EC2-Instanz wird automatisch nicht mehr verfügbar – 504 Gateway-Timeout

EC2-Instanz wird automatisch nicht mehr verfügbar – 504 Gateway-Timeout

Ich habe eint3a.microInstanz mit WordPress und ziemlich geringem Datenverkehr. Diese Instanz wird automatisch nicht mehr verfügbar, was zu einem 504 Gateway-Timeout-Fehler führt. In diesem Moment kann ich auch keine Verbindung mit EC2 über SSH herstellen. Dies geschieht zu jeder Tageszeit, manchmal täglich und manchmal die ganze Woche über überhaupt nicht. Es gibt auch keine Datenverkehrsspitze, wenn es ausfällt. Ich habe diese Frage auch dem AWS-Support gestellt und folgende Antwort erhalten:

Bei der Überprüfung von meiner Seite aus konnte ich feststellen, dass die Instanz die Instanzstatusprüfung[1] in den letzten 24 Stunden mehrmals nicht bestanden hat, was darauf hindeutet, dass die Instanz Probleme auf Betriebssystemebene hat. Bei der weiteren Überprüfung der Konsolenprotokolle konnte ich den folgenden Fehler „Nicht genügend Arbeitsspeicher“ feststellen:

[ 5626.002561] Nicht genügend Arbeitsspeicher: Prozess 2050 (apache2) beendet total-vm:552924kB, anon-rss:54868kB, file-rss:0kB, shmem-rss:32076kB, UID:33 pgtables:848kB oom_score_adj:0

[ 5674.174673] Nicht genügend Arbeitsspeicher: Prozess 1788 (apache2) beendet total-vm:624936kB, anon-rss:51952kB, file-rss:0kB, shmem-rss:34184kB, UID:33 pgtables:856kB oom_score_adj:0

[ 5763.820732] Nicht genügend Arbeitsspeicher: Prozess 1815 (apache2) beendet total-vm:550384kB, anon-rss:51604kB, file-rss:0kB, shmem-rss:34532kB, UID:33 pgtables:836kB oom_score_adj:0

[ 5773.275938] Nicht genügend Arbeitsspeicher: Prozess 1973 (apache2) beendet total-vm:624744kB, anon-rss:52260kB, file-rss:0kB, shmem-rss:32136kB, UID:33 pgtables:856kB oom_score_adj:0

[ 5959.347157] Nicht genügend Arbeitsspeicher: Prozess 2014 (apache2) beendet total-vm:552440kB, anon-rss:54020kB, file-rss:0kB, shmem-rss:28856kB, UID:33 pgtables:844kB oom_score_adj:0

[ 6438.787255] Nicht genügend Arbeitsspeicher: Prozess 2165 (apache2) beendet total-vm:624756kB, anon-rss:51948kB, file-rss:0kB, shmem-rss:29836kB, UID:33 pgtables:856kB oom_score_adj:0

Ein wenig zum OOM-Killer (Out of Memory): Wenn der Speicher von Prozessen so stark aufgebraucht wird, dass die Stabilität des Systems gefährdet ist, greift der OOM-Killer. Die Aufgabe des OOM-Killers besteht darin, weiterhin Prozesse zu beenden, bis genügend Speicher für das reibungslose Funktionieren des restlichen Prozesses freigegeben ist, den der Kernel auszuführen versucht. Aus der Ausgabe scheint hervorzugehen, dass Ihre Instanz den Speicher möglicherweise aufgebraucht hat, sodass der OOM-Killer vom Linux-Kernel aufgerufen wird.

Sie schlugen vor, die Speichernutzung jedes Prozesses zu überwachen und diesen Prozess zu beenden oder zu reparieren, damit nicht so viel Speicher verbraucht wird. Dies scheint kein sehr praktischer Ansatz zu sein, wenn ich WordPress verwende, das ich nicht ändern kann, selbst wenn es einige Minuten lang zu viel Speicher verbraucht.

Ich habe eine andere Instanzt3.kleinVerwendung von Elastic Beanstalk, das eine Java-Webanwendung mit einer Nginx/Tomcat-Umgebung auf einem von Beanstalk bereitgestellten Amazon Linux AMI hostet. Dasselbe Problem tritt bei dieser Instanz auf, sie stürzt automatisch ab und zeigt ein 504-Gateway-Timeout an.

Frage:- Ich möchte meine Instanz nicht aktualisieren, da sie mit dem aktuellen Datenverkehr einwandfrei läuft. Gibt es eine Lösung, um diese Probleme ohne Aktualisierung und natürlich ständige Überwachung der Prozesse zu beheben?

Antwort1

Ihre Hauptoptionen sind:

  • Finden Sie heraus, was den RAM nutzt, und konfigurieren Sie es so, dass weniger RAM genutzt wird (beste Option).
  • Verwenden Sie eine Instanz mit mehr RAM (was das Problem möglicherweise nicht vollständig löst).
  • Verwenden Sie eine Auslagerungsdatei als kostengünstige Möglichkeit, den RAM zu erhöhen. Ich verwende eine Auslagerungsdatei nur, um sicherzustellen, dass etwas übrig bleibt, um OOM-Situationen zu vermeiden. Auch wenn das das Problem nicht löst, ist es dennoch eine gute Idee.

Ich betreibe fünf Wordpress-Websites mit relativ geringem Volumen, MySQL und einige andere Tools auf einem t3a.nano (512 MB RAM) plus 512 MB Swap.

Hier sind einige Möglichkeiten, um den Speicherverbrauch eines typischen Wordpress-Systems zu reduzieren (spontan fallen mir folgende ein):

  • Begrenzen Sie die Anzahl der PHP-Threads/Worker. Ich denke, ich lasse vielleicht 2-3 Threads zu. Wenn einer nicht verfügbar ist, wartet der Webserver, bis einer verfügbar ist, was normalerweise nicht lange dauert. Dies ist entscheidend, da PHP/WordPress enorme Speicherfresser sind.
  • Begrenzen Sie den maximal verfügbaren Speicher für jeden PHP-Thread.
  • MySQL-Leistungsschema deaktivieren
  • Ändern Sie MySQL-Parameter, um den Speicherverbrauch zu reduzieren. Sie müssen im Grunde nur die Dokumentation lesen, aber ich kopiere unten meine aktuelle Konfiguration. Das ist von meinem Windows-PC, aber unter Linux wird es ähnlich sein.
  • Überprüfen Sie die Speichernutzung Ihres Webservers. Wenn es sich um Apache handelt und dieser hoch ist, könnten Sie Nginx in Betracht ziehen, das schnell und klein ist.

Sie sollten auch nach „LAMP (oder LEMP) WordPress reduziert Speichernutzung“ suchen.

Hier ist die MySQL-Konfiguration, die ich verwende. Es ist meine neue Konfiguration für MySQL 8.x und wurde noch nicht getestet, aber sie ist meiner MySQL5-Konfiguration recht ähnlich, also sollte sie ok sein. Sie ist für geringen Speicherverbrauch optimiert, nicht für hohe Leistung, und ich bin kein MySQL-Experte, also ist sie wahrscheinlich nicht so toll.

[mysqld]
# set basedir to your installation path
basedir=(insert here)
# set datadir to the location of your data directory
datadir=(insert here)

# Turn off performance schema
performance_schema=OFF

# Turn off binary log
skip-log-bin
log_bin = OFF

# Disable monitoring
innodb_monitor_disable=all

# RAM optimisation settings overall
innodb_buffer_pool_size=50M
innodb_buffer_pool_instances=1
innodb_flush_method=unbuffered
innodb_log_buffer_size=1048576
innodb_log_file_size=4194304
innodb_max_undo_log_size=10485760
innodb_sort_buffer_size=64K
innodb_ft_cache_size=1600000
innodb_max_undo_log_size=10485760
max_connections=20
key_buffer_size=1M

# Reduce RAM: per thread or per operation settings
thread_stack=140K
thread_cache_size = 2
read_buffer_size=8200
read_rnd_buffer_size=8200
max_heap_table_size=16K
tmp_table_size=128K
temptable_max_ram=2097152
bulk_insert_buffer_size=0
join_buffer_size=128
net_buffer_length=1K

# Slow query log
slow_query_log=OFF
#long_query_time=5
#log_slow_rate_limit=1
#log_slow_rate_type=query
#log_slow_verbosity=full
#log_slow_admin_statements=ON
#log_slow_slave_statements=ON
#slow_query_log_always_write_time=1
#slow_query_log_use_global_control=all

# Logs
log_error = (wherever)
general_log = ON
general_log_file  = (wherever)

verwandte Informationen