Utilisez 50 % de la RAM disponible pour tester :
Vous pouvez réduire innodb_buffer_pool_size très bas pour voir si cela aide :
#/etc/my.cnf
innodb_buffer_pool_size = 1M
Une règle empirique consiste à définir innodb_buffer_pool_size à 50 % de la RAM disponible pour vos tests de mémoire faible. Cela signifie que vous démarrez le serveur et tout sauf MySQL InnoDB. Voyez combien de RAM vous avez. Utilisez ensuite 50 % de cela pour InnoDB.
Pour essayer plusieurs paramètres à faible mémoire à la fois :
Un coupable plus probable est tout ce qui se trouve sur ce serveur, tel qu'un serveur Web.
Apache ?
Utilisez-vous Apache et/ou un autre serveur Web ? Si c'est le cas, essayez de réduire son utilisation de la RAM. Par exemple, dans Apache conf, considérez les paramètres de faible RAM comme ceux-ci :
StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5
Et limitez les demandes comme ceci :
MaxRequestsPerChild 300
Puis redémarrez Apache.
mod_wsgi :
Si vous utilisez Apache avec mod_python, passez à Apache avec mod_wsgi.
Pymple :
Si cela se produit toujours, votre Django est peut-être en croissance constante. Essayez le profilage de mémoire Django avec Pympler :
SAR :
Votre rapport d'échecs une fois par jour, puis d'échecs une fois par semaine, pourrait indiquer une sorte de tâche cron exécutée quotidiennement ou hebdomadairement. Par exemple, il y a peut-être un traitement par lots qui prend beaucoup de RAM, ou un vidage de base de données, etc.
Pour suivre l'utilisation de la RAM et rechercher les pics de RAM dans l'heure qui précède la mort de MySQL, jetez un œil à SAR, qui est un excellent outil :http://www.thegeekstuff.com/2011/03/sar-examples/
