WordPress seems to have killed my Google Compute micro server by using too much memory

Basically I booted a micro server on Google Compute running Debian 8 Jesse and installed MySQL and Apache2 on it just to run a little test site. I'm not developing the theme myself so I don't have any code - I just uploaded a theme I got on themeforest that uses WPBakery to build the pages.

I noticed from the beginning that it was slow - which was fine because this was just a little test server so that my client can see it. I was planning to move it to their current hosting once it's done. However I started to notice that when I was doing a lot of edits it would freeze up occasionally and I would get "Out of Memory" errors in my ssh terminal. Which was again fine - it's just a test site I needed for a couple days to customize the theme. They would usually resolve themselves.

However once the server got stuck and I had to reboot it. That should have been my first sign to at least snapshot the disk. But once it came back up everything was fine and it was even noticeably faster. I figured something got out of hand in the WP backend and restarting the server solved the issue.

I used it for another day or two - then it suddenly stopped working again. But this time I couldn't connect with ssh any more. I rebooted it using the Google Compute GUI but nothing didn't work at all. The usage graph is peaked - and when I log the serial output I get this:

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

And it outputs this about every second or every other second. When I watch the output during boot it looks like it starts shortly after Apache boots. But there's some other messages about a failure above - I'm not really sure what is causing it.

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.

And I have no idea what to do here. I read that this is sometimes cause by overuse of memory which would correlate with the issues I had before - so I tried snapshotting the disk and booting it on a higher RAM server but it does the same thing no matter how high I set the RAM. And I can't ssh in to investigate more.

Does anyone have an idea what the issue might be or how to resolve it? I'm stuck and I'd really like to not have to start from scratch again and remake all the stuff I did before. If I can at the least get a dump of the MySQL database I'd be happy - but the database isn't configured to accept remote connections because I had no reason to do that. So I have to get into it somehow.

0
задан 25 February 2018 в 15:17
1 ответ

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

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

1
ответ дан 4 December 2019 в 15:59

Теги

Похожие вопросы