Shopware Datenbank frisst RAM bis zum Absturz

Hallo zusammen,

meine Shopware 5.2.21 lief einige Zeit auf einer „t2.micro“ Amazon web services Instanz. Diese bot 1 GB Arbeitsspeicher. Nachdem der mysqld Prozess immer öfter abstürzte habe ich die Instanz auf „t2.small“ mit 2 GB Arbeitsspeicher geupgraded. Leider tritt immernoch der gleiche Fehler auf (var/log/mysqld.log):

 

170324 17:22:23 InnoDB: Fatal error: cannot allocate memory for the buffer pool

170324 17:22:23 [ERROR] Plugin ‚InnoDB‘ init function returned error.

170324 17:22:23 [ERROR] Plugin ‚InnoDB‘ registration as a STORAGE ENGINE failed.

170324 17:22:23 [ERROR] Unknown/unsupported storage engine: InnoDB

170324 17:22:23 [ERROR] Aborting

 

Eine Idee warum die Shopware Datenbank bis zum Absturz Arbeitsspeicher konsumiert? Kann ich dies irgendwo limitieren?

Danke für jede Hilfe!

LG,

Elisa

ich glaube nicht dass das was mit dem Arbeitsspeicher zu tun hat; eher dass diese „Instanzen“ gar nicht für einen Shop geeignet sind ?

Wende dich mit der Frage doch mal an den Amazon-Support und berichte uns.

1 „Gefällt mir“

Hallo @Elisa‍

welche Werte hast Du denn in der my.cnf gesetzt? Die sind wahrscheinlich zu hoch gewählt. Fang mit niedrigeren  innodb_buffer_pool_size Werten in /etc/my.cnf an. 

Bedenke, dass nicht das gesamte RAM für den Datenbankserver zur Verfügung steht - Betriebssystem und die restlichen Dienste benötigen ebenfalls ihren Anteil. Du kannst nicht einfach 80% des RAM verwenden, obwohl  es oft “empfohlen” wird.

Hast Du schon überprüft wie die RAM-Auslastung zum Zeitpunkt der Fehlermeldung aussieht? Theoretisch könnten auch andere Systemkomponenten das RAM auslasten und ohne Swap-Speicher startet dann der mysqld Prozess nicht mehr. Stehen noch weitere Meldungen vor dem zitierten Ausschnitt aus mysqld.log?

Warum nimmst Du eine Amazon-Instance statt eines vernünftig konfigurierten managed vServer? Das ist eigentlich mehr Arbeit und man sollte sich schon ordentlich mit Serverkonfigurationen auskennen oder eines der Marketplace Angebote - z. B. die bitnami Images für Shopware - nutzen.

 

1 „Gefällt mir“

Danke für die Antworten! Die AWS instanzen sind ja eigentlich ganz normale vServer, ich habe mir eigentlich keine großen Gedanken bei der Auswahl gemacht. Die Installation und alles andere funktionierten auch reibungslos. Das es vorgefertige Images für Shopware gibt ist natürlich interessant - wusste ich nicht! 

Das ist die komplette /etc/my.conf

mysqld]

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

Disabling symbolic-links is recommended to prevent assorted security risks

symbolic-links=0

Settings user and group are ignored when systemd is used.

If you need to run mysqld under a different user or group,

customize your systemd unit file for mysqld according to the

instructions in Redirect Notice

 

[mysqld_safe]

log-error=/var/log/mysqld.log

pid-file=/var/run/mysqld/mysqld.pid

Eine mysql Abfrage nach folgenden Variablen liefert noch diese Informationen:

mysql> show variables like ‚key_buffer_size‘;

±----------------±--------+

| Variable_name   | Value   |

±----------------±--------+

| key_buffer_size | 8388608 |

±----------------±--------+

1 row in set (0.00 sec)

 

mysql> show variables like ‚innodb_buffer_pool_size‘;

±------------------------±----------+

| Variable_name           | Value     |

±------------------------±----------+

| innodb_buffer_pool_size | 134217728 |

±------------------------±----------+

1 row in set (0.01 sec)

 

Das sollten 8,4 und 134MB sein… womit ich doch eigentlich mit 2GB RAM klarkommen sollte, oder?

Sind die geposteten Zeilen alles, was im Log steht oder gibt es davor noch etwas wie -  Number of processes running now    ?

Na ja, ich würde schon mehr RAM für innodb_buffer_pool_size nehmen, wenn 2 GB RAM zur Verfügung stehen. Die Fehlermeldung sagt aber schon, dass zu wenig RAM zur Verfügung steht. Vielleicht ist es doch eine Sackgasse und das OS killt den mysqld aufgrund von RAM Problemen und anschließend kann er nicht neu gestartet werden. Ich würde dann nur noch mehr Meldungen im Log erwarten. 

Klar sind die Amazon Instanzen „normale“ vServer, wenn man diese denn so einsetzt. Aber wenn man das Autoscaling und die ganzen anderen Optionen nicht benötigt, spricht doch gar nichts für deren Einsatz. Du musst den gesamten Server mit allen Diensten selber verwalten, Fehler suchen und preislich ist es dann auch nicht günstig. Laufen tut es auf jeden Fall in t2 Instanzen