Verwenden Sie zum Testen 50 % des verfügbaren Arbeitsspeichers:
Sie können die innodb_buffer_pool_size sehr niedrig verringern, um zu sehen, ob es hilft:
#/etc/my.cnf
innodb_buffer_pool_size = 1M
Als Faustregel gilt, dass Sie innodb_buffer_pool_size auf 50 % des verfügbaren Arbeitsspeichers setzen, um Ihren niedrigen Arbeitsspeicher zu testen. Das heißt, Sie starten den Server und alles außer MySQL-InnoDB. Sehen Sie, wie viel RAM Sie haben. Verwenden Sie dann 50 % davon für InnoDB.
Um viele Low-Memory-Einstellungen gleichzeitig auszuprobieren:
Ein wahrscheinlicherer Übeltäter ist, was sich sonst noch auf diesem Server befindet, wie zum Beispiel ein Webserver.
Apache?
Verwenden Sie Apache und/oder einen anderen Webserver? Versuchen Sie in diesem Fall, die RAM-Nutzung zu verringern. Berücksichtigen Sie zum Beispiel in Apache conf niedrige RAM-Einstellungen wie diese:
StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5
Und begrenzen Sie die Anforderungen wie folgt:
MaxRequestsPerChild 300
Starten Sie dann Apache neu.
mod_wsgi:
Wenn Sie Apache mit mod_python verwenden, wechseln Sie zu Apache mit mod_wsgi.
Pympler:
Wenn es immer noch passiert, wächst Ihr Django möglicherweise stetig. Probieren Sie die Django-Speicherprofilerstellung mit Pympler aus:
SAR:
Ihr Bericht über Fehler einmal pro Tag und dann einmal pro Woche könnte auf eine Art Cron-Job hinweisen, der täglich oder wöchentlich ausgeführt wird. Vielleicht gibt es zum Beispiel einen Batch-Prozess, der viel RAM beansprucht, oder einen Datenbank-Dump usw.
Um die RAM-Nutzung zu verfolgen und in der Stunde vor dem Abbruch von MySQL nach RAM-Spitzen zu suchen, werfen Sie einen Blick auf SAR, ein großartiges Tool:http://www.thegeekstuff.com/2011/03/sar-examples/
