WordPress parece haber matado mi microservidor Google Compute al usar demasiada memoria

WordPress parece haber matado mi microservidor Google Compute al usar demasiada memoria

Básicamente, inicié un microservidor en Google Compute con Debian 8 Jesse e instalé MySQL y Apache2 solo para ejecutar un pequeño sitio de prueba. No estoy desarrollando el tema yo mismo, así que no tengo ningún código; acabo de subir un tema que obtuve en themeforest que usa WPBakery para crear las páginas.

Desde el principio noté que era lento, lo cual estuvo bien porque era solo un pequeño servidor de prueba para que mi cliente pudiera verlo. Estaba planeando trasladarlo a su alojamiento actual una vez que esté listo. Sin embargo, comencé a notar que cuando estaba haciendo muchas ediciones, ocasionalmente se congelaba y aparecían errores de "Memoria insuficiente" en mi terminal ssh. Lo cual nuevamente estuvo bien: es solo un sitio de prueba que necesitaba durante un par de días para personalizar el tema. Por lo general, se resolverían solos.

Sin embargo, una vez el servidor se atascó y tuve que reiniciarlo. Esa debería haber sido mi primera señal para al menos tomar una instantánea del disco. Pero una vez que volvió a funcionar todo estuvo bien y fue incluso notablemente más rápido. Pensé que algo se salió de control en el backend de WP y reiniciar el servidor resolvió el problema.

Lo usé durante uno o dos días más y, de repente, dejó de funcionar otra vez. Pero esta vez ya no pude conectarme con ssh. Lo reinicié usando la GUI de Google Compute pero nada funcionó en absoluto. El gráfico de uso alcanza su punto máximo y cuando registro la salida en serie obtengo esto:

Feb 25 12:47:05 test-wrs systemd[1]: Looping too fast. Throttling execution a little.

Y genera esto aproximadamente cada segundo o cada dos segundos. Cuando miro el resultado durante el arranque, parece que comienza poco después de que arranca Apache. Pero hay algunos otros mensajes arriba sobre una falla; no estoy realmente seguro de qué lo está causando.

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.

Y no tengo idea de qué hacer aquí. Leí que esto a veces se debe al uso excesivo de la memoria, lo que se correlacionaría con los problemas que tuve antes, así que intenté tomar una instantánea del disco y arrancarlo en un servidor con mayor RAM, pero hace lo mismo sin importar qué tan alta configuré la RAM. Y no puedo entrar para investigar más.

¿Alguien tiene una idea de cuál podría ser el problema o cómo resolverlo? Estoy estancado y realmente me gustaría no tener que empezar de cero otra vez y rehacer todo lo que hice antes. Si al menos puedo obtener un volcado de la base de datos MySQL, sería feliz, pero la base de datos no está configurada para aceptar conexiones remotas porque no tenía ningún motivo para hacerlo. Así que tengo que abordarlo de alguna manera.

Respuesta1

En cuanto a por qué su configuración se queda sin memoria, sólo podemos especular. El hecho de que el problema no desaparezca con una máquina virtual más grande sugiere que esto se debe a algún problema de configuración. Podrías intentar ejecutar elConfiguración de Wordpress preconfigurada por Google, que se puede encontrar en "Administrador de implementación", "Lanzador de nube". Puede ejecutarlos en cualquier tamaño de VM y por experiencia puedo asegurarle que la instalación básica no se queda sin memoria. Para recuperar su base de datos, puede hacer lo siguiente: 1. apagar la VM desde Developers Console 2. tomar una instantánea del disco 3. adjuntar la instantánea como disco adicional a una VM que funcione (elija la opción: crear un nuevo disco -desde instantánea) Realice los pasos anteriores en Developers Console y no olvide hacer clic en el botón "guardar" al final. Ahora haga clic en el botón "ssh" de la nueva VM y
4. monte este disco adicional en la línea de comando: sudo mount /dev/sdb1 /mnt

Nota: puede realizar estos pasos desde la máquina virtual que activa a través de Cloud Launcher y copiar los archivos directamente a esta máquina virtual.

información relacionada