Estoy ejecutando una instancia t2.micro en Amazon Linux AMI 2018.03 (4.14.59-64.43.amzn1.x86_64). Aloja un sitio web php usando Apache/2.4.33 y se conecta a una base de datos RDS MySQL.
De vez en cuando, el servidor "desaparece" por completo. Intentar mostrar el sitio web, conectarse al FTP o incluso conectarse en SSH con PuTTY genera un tiempo de espera. Y no vuelve por sí solo, tengo que apagar manualmente el servidor a través de la consola de AWS e iniciarlo nuevamente, luego todo vuelve a la normalidad. (Curiosamente, el comando "reiniciar" no hace nada y parece ser ignorado por el servidor. Sólo funciona apagarlo y reiniciarlo)
El problema es que revisé todos los archivos de registro que pude encontrar y no parece haber nada en absoluto cuando el servidor deja de responder, así que no tengo idea de cómo solucionar el problema. Al verificar las métricas de Cloudwatch, el uso de la CPU y la red también parece ser normal mientras el servidor no responde.
Esto parece suceder cuando estoy ejecutando un script PHP particular con mucha memoria varias veces (pero aleatoriamente, también puedo ejecutar este script sin problemas), por lo que sospecho que podría estar relacionado con el llenado de RAM. Pero si el sistema estuviera cerrando algo para liberar memoria, ¿no aparecería en los registros?
¿Cómo se haría la depuración en una situación como esta?
Gracias
Esto es lo único en el registro de mensajes sobre la última aparición:
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 es cuando reinicio el servidor.
Me acabo de dar cuenta de algo: la concesión eth0 generalmente se renueva ~ cada minuto, pero se detiene una vez que el servidor deja de responder.
Respuesta1
Según el comentario anterior, buscaré una respuesta para que puedas marcar como correcta. Esto significa que la gente no vendrá a intentar ayudar.
Le sugiero que configure algo de espacio de intercambio para probar si se trata de un problema de RAM. tengo un tutorial de como hacerloaquí, pero es algo muy común, por lo que hay cientos de recursos que le indican cómo hacerlo.
Respuesta2
Se acordó verificar los créditos de la CPU en una instancia t2. La aceleración puede tener ese comportamiento.
Mira este enlace: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-credits-baseline-concepts.html