Im Grunde habe ich einen Mikroserver auf Google Compute mit Debian 8 Jesse gestartet und MySQL und Apache2 darauf installiert, nur um eine kleine Testseite zu betreiben. Ich entwickle das Theme nicht selbst, also habe ich keinen Code – ich habe einfach ein Theme hochgeladen, das ich auf Themeforest habe und das WPBakery zum Erstellen der Seiten verwendet.
Mir fiel von Anfang an auf, dass es langsam war – was in Ordnung war, da dies nur ein kleiner Testserver war, damit mein Kunde es sehen konnte. Ich hatte vor, es auf ihr aktuelles Hosting zu verschieben, sobald es fertig ist. Allerdings bemerkte ich, dass es bei vielen Änderungen gelegentlich einfror und ich in meinem SSH-Terminal „Out of Memory“-Fehler bekam. Was wiederum in Ordnung war – es ist nur eine Testsite, die ich für ein paar Tage brauchte, um das Design anzupassen. Normalerweise lösten sich diese Probleme von selbst.
Einmal blieb der Server jedoch hängen und ich musste ihn neu starten. Das hätte für mich ein erstes Zeichen sein sollen, zumindest einen Snapshot der Festplatte zu erstellen. Aber als er wieder hochfuhr, war alles in Ordnung und er war sogar merklich schneller. Ich dachte, irgendetwas im WP-Backend sei außer Kontrolle geraten und ein Neustart des Servers löste das Problem.
Ich habe es noch ein oder zwei Tage benutzt – dann funktionierte es plötzlich wieder nicht mehr. Aber dieses Mal konnte ich keine Verbindung mehr per SSH herstellen. Ich habe es über die Google Compute-GUI neu gestartet, aber nichts funktionierte. Das Nutzungsdiagramm ist auf dem Höhepunkt – und wenn ich die serielle Ausgabe protokolliere, erhalte ich Folgendes:
Feb 25 12:47:05 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
Und es gibt dies etwa jede Sekunde oder jede zweite Sekunde aus. Wenn ich mir die Ausgabe während des Bootvorgangs anschaue, sieht es so aus, als würde es kurz nach dem Booten von Apache beginnen. Aber es gibt noch einige andere Meldungen über einen Fehler oben – ich bin mir nicht wirklich sicher, was ihn verursacht.
Feb 25 12:44:48 test-wrs systemd[1]: Started ACPI event daemon.
Feb 25 12:44:48 test-wrs systemd[1]: Started System Logging Service.
Feb 25 12:44:48 test-wrs systemd[1]: Started Expand the root partition and filesystem on boot.
Feb 25 12:44:48 test-wrs systemd[1]: Started /etc/rc.local Compatibility.
Feb 25 12:44:48 test-wrs systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE
Feb 25 12:44:48 test-wrs systemd[1]: Failed to start Login Service.
Feb 25 12:44:48 test-wrs systemd[1]: Unit systemd-logind.service entered failed state.
Feb 25 12:44:48 test-wrs systemd[1]: Started LSB: Start and stop the mysql database server daemon.
[ OK ] Started Permit User Sessions.
Feb 25 12:44:48 test-wrs systemd[1]: Started LSB: Start NTP daemon.
Feb 25 12:44:48 test-wrs systemd[1]: Started LSB: Apache2 web server.
Feb 25 12:44:48 test-wrs systemd[1]: dbus.service: main process exited, code=exited, status=1/FAILURE
Feb 25 12:44:48 test-wrs systemd[1]: Unit dbus.service entered failed state.
Feb 25 12:44:49 test-wrs systemd[1]: Started Permit User Sessions.
Feb 25 12:44:49 test-wrs systemd[1]: Time has been changed
Feb 25 12:44:49 test-wrs systemd[1]: systemd-logind.service has no holdoff time, scheduling restart.
Feb 25 12:44:50 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
Feb 25 12:44:51 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
Feb 25 12:44:52 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
Feb 25 12:44:54 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
Und ich habe keine Ahnung, was ich hier tun soll. Ich habe gelesen, dass dies manchmal durch übermäßige Speicherbeanspruchung verursacht wird, was mit den Problemen korreliert, die ich vorher hatte – also habe ich versucht, einen Snapshot der Festplatte zu erstellen und sie auf einem Server mit mehr RAM zu booten, aber es passiert dasselbe, egal, wie hoch ich den RAM einstelle. Und ich kann mich nicht per SSH anmelden, um weitere Untersuchungen durchzuführen.
Hat jemand eine Idee, was das Problem sein könnte oder wie man es löst? Ich stecke fest und möchte nicht wieder von vorne anfangen und alles neu machen müssen, was ich vorher gemacht habe. Wenn ich zumindest einen Dump der MySQL-Datenbank bekommen könnte, wäre ich glücklich – aber die Datenbank ist nicht so konfiguriert, dass sie Remoteverbindungen akzeptiert, weil ich keinen Grund dazu hatte. Also muss ich irgendwie da reinkommen.
Antwort1
Warum Ihr Setup nicht genügend Arbeitsspeicher hat, können wir nur spekulieren. Die Tatsache, dass das Problem bei einer größeren VM nicht verschwindet, lässt darauf schließen, dass dies durch ein Konfigurations- oder Setup-Problem verursacht wird. Sie können versuchen, denVon Google vorkonfiguriertes Wordpress-Setup, die unter „Deployment Manager“ „Cloud Launcher“ zu finden sind. Sie können sie auf VMs jeder Größe ausführen und aus Erfahrung kann ich Ihnen versichern, dass bei der Basisinstallation der Arbeitsspeicher nicht ausgeht. Um Ihre Datenbank wiederherzustellen, können Sie Folgendes tun: 1. Fahren Sie die VM über die Entwicklerkonsole herunter. 2. Erstellen Sie einen Snapshot der Festplatte. 3. Hängen Sie den Snapshot als zusätzliche Festplatte an eine funktionierende VM an (wählen Sie die Option: Erstellen Sie eine neue Festplatte – aus Snapshot). Führen Sie die obigen Schritte in der Entwicklerkonsole aus und vergessen Sie nicht, am Ende auf die Schaltfläche „Speichern“ zu klicken. Klicken Sie nun auf die Schaltfläche „SSH“ der neuen VM und
4. mounten Sie diese zusätzliche Festplatte über die Befehlszeile:
sudo mount /dev/sdb1 /mnt
Hinweis: Sie können diese Schritte von der VM aus ausführen, die Sie über Cloud Launcher starten, und die Dateien direkt auf diese VM kopieren.