Encontré un problema peculiar relacionado con mi instancia de base de datos MariaDB (versión 10.2) que hace que mi servicio MariaDB se detenga inesperadamente. Intenté investigar el problema registrando periódicamente el uso de RAM de los 3 procesos principales cada minuto usando un cronjob, con el objetivo de determinar si MariaDB consume memoria excesiva antes de que el servidor falle. Sin embargo, después de realizar esta investigación, me inclino a creer que el uso excesivo de RAM no es la causa principal del problema.
Además, cada vez que el servidor falla, intento revisar los registros de MariaDB usando los siguientes comandos:
sudo cat /var/log/mariadb/mariadb.log- Este comando no arroja resultados.sudo systemctl status mariadb -l- Este comando produce el siguiente resultado:
Además, aquí hay una captura de pantalla de la información del sistema operativo:
[someuser ~]$ uname -a
Linux ec2.internal .amzn2.x86_64 #1 SMP Thu Dec 8 01:29:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[someuser ~]$ hostnamectl
Static hostname: <ip>.ec2.internal
Icon name: computer-vm
Chassis: vm
Machine ID: -
Boot ID: -
Virtualization: xen
Operating System: Amazon Linux 2
CPE OS Name: cpe:2.3:o:amazon:amazon_linux:2
Kernel: Linux <ip>.amzn2.x86_64
Architecture: x86-64
Agradecería mucho su ayuda para diagnosticar y resolver este problema de estabilidad del servidor. Cualquier información y orientación sobre cómo proceder sería invaluable.
Respuestas al comentario de @NikitaKipriyanov: Hola @NikitaKipriyanov, gracias por las preguntas. Siguiendo tu consejo corrí dmesg -T | grep mysqly descubrí esto (pegando solo los datos relevantes):
[Mon Sep 18 17:37:34 2023] [ 26231] 27 26231 29965 52 61440 0 0 mysql-prepare-d
[Tue Sep 19 14:04:29 2023] [ 26839] 27 26839 367222 19121 630784 0 0 mysqld
[Tue Sep 19 14:04:31 2023] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=mysqld,pid=26839,uid=27
[Tue Sep 19 14:04:31 2023] Out of memory: Killed process 26839 (mysqld) total-vm:1468888kB, anon-rss:76484kB, file-rss:0kB, shmem-rss:0kB, UID:27 pgtables:616kB oom_score_adj:0
[Tue Sep 19 14:05:41 2023] [ 29800] 27 29800 2326 26 61440 0 0 mysql-check-soc
[Tue Sep 19 14:05:52 2023] [ 29800] 27 29800 2326 26 61440 0 0 mysql-check-soc
Como podemos ver, la fecha y la hora coinciden un poco con el momento en que el servicio dejó de funcionar. Algo que quiero mencionar es que cuando ejecuto dmesg -TI veo más a menudo que el servidor web httpd ha fallado:
[Tue Sep 19 14:13:00 2023] [ 30195] 0 30195 143596 2011 839680 0 0 httpd
[Tue Sep 19 14:13:00 2023] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=httpd,pid=28937,uid=48
[Tue Sep 19 14:13:00 2023] Out of memory: Killed process 28937 (httpd) total-vm:628120kB, anon-rss:11732kB, file-rss:0kB, shmem-rss:96kB, UID:48 pgtables:860kB oom_score_adj:0
[Tue Sep 19 14:13:17 2023] systemd-journald[30073]: Received SIGTERM from PID 1 (systemd).
Sin embargo, el servidor web nunca ha experimentado fallas o interrupciones en su funcionamiento. El problema sólo afecta al servicio MariaDB. El problema llega de vez en cuando sólo al servicio MariDB, por ejemplo, cada 3 a 5 días. Estos son los únicos registros que solo tengo en la carpeta /var/log/mariadb:
[root@ip mariadb]# ls -la
total 28
drwxr-x--- 2 mysql mysql 146 Sep 20 03:48 .
drwxr-xr-x 10 root root 4096 Sep 26 03:23 ..
-rw------- 1 mysql mysql 0 Sep 20 03:48 mariadb.log
-rw------- 1 mysql mysql 8714 Sep 7 12:40 mariadb.log-20230908
-rw------- 1 mysql mysql 2005 Sep 15 18:02 mariadb.log-20230916.gz
-rw------- 1 mysql mysql 1917 Sep 18 17:39 mariadb.log-20230919.gz
-rw------- 1 mysql mysql 1909 Sep 19 14:16 mariadb.log-20230920.gz
[root@ip mariadb]# pwd
/var/log/mariadb
Aquí también está el resultado de sysctl -A | grep panic:
[root@ip log]# sysctl -A | grep panic
fs.xfs.panic_mask = 0
kernel.hardlockup_panic = 0
kernel.hung_task_panic = 0
kernel.panic = 30
kernel.panic_on_io_nmi = 0
kernel.panic_on_oops = 0
kernel.panic_on_rcu_stall = 0
kernel.panic_on_unrecovered_nmi = 0
kernel.panic_on_warn = 0
kernel.panic_print = 0
kernel.softlockup_panic = 0
kernel.unknown_nmi_panic = 0
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.eth0.stable_secret"
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
vm.panic_on_oom = 0
Respuestas a las preguntas de Wilson Hauck:
Respecto a la RAM:
[ec2-user@ip ~]$ free -h
total used free shared buff/cache available
Mem: 964M 333M 197M 724K 433M 451M
Swap: 0B 0B 0B
SELECT COUNT(*) FROM information_schema.tables;- 238
SHOW GLOBAL STATUS;- Devuelve demasiadas filas para pegarlas aquí, ¿qué valor está buscando?
SHOW GLOBAL VARIABLES;- Mismo
¿Cómo debo enviar el resultado de todas las consultas solicitadas?
Respuesta1
¿Recibo un premio por acertar?
Hay muchas respuestas aquí y en otros lugares de Internet sobre cómo abordar este problema. Lamentablemente muchos de ellos están equivocados. Si mencionan oom_adj o oom_score_adj, esta NO es la forma de solucionar el problema.
Hay 2 cosas que debes hacer.
La primera es observar la configuración de su servidor web y la base de datos (y presumiblemente también hay algún nivel de aplicación aquí) para asegurarse de que no intenten utilizar más RAM de la que tiene disponible. Como no nos habló sobre el servidor de aplicaciones ni sobre el servidor web, realmente no puedo aconsejarle (pero aquí estáuna pista para Apache antes de la bifurcación, opcionalmente con PHP). En cuanto a Mariadb, ve a buscar una copia demysqltuner.ply ejecútelo en su instalación.
Esto debería evitar que te quedes sin memoria la mayor parte del tiempo, pero también deberías reducir la cantidad de memoria inexistente que entregará el kernel:
sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=20
...y pruebe con valores más bajos para la proporción si todavía ve OOM Killer.