Bonjour et merci pour vos réponses, Vous m'avez dissuadé de faire cette connerie :-p du coup je vais me concentrer à optimiser ma conf mysql... @Exca : je n'ai pas retrouvé mais c'était juste des moulinettes bash Alter table brutale... @tranxene50 : Le 23/07/2013 21:48, tranxene50 a écrit :
Hello !
Je cherche à gagner de la mémoire vive (car mon piti serveur part trop en SWAP) [...] www.linuxatemyram.com
Que racontent "free -m" et "cat /proc/meminfo" ?
Tu peux configurer "l'agressivité" de la SWAP directement avec /proc/sys/vm/swappiness ("vm.swappiness = XX" dans /etc/sysctl.conf)
https://en.wikipedia.org/wiki/Swappiness
Essaye avec une valeur de 10, démonte la swap (swapoff -va) et remonte la (swapon -va).
Attention, le système peut "freezer" pendant plusieurs secondes lors du démontage et, pire cas de figure, si vraiment les applis consomment plus de RAM que celle réellement disponible, "OOM killer" sera de sortie (et ça, c'est pas bon...)
Bref, avant : "free -m" et "cat /proc/meminfo" ;)
J'ai oublié de précisé que c'est un VPS OpenVZ donc pas certain que Swappiness soit paramétrable à l'intérieur de la VM... !? (en tous cas je n'ai pas la possibilité de démonter/remonter ma swap, ni même d'en ajouter via du swapfile...) http://pastebin.com/zYft6Eu8 http://dl.zici.fr/filestore/28/Mhq9zevQmh.memory-day.png._ http://dl.zici.fr/filestore/70/wqzzY8Vslf.memory-week.png._
Après plusieurs recherches sur le Web de l'internet et plusieurs tests je me suis rendu compte que InnoDB était très gourmand en RAM Mmmmh... Certes, InnoDB a une empreinte mémoire légèrement plus élevée que MyISAM mais, dans les faits, ce n'est pas un problème.
En fait, j'aurais plutôt envie de te conseiller l'inverse : tout passer en InnoDB (non, ce n'est pas un troll)
La contention (row locking) est meilleure, tu disposeras de toutes les fonctionnalités (contraintes d'intégrité, transactions, isolation, etc) et tu pourras faire des backups fiables (car le dump sera atomique).
Consommation mémoire sur un serveur en désactivant InnoDB : 22048 Consommation mémoire sur un serveur avec InnoDB : 380792 Sans voir ton fichier de conf (/etc/mysql/my.cnf), on ne peut rien déduire mais à priori c'est lié à ta configuration.
Le voici : http://pastebin.com/QY61NfUc N'étant pas très pointu en config mysql je me suis certainement basé à l'époque sur ce tuto : http://wiki.vpslink.com/Low_memory_MySQL_/_Apache_configurations
Est-ce que tu peux télécharger et lancer :
- https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl
Cool ces scripts, je connaissais pas c'est parfais !!! Résultat : http://pastebin.com/Z003FKMF
- https://launchpad.net/mysql-tuning-primer/trunk/1.6-r1/+download/tuning-prim...
Si MySQL ne tourne pas depuis 48 heures, les scripts vont "râler" mais ce n'est pas bien grave.
Pour faire simple, MySQL une fois configuré consommera la mémoire que tu lui aura alloué, quelle que soit la taille de tes bases de données.
Si tu mets une valeur trop basse, tu auras beaucoup d'entrées/sorties à cause des lectures sur le disque et, si tu mets une valeur trop haute, MySQL va s'accaparer autant de mémoire qu'il le peut sans pour autant atteindre la limite supérieure donc cela ne sert à rien.
Dans mon cas je penses qu'il est nécessaire de diminuer l’occupation mémoire et de faire plus d'I/O sur disque...
En fait, tout dépend du nombre de connexions simultanées que tu veux autoriser et de la mémoire que tu souhaites allouer au buffer InnoDB ainsi qu'au cache (en supposant que ce soit vraiment utile).
J'ai malheureusement énormément de table en InnoDB, j'ai trouvé des scripts pour automatiser la migration vers MySAM mais j'ai peur de foutre le bordel monstre (Hode, TinyTinyRSS, Joomla, Wordpress... comment ça va réagir ?) Donc je voulais, par ce présent email être rassuré ou lynché pour cette migration Je confirme ce que dit Exca : si une application repose sur des contraintes d'intégrité (typiquement les DELETE en CASCADE), basculer en MyISAM va engendrer deux choses :
- l'application ne fonctionnera plus correctement - les données seront corrompues/désynchronisées ou orphelines
Note : j'ai déjà joué beaucoup avec skip-locking, table_open_cache, sort_buffer_size... mais si vous avez des conseils je prends aussi. Gare au sort_buffer_size ! (mal configuré c'est un gouffre à RAM)
http://www.mysqlperformanceblog.com/2010/10/25/impact-of-the-sort-buffer-siz...
skip-external-locking : pas de souci tant que tu n'as qu'un seul serveur MySQL qui accède aux données physiques des BDD (variable "datadir").
table_open_cache : tout dépend du nombre de tes tables (actives).
A+
Je vais essayer de tuner mon my.cnf ! Si vous avez d'autres conseils poussés au vu des éléments supplémentaires que j'ai apporté n'hésitez pas ! Merci bien, David -- http://www.zici.fr http://www.mercereau.info