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" ;)
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. Est-ce que tu peux télécharger et lancer : - https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl - 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. 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+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr