Похоже, WordPress убил мой микросервер Google Compute, используя слишком много памяти

Похоже, WordPress убил мой микросервер Google Compute, используя слишком много памяти

По сути, я загрузил микросервер на Google Compute с Debian 8 Jesse и установил на нем MySQL и Apache2, чтобы запустить небольшой тестовый сайт. Я не разрабатываю тему сам, поэтому у меня нет кода — я просто загрузил тему, которую нашел на themeforest, которая использует WPBakery для создания страниц.

Я заметил с самого начала, что он медленный — и это было нормально, потому что это был всего лишь небольшой тестовый сервер, чтобы мой клиент мог его видеть. Я планировал перенести его на их текущий хостинг, как только он будет готов. Однако я начал замечать, что когда я делал много правок, он время от времени зависал, и я получал ошибки «Недостаточно памяти» в моем терминале ssh. Что, опять же, было нормально — это всего лишь тестовый сайт, который мне нужен был на пару дней, чтобы настроить тему. Обычно они решались сами собой.

Однако однажды сервер завис и мне пришлось его перезагрузить. Это должно было быть моим первым знаком, чтобы хотя бы сделать снимок диска. Но как только он снова заработал, все было в порядке, и даже заметно быстрее. Я решил, что что-то вышло из-под контроля в бэкэнде WP, и перезапуск сервера решил проблему.

Я использовал его еще день или два - затем он внезапно снова перестал работать. Но на этот раз я больше не мог подключиться по ssh. Я перезагрузил его с помощью Google Compute GUI, но ничего не работало вообще. График использования достиг пика - и когда я регистрирую последовательный вывод, я получаю это:

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

И он выводит это примерно каждую секунду или каждую вторую секунду. Когда я смотрю вывод во время загрузки, кажется, что он начинается вскоре после загрузки Apache. Но есть и другие сообщения о сбое выше — я не совсем уверен, что его вызывает.

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.

И я понятия не имею, что тут делать. Я читал, что это иногда бывает вызвано чрезмерным использованием памяти, что коррелирует с проблемами, которые у меня были раньше, поэтому я попробовал сделать снимок диска и загрузить его на сервере с большим объемом оперативной памяти, но он делает то же самое, независимо от того, насколько высокий объем оперативной памяти я установил. И я не могу зайти по ssh, чтобы разобраться подробнее.

Есть ли у кого-нибудь идеи, в чем может быть проблема или как ее решить? Я застрял и мне бы очень не хотелось начинать все с нуля и переделывать все, что я делал раньше. Если бы я мог хотя бы получить дамп базы данных MySQL, я был бы счастлив, но база данных не настроена на прием удаленных подключений, потому что у меня не было причин это делать. Так что мне нужно как-то в нее попасть.

решение1

Что касается того, почему ваша настройка выходит за пределы памяти, мы можем только предполагать. Тот факт, что проблема не исчезает с большей виртуальной машиной, предполагает, что это вызвано какой-то проблемой конфигурации или настройки. Вы можете попробовать запуститьНастройка Wordpress, предварительно настроенная Google, который можно найти в разделе "Deployment Manager" "Cloud Launcher". Вы можете запустить их на виртуальной машине любого размера, и по опыту могу вас заверить, что базовая установка не выйдет за пределы памяти. Чтобы восстановить базу данных, вы можете сделать следующее: 1. выключить виртуальную машину из Developers Console 2. сделать снимок диска 3. присоединить снимок как дополнительный диск к работающей виртуальной машине (выберите опцию: создать новый диск -из снимка) Выполните указанные выше шаги в Developers Console и не забудьте нажать кнопку "сохранить" в конце. Теперь нажмите кнопку "ssh" новой виртуальной машины и
4. смонтировать этот дополнительный диск в командной строке: sudo mount /dev/sdb1 /mnt

Примечание: вы можете выполнить эти шаги из виртуальной машины, которую вы развернули с помощью Cloud Launcher, и скопировать файлы непосредственно в эту виртуальную машину.

Связанный контент