¡Hola gurús superiores del servidor!
Estoy ejecutando un servidor Ubuntu que aloja un servicio Apache Tomcat junto con una base de datos MySQL. La carga del servidor siempre es cercana a cero, incluso durante las horas más ocupadas de la semana. A pesar de eso, experimento cuelgues aleatorios 1 o 2 veces por semana, donde todo el servidor deja de responder.
Un efecto interesante de este bloqueo es que todos los cronjobs parecen ejecutarse más tarde de lo programado, al menos eso es lo que indican las marcas de tiempo en varios registros del sistema. Por lo tanto, me parece que de hecho es todo el servidor el que se congela, no solo el software personalizado que se ejecuta como parte del servicio Tomcat. El bloqueo normalmente dura entre 3 y 5 minutos y luego todo vuelve a la normalidad.
Hardware:
Model: Dell PowerEdge R720, 16 cores, 16 GB ram
HDD-configuration: Raid-1 (mirror)
Main services:
apache tomcat, mysql, ssh/sftp
#uname -a
Linux es2 2.6.24-24-server #1 SMP Tue Jul 7 19:39:36 UTC 2009 x86_64 GNU/Linux
Al ejecutar sysstat, puedo ver picos enormes tanto en la carga promedio como en las esperas de bloques de disco que corresponden exactamente al momento en que los clientes informaron problemas con el sistema backend. A continuación se muestra un gráfico del uso del disco de sar con un pico muy obvio alrededor de las 12:30 p.m.
Mis más sinceras disculpas por poner esto en un servidor externo, pero mi representante es demasiado bajo para incluir archivos aquí directamente. También tuve que juntarlos ya que solo puedo publicar un enlace :S
Parcelas sar:http://213.115.101.5/abba/tmpdata/sardata_es.jpg
Gráfico 1: Espera de bloque, observe cómo el % de utilidad sube al 100 % aproximadamente en 12,58
Gráfico 2: Transferencia en bloque, nada inusual aquí.
Gráfico 3: Carga media, picos junto con el gráfico 1
Gráfico 4: Uso de CPU, todavía cercano al 0%.
Gráfico 5: Memoria, nada inusual aquí
¿Alguien tiene alguna idea de qué podría causar este efecto en un sistema? Como expliqué anteriormente, el único software que se ejecuta en el servidor es un servidor Tomcat con una interfaz SOAP, para permitir a los usuarios conectarse a la base de datos. Las aplicaciones remotas también se conectan al servidor a través de SSH para extraer y cargar archivos. En las horas punta, supongo que tenemos alrededor de 50 conexiones SSH/SFTP simultáneas y no más de 1 a 200 conexiones a través de http (soap/tomcat).
Buscando en Google encontré discusiones sobre identificadores de archivos y de inodos, pero creo que son normales para los núcleos 2.6.x. ¿Alguien que no esté de acuerdo?
cat /proc/sys/fs/file-nr
1152 0 1588671
cat /proc/sys/fs/inode-state
11392 236 0 0 0 0 0
Al mismo tiempo, "sar -v" muestra estos valores para el momento del cuelgue anterior, pero el número de inodo aquí SIEMPRE es muy alto en comparación con el anterior.
12:40:01 dentunusd file-nr inode-nr pty-nr
12:40:01 40542 1024 15316 0
12:45:01 40568 1152 15349 0
12:50:01 40587 768 15365 0
12:55:01 40631 1024 15422 0
13:01:02 40648 896 15482 0
13:05:01 40595 768 15430 0
13:10:01 40637 1024 15465 0
He visto esto en dos servidores independientes que ejecutan la misma configuración de hardware, sistema operativo, software, configuración de raid, etc. Por lo tanto, quiero creer que depende más del software/configuración que del hardware.
Muchas gracias por tu tiempo
/Ebbe
Respuesta1
Los problemas estaban relacionados con un problema de incompatibilidad entre Ubuntu 8.04 LTS (Hardy) y el controlador RAID PERC 6/i de Dell, como se informa en este error:https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607167 La actualización a Ubuntu 10.04 LTS Lucid (kernel 2.6.32) resuelve el problema.
En caso de que alguien más tenga los mismos problemas.
Respuesta2
Es posible que esté ejecutando alguna consulta pesada que esté realizando un escaneo completo de la tabla. ¿Ha revisado su registro de consultas lentas?
Si ese es el caso, simplemente agregue los índices adecuados.
PD: Lo siento si ya lo has hecho.