Estou executando uma instância t2.micro no Amazon Linux AMI 2018.03 (4.14.59-64.43.amzn1.x86_64). Ele hospeda um site php usando Apache/2.4.33 e se conecta a um banco de dados RDS MySQL.
De vez em quando, o servidor “desaparece” completamente. Tentar exibir o site, conectar-se ao FTP ou até mesmo conectar-se ao SSH com PuTTY resulta em um tempo limite. E não volta sozinho, tenho que desligar manualmente o servidor através do console AWS e reiniciá-lo, então tudo volta ao normal. (Curiosamente, o comando "reboot" não faz nada e parece ser ignorado pelo servidor. Apenas desligá-lo e reiniciá-lo funciona)
O problema é que verifiquei todos os arquivos de log que encontrei e não parece haver nada no momento em que o servidor para de responder, então não tenho ideia de como solucionar o problema. Verificando as métricas do Cloudwatch, o uso da CPU e da rede também parece normal enquanto o servidor não está respondendo.
Isso parece acontecer quando estou executando um script PHP específico com muita memória várias vezes (mas aleatoriamente, também posso executar esse script sem problemas), então suspeito que possa estar relacionado ao preenchimento da RAM. Mas se o sistema estivesse fechando algo para liberar memória, isso não apareceria nos logs?
Como alguém faria a depuração em uma situação como essa?
Obrigado
Aqui está a única coisa no log de mensagens em torno da última ocorrência:
Sep 6 15:11:34 compta dhclient[2266]: PRC: Renewing lease on eth0.
Sep 6 15:11:34 compta dhclient[2266]: XMT: Renew on eth0, interval 10970ms.
Sep 6 15:11:34 compta dhclient[2266]: RCV: Reply message on eth0 from ****::***:****:****:****.
Sep 6 15:11:34 compta ec2net: [get_meta] Trying to get http://***.***.***.***/latest/meta-data/network/interfaces/macs/**:**:**:**:**:**/local-ipv4s
Sep 6 15:11:34 compta ec2net: [rewrite_aliases] Rewriting aliases of eth0
Sep 6 15:11:34 compta ec2net: [get_meta] Trying to get http://***.***.***.***/latest/meta-data/network/interfaces/macs/**:**:**:**:**:**/subnet-ipv4-cidr-block
Sep 6 15:22:13 compta kernel: imklog 5.8.10, log source = /proc/kmsg started.
Sep 6 15:22:13 compta rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2356" x-info="http://www.rsyslog.com"] start
Sep 6 15:22:13 compta kernel: [ 0.000000] Linux version 4.14.59-64.43.amzn1.x86_64 (mockbuild@gobi-build-64010) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #1 SMP Thu Aug 2 21:29:33 UTC 2018
Sep 6 15:22:13 compta kernel: [ 0.000000] Command line: root=LABEL=/ console=tty1 console=ttyS0 selinux=0 LANG=en_US.UTF-8 KEYTABLE=us
Sep 6 15:22:13 compta kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
15:22 é quando reinicio o servidor.
Acabei de perceber uma coisa: a concessão eth0 geralmente é renovada ~ a cada minuto, mas para quando o servidor para de responder.
Responder1
De acordo com o comentário anterior, recorrerei a uma resposta para que você possa marcar como correto. Isso significa que as pessoas não virão tentar ajudar.
Sugiro que você configure algum espaço de troca para testar se é um problema de RAM. tenho um tutorial de como fazer issoaqui, mas é algo muito comum, por isso existem centenas de recursos que informam como fazer isso.
Responder2
Concordou em verificar os créditos de CPU em uma instância t2. O estrangulamento pode ter esse comportamento.
Confira este link: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-credits-baseline-concepts.html