Ich betreibe eine t2.micro-Instanz auf Amazon Linux AMI 2018.03 (4.14.59-64.43.amzn1.x86_64). Sie hostet eine PHP-Website mit Apache/2.4.33 und stellt eine Verbindung zu einer RDS MySQL-Datenbank her.
Von Zeit zu Zeit „verschwindet“ der Server komplett. Versuche, die Website anzuzeigen, sich mit dem FTP zu verbinden oder sogar eine SSH-Verbindung mit Putty herzustellen, führen alle zu einem Timeout. Und er kommt nicht von alleine zurück, ich muss den Server manuell über die AWS-Konsole herunterfahren und neu starten, dann ist alles wieder normal. (Interessanterweise bewirkt der Befehl „reboot“ nichts und scheint vom Server ignoriert zu werden. Nur das Herunterfahren und erneute Starten funktioniert)
Das Problem ist, dass ich alle Protokolldateien geprüft habe, die ich finden konnte, und dass es zu der Zeit, als der Server nicht mehr reagierte, nichts zu geben scheint. Ich habe also keine Ahnung, wie ich das Problem beheben soll. Beim Prüfen der Cloudwatch-Metriken scheinen die CPU- und Netzwerkauslastung auch dann normal zu sein, wenn der Server nicht reagiert.
Dies scheint zu passieren, wenn ich ein bestimmtes speicherintensives PHP-Skript mehrmals ausführe (aber ich kann dieses Skript auch zufällig ohne Probleme ausführen), daher vermute ich, dass es mit dem Auffüllen des RAM zusammenhängen könnte. Aber wenn das System etwas schließen würde, um Speicher freizugeben, würde es dann nicht in den Protokollen angezeigt werden?
Wie würde man in einer solchen Situation beim Debuggen vorgehen?
Danke
Im Nachrichtenprotokoll ist nur Folgendes zum letzten Vorkommen aufgeführt:
Sep 6 15:11:34 compta dhclient[2266]: PRC: Renewing lease on eth0.
Sep 6 15:11:34 compta dhclient[2266]: XMT: Renew on eth0, interval 10970ms.
Sep 6 15:11:34 compta dhclient[2266]: RCV: Reply message on eth0 from ****::***:****:****:****.
Sep 6 15:11:34 compta ec2net: [get_meta] Trying to get http://***.***.***.***/latest/meta-data/network/interfaces/macs/**:**:**:**:**:**/local-ipv4s
Sep 6 15:11:34 compta ec2net: [rewrite_aliases] Rewriting aliases of eth0
Sep 6 15:11:34 compta ec2net: [get_meta] Trying to get http://***.***.***.***/latest/meta-data/network/interfaces/macs/**:**:**:**:**:**/subnet-ipv4-cidr-block
Sep 6 15:22:13 compta kernel: imklog 5.8.10, log source = /proc/kmsg started.
Sep 6 15:22:13 compta rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2356" x-info="http://www.rsyslog.com"] start
Sep 6 15:22:13 compta kernel: [ 0.000000] Linux version 4.14.59-64.43.amzn1.x86_64 (mockbuild@gobi-build-64010) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #1 SMP Thu Aug 2 21:29:33 UTC 2018
Sep 6 15:22:13 compta kernel: [ 0.000000] Command line: root=LABEL=/ console=tty1 console=ttyS0 selinux=0 LANG=en_US.UTF-8 KEYTABLE=us
Sep 6 15:22:13 compta kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Um 15:22 Uhr starte ich den Server neu.
Mir ist gerade etwas aufgefallen: Der eth0-Lease wird normalerweise ungefähr jede Minute erneuert, stoppt aber, sobald der Server nicht mehr reagiert.
Antwort1
Wie im vorherigen Kommentar beschrieben, werde ich eine Antwort verfassen, damit Sie sie als richtig markieren können. Das bedeutet, dass niemand vorbeikommt und versucht zu helfen.
Ich schlage vor, dass Sie Swap-Speicher einrichten, um zu testen, ob es sich um ein RAM-Problem handelt. Ich habe ein Tutorial dazuHier, aber das ist etwas ganz Alltägliches und es gibt Hunderte von Ressourcen, die Ihnen erklären, wie das geht.
Antwort2
Einverstanden, die CPU-Guthaben auf einer T2-Instanz zu überprüfen. Die Drosselung kann dieses Verhalten haben.
Schauen Sie sich diesen Link an: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-credits-baseline-concepts.html