it-swarm.com.de

der mysqld-Dienst wird einmal täglich auf dem ec2-Server angehalten

Umgebungsdetails:

Server: Amazon ec2 Linux
Web Server: Apache
Web Framework: Django with mod_wsgi

Folgendes habe ich in der Datei mysql_err.log gefunden.

The InnoDB memory heap is disabled
120823  3:21:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120823  3:21:40 InnoDB: Compressed tables use zlib 1.2.3
120823  3:21:40 InnoDB: Using Linux native AIO
120823  3:21:41 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
120823  3:21:41 InnoDB: Completed initialization of buffer pool
120823  3:21:41 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120823  3:21:41 [ERROR] Plugin 'InnoDB' init function returned error.
120823  3:21:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120823  3:21:41 [ERROR] Unknown/unsupported storage engine: InnoDB
120823  3:21:41 [ERROR] Aborting

Anscheinend reicht der Systemspeicher nicht aus, um dem Pufferpool Speicher zuzuweisen. Der gleiche Fehler tritt auf, wenn ich Amazon ec2 micro instance verwendete. Also wechselte ich zum small instance. Es funktioniert für einige Tage gut, aber jetzt bricht es einmal am Tag wieder. Gibt es eine dauerhafte Lösung dafür? Ich kann zur Medium-Instanz wechseln, aber das Problem ist, ob das behoben wird oder nicht? Sollte ich den innodb_buffer_pool_size verringern, welche Größe sollte bevorzugt werden?

Das Ergebnis von cat /proc/meminfo ist folgendes (möglicherweise hilft es):

MemTotal:        1697824 kB
MemFree:          125744 kB
Buffers:          109704 kB
Cached:           481408 kB
SwapCached:            0 kB
Active:          1212396 kB
Inactive:         266840 kB
Active(anon):     888192 kB
Inactive(anon):       76 kB
Active(file):     324204 kB
Inactive(file):   266764 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 4 kB
Writeback:             0 kB
AnonPages:        888144 kB
Mapped:            15604 kB
Shmem:               144 kB
Slab:              63752 kB
SReclaimable:      53680 kB
SUnreclaim:        10072 kB
KernelStack:         800 kB
PageTables:        16436 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      848912 kB
Committed_AS:    1417140 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       10988 kB
VmallocChunk:   34359725168 kB
DirectMap4k:     1748992 kB
DirectMap2M:           0 kB

Betriebssystemversion (uname -a): Linux ip-10-246-134-149 3.2.21-1.32.6.amzn1.x86_64 #1 SMP Sat Jun 23 02:32:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Ich habe den Befehl ps aux überprüft, nach dem der Server nur noch 15 MB Speicher hat, und dies ist der Prozess httpd, der zu diesem Zeitpunkt ausgeführt wird:

Das Ergebnis von free -m

total       used       free     shared    buffers     cached
Mem:          1657       1628         29          0          3         19
-/+ buffers/cache:       1605         51
Swap:          895        875         20

Das Ergebnis von ps aux

Apache   21123  0.1  1.2 394652 20464 ?        S    19:35   0:06 /usr/sbin/httpd
Apache   21146  0.1  1.2 394280 20796 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21152  0.1  1.2 394284 21560 ?        S    19:38   0:05 /usr/sbin/httpd
Apache   21155  0.2  1.4 396244 24528 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21156  0.1  1.1 392552 20344 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21157  0.1  1.1 394284 18884 ?        S    19:38   0:05 /usr/sbin/httpd
Apache   21159  0.1  1.4 396200 25040 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21161  0.1  1.2 394856 21724 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21162  0.1  1.3 394864 22400 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21163  0.1  1.3 394860 22204 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21164  0.1  1.1 392560 19204 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21165  0.1  1.3 394832 22280 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21166  0.1  1.3 395276 22932 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21172  0.2  1.4 396320 24820 ?        S    19:38   0:06 /usr/sbin/httpd
Apache   21174  0.2  1.7 400672 29452 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21178  0.1  1.4 400540 25304 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21179  0.2  1.6 400580 27856 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21184  0.1  1.7 400628 29320 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21185  0.1  1.6 397944 27292 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21186  0.1  1.5 397960 25648 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21187  0.1  1.7 400576 29120 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21191  0.1  1.4 400576 24400 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21193  0.1  1.4 400536 24940 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21194  0.1  1.5 400572 26096 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21203  0.1  1.6 400580 28808 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21206  0.1  1.7 400584 29732 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21207  0.1  1.6 400576 27940 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21224  0.1  1.2 400624 20768 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21225  0.1  1.6 400576 28468 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21226  0.1  1.6 400576 28048 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21228  0.1  1.4 400572 23880 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21237  0.1  1.5 400628 26124 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21265  0.1  1.6 400536 28592 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21276  0.1  1.2 400544 21456 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21277  0.1  1.3 400624 22676 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21278  0.1  1.6 400536 27360 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21282  0.1  1.4 400612 24996 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21292  0.1  1.4 400532 24780 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21302  0.2  1.2 400540 21332 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21303  0.1  1.3 400628 22228 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21305  0.2  1.2 400536 21116 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21306  0.1  1.3 400572 22380 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21307  0.1  1.1 397956 20056 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21308  0.1  1.2 400624 21520 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21319  0.1  1.1 400540 19468 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21320  0.1  1.3 400628 22712 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21335  0.1  1.0 400540 17236 ?        S    19:39   0:05 /usr/sbin/httpd
Apache   21336  0.1  1.3 400628 22188 ?        S    19:39   0:06 /usr/sbin/httpd
Apache   21352  0.1  1.1 394276 18972 ?        S    19:40   0:04 /usr/sbin/httpd
Apache   21356  0.1  1.1 394280 19028 ?        S    19:40   0:05 /usr/sbin/httpd
Apache   21358  0.1  1.1 394280 19004 ?        S    19:40   0:05 /usr/sbin/httpd
Apache   21361  0.2  0.7 400452 12632 ?        S    19:40   0:06 /usr/sbin/httpd
Apache   21610  0.2  1.6 400536 27660 ?        S    19:46   0:06 /usr/sbin/httpd
Apache   21643  0.2  1.3 400156 23272 ?        S    19:55   0:04 /usr/sbin/httpd
Apache   21647  0.2  1.0 400544 17556 ?        S    19:57   0:05 /usr/sbin/httpd
Apache   21654  0.2  1.5 400188 26884 ?        S    19:58   0:05 /usr/sbin/httpd
Apache   21719  0.3  1.9 400192 32264 ?        S    20:14   0:03 /usr/sbin/httpd
Apache   21725  0.2  2.0 400044 35340 ?        S    20:15   0:03 /usr/sbin/httpd
Apache   21738  0.0  0.8 257648 13792 ?        S    20:26   0:00 /usr/sbin/httpd

Kann jemand eine Idee darüber haben, warum es so viel httpd-Prozess gibt?

39
Aamir Adnan

Verwenden Sie 50% of available RAM, um Folgendes zu testen:

Sie können den Wert für innodb_buffer_pool_size sehr verringern, um zu sehen, ob dies hilfreich ist:

#/etc/my.cnf 
innodb_buffer_pool_size = 1M

Als Faustregel können Sie innodb_buffer_pool_size auf 50% des verfügbaren Werts RAM setzen, wenn Sie wenig Speicher benötigen. Das heißt, Sie starten den Server und alles außer MySQL InnoDB. Sehen Sie, wie viel RAM Sie haben. Dann verwenden Sie 50% davon für InnoDB.

So testen Sie viele Einstellungen mit wenig Arbeitsspeicher gleichzeitig:

Ein wahrscheinlicher Täter ist das, was sich auf diesem Server befindet, beispielsweise ein Webserver.

Apache?

Verwenden Sie Apache und/oder einen anderen Webserver? Wenn ja, versuchen Sie, die Verwendung von RAM zu verringern. Betrachten Sie beispielsweise in Apache conf die folgenden Einstellungen: low RAM:

StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5

Und bedecken Sie die Anfragen wie folgt:

MaxRequestsPerChild 300

Starten Sie dann Apache neu.

mod_wsgi:

Wenn Sie Apache mit mod_python verwenden, wechseln Sie mit mod_wsgi zu Apache.

Pympler:

Wenn es immer noch passiert, wächst Ihr Django möglicherweise ständig. Testen Sie das Django-Memory-Profiling mit Pympler:

SAR:

Ihr Bericht über Fehlschläge einmal pro Tag und einmal pro Woche könnte auf eine Art Cron-Job hinweisen, der täglich oder wöchentlich ausgeführt wird. Zum Beispiel gibt es vielleicht einen Batch-Prozess, der viel RAM benötigt, oder einen Datenbankspeicherauszug usw. 

Um RAM zu verfolgen und nach RAM Spitzen in der Stunde vor dem Tod von MySQL zu suchen, werfen Sie einen Blick auf SAR, ein großartiges Werkzeug: http: //www.thegeekstuff) .com/2011/03/SAR-Beispiele /

37

Sie müssen Ihren innodb_buffer_pool_size = <60-80% Ihres Hauptspeichers verringern.)

Lösung für Innodb-Fehler:

110603  7:34:15 [ERROR] Plugin ‘InnoDB’ init function returned error.
110603  7:34:15 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
110603  7:34:15 [ERROR] Unknown/unsupported storage engine: InnoDB
110603  7:34:15 [ERROR] Aborting

10603  7:34:15 [Note] /usr/sbin/mysqld: Shutdown complete

I moved the ib_logfile0 and ib_logfile01 to bak and start Mysql again. Now this time, it is working fine

[[email protected] mysql]# mv ib_logfile0 ib_logfile0-bak
[[email protected] mysql]# mv ib_logfile1 ib_logfile1-bak

Quelle: http://www.onaxer.com/tag/error-plugin-innodb-init-function-returned-error/

9
Rush

Wie andere bereits erwähnt haben, scheint das Problem zu sein, dass Ihr System bei RAM zu niedrig ist und MySQL dadurch in die Luft geht. Im Folgenden wird beschrieben, wie Sie den Speicherplatz Ihres Systems einschränken und wie Sie die Datenbank nach dem Ausfall der Datenbank wiederherstellen können.

Werfen Sie einen Blick auf collectd und seine Plugins. Einige der zutreffenden sind möglicherweise das Prozess-Plugin und das Memory-Plugin . Mit diesen können Sie die Speichernutzung Ihres Systems sehen und welche Prozesse den größten Teil davon beanspruchen.

Je nachdem, wie Sie Django ausführen, können Sie die Arbeitsprozesse so konfigurieren, dass nur eine bestimmte Anzahl von Anforderungen verarbeitet und anschließend beendet wird. Wenn also in Ihrer Anwendung eine Art Speicherverlust auftritt, bleibt diese Anzahl der Anforderungen nicht bestehen. Wenn Sie beispielsweise Gunicorn verwenden, können Sie die Option --max-request verwenden. Wenn Sie 500 einstellen, wird der Bearbeiter gelöscht, nachdem er 500 Anforderungen verarbeitet hat.

Die oben genannte Kombination mit der Statistiksammlung zeigt Ihnen einige interessante Trends zur Speichernutzung.

Wenn die Datenbank ausfällt, können Sie die Prozessüberwachung so einrichten, dass MySQL automatisch neu gestartet wird. MySQL in der neuesten Ubuntu-Version verwendet dazu Upstart. Wenn der Prozess beendet wird, bringt Upstart ihn sofort wieder hoch. Wenn Sie eine andere Distribution verwenden, die nicht über dieses integrierte Gerät verfügt, schauen Sie unter Supervisor nach. Obwohl das Problem dadurch nicht behoben wird, werden zumindest die Auswirkungen gemindert. Dies sollte nicht als Fix betrachtet werden, sondern eher als eine Möglichkeit, die Anwendung weiterhin auszuführen, falls etwas schief geht.

2
berto

Nachdem ich in ähnlichen Fragen steckengeblieben war, war ich wirklich frustriert, dass meine Benutzer diese hässliche Nachricht Fehler beim Herstellen der DB-Verbindung sehen. Anstatt die genauen Probleme zu lösen, fand ich dieses Repo , um für mich (vorübergehend) wie ein Zauber zu wirken. Danach wurde ich von meinem Freund debuggt und er hat meinen Server mit einigen Konfigurationsänderungen optimiert. Ich habe dieses Skript jedoch immer noch alle 10 Minuten zu meiner Crontab hinzugefügt und dann überprüft, ob der Server abgestürzt ist (was für meinen Fall irgendwann abstürzte, wenn ich VNCServer auf meinem Server ausführte) und dann neu starten

1
Hammad

Das Erhöhen des verfügbaren RAM durch Hinzufügen eines neuen Swap-Bereichs kann ebenfalls hilfreich sein. Schritte sind hier

Stellen Sie sicher, dass Sie eine/swap-Datei mit einer kleineren Größe als dem verfügbaren Speicherplatz erstellen

df -h

Zum Beispiel war für mich die Ausgabe von df-h:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  1.2G  6.3G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            492M   12K  492M   1% /dev
tmpfs           100M  336K   99M   1% /run

Also habe ich mit 2 G erstellt

Sudo fallocate -l 2G /swapfile

Und dann einfach den Dienst starten

Sudo /etc/init.d/mysql restart

Hoffe das hilft. Alles Gute.

0
Vivek

Ich fand Antwort fügt zu dieser Diskussion hinzu und arbeitete für mich: https://www.digitalocean.com/community/questions/mysql-server-keeps-stopping-unexpectedly?answer=26016

sie müssen sowohl innodb_buffer_pool_size als auch 32M für my.conf in /etc/mysql/my.cnf ausführen Möglicherweise müssen Sie auch /etc/Apache2/mods-enabled/mpm_prefork.conf ändern, um die Anzahl der von Apache gestarteten Verbindungen zu verringern.

<IfModule mpm_prefork_module>
    StartServers     3
    MinSpareServers  3
    MaxSpareServers  5
    MaxRequestWorkers 25
    MaxConnectionsPerChild  0
</IfModule>
0
Vishal Patel