Basicamente eu inicializei um micro servidor no Google Compute rodando Debian 8 Jesse e instalei MySQL e Apache2 nele apenas para rodar um pequeno site de teste. Não estou desenvolvendo o tema sozinho, então não tenho nenhum código - acabei de enviar um tema que comprei no themeforest que usa WPBakery para construir as páginas.
Percebi desde o início que estava lento - o que foi bom porque era apenas um pequeno servidor de teste para que meu cliente pudesse vê-lo. Eu estava planejando movê-lo para a hospedagem atual assim que terminar. No entanto, comecei a notar que, quando fazia muitas edições, ele congelava ocasionalmente e recebia erros de "Sem memória" no meu terminal ssh. O que foi novamente bom - é apenas um site de teste que precisei por alguns dias para personalizar o tema. Eles geralmente se resolveriam sozinhos.
No entanto, uma vez que o servidor travou e tive que reiniciá-lo. Esse deveria ter sido meu primeiro sinal para pelo menos tirar um instantâneo do disco. Mas assim que voltou, tudo ficou bem e foi ainda visivelmente mais rápido. Achei que algo estava fora de controle no back-end do WP e reiniciar o servidor resolveu o problema.
Usei-o por mais um ou dois dias - então, de repente, ele parou de funcionar novamente. Mas desta vez não consegui mais me conectar ao ssh. Eu reiniciei usando a GUI do Google Compute, mas nada funcionou. O gráfico de uso atingiu o pico - e quando registro a saída serial, recebo o seguinte:
Feb 25 12:47:05 test-wrs systemd[1]: Looping too fast. Throttling execution a little.
E isso gera isso a cada segundo ou a cada dois segundos. Quando observo a saída durante a inicialização, parece que ela começa logo após a inicialização do Apache. Mas há algumas outras mensagens sobre uma falha acima - não tenho certeza do que está causando isso.
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.
E não tenho ideia do que fazer aqui. Eu li que isso às vezes é causado pelo uso excessivo de memória, o que se correlacionaria com os problemas que tive antes - então tentei tirar um instantâneo do disco e inicializá-lo em um servidor de RAM mais alto, mas ele faz a mesma coisa, não importa o quão alto eu configurei a RAM. E não posso entrar para investigar mais.
Alguém tem uma ideia de qual pode ser o problema ou como resolvê-lo? Estou preso e realmente gostaria de não ter que começar do zero novamente e refazer todas as coisas que fiz antes. Se eu conseguir pelo menos um dump do banco de dados MySQL, ficaria feliz - mas o banco de dados não está configurado para aceitar conexões remotas porque não tinha motivo para fazer isso. Então eu tenho que entrar nisso de alguma forma.
Responder1
Quanto ao motivo de sua configuração ficar sem memória, só podemos especular. O fato de o problema não desaparecer com uma VM maior sugere que isso é causado por algum problema de configuração ou configuração. Você pode tentar executar oConfiguração do Wordpress pré-configurada pelo Google, que pode ser encontrado em "Deployment Manager" "Cloud Launcher". Você pode executá-los em qualquer tamanho de VM e, por experiência própria, posso garantir que a instalação básica não fica sem memória. Para recuperar seu banco de dados, você pode fazer o seguinte: 1. desligar a VM no Developers Console 2. tirar um instantâneo do disco 3. anexar o instantâneo como disco adicional a uma VM em funcionamento (escolha a opção: criar um novo disco -de snapshot) Execute as etapas acima no Developers Console e não se esqueça de clicar no botão "salvar" no final. Agora clique no botão "ssh" da nova VM e
4. monte este disco adicional na linha de comando:
sudo mount /dev/sdb1 /mnt
Observação: você pode executar essas etapas na VM criada por meio do Cloud Launcher e copiar os arquivos diretamente para esta VM.