A veces me he encontrado con que un servidor va muy, muy lento, hasta el punto de que hasta cuesta teclear en la pantalla. Eso ya son casos extremos, pero no he visto ningún proceso que esté consumiendo demasiada CPU. Un día, incluso, me encontré con un servidor que estaba consumiendo un 40% de CPU pero el load estaba en 200!!!!
Sí, es raro pero, ¿por qué pasan cosas así?
Echémosle la culpa al servidor VMWare ESX, que estaba saturadísimo. Me explico:
Cuando en un servidor virtual comienzan a encolarse peticiones en la CPU y, por lo tanto, el load aumenta, puede deberse a que realmente hay un proceso que es un gran consumidor de CPU o que las CPUs virtuales tardan mucho en poder adquirir las CPUs físicas.
El segundo caso es justo lo que me encontré ese día.
La métrica de CPU ready de VMWare que aparece en la imagen anterior está indicando que las CPUs virtuales están tardando 13 segundos en adquirir a las CPUs físicas. En incidencias de mucha lentitud, he llegado a ver hasta 60 segundos.
Son tiempos realmente inaceptables. Los tiempos correctos deberían ser de unos pocos milisegundos.
Hasta que todas las CPUs virtuales no tengan acceso a las físicas, el servidor virtual no realizará ninguna acción (de CPU) y las peticiones se encolarán (en CPU).
A veces es mejor reducir el número de CPUs virtuales
A algunos clientes le sorprende que para mejorar el rendimiento de un servidor virtual es conveniente bajar el número de CPUs virtuales de cuatro a dos, por ejemplo.
El motivo es que, si tras analizar el consumo de CPU, realmente vemos que no se necesitan cuatro CPUs virtuales, es mejor reducirlas a dos (si el consumo lo permite) porque dos CPUs virtuales tardan menos que cuatro en adquirir las CPUs físicas.
CPU Steal (CPU Robada)
Con el comando top de Linux podemos ver el parámetro CPU steal, que es el porcentaje de CPU que la maquina virtual está demandando pero el hypervisor no le está dando porque está realizando otras tareas.
[root@liocsux1 init.d]# top
top - 12:03:09 up 19:34, 2 users, load average: 0.46, 0.41, 0.28
Tasks: 329 total, 2 running, 326 sleeping, 0 stopped, 1 zombie
Cpu(s): 2.1%us, 0.6%sy, 0.0%ni, 97.1%id, 0.2%wa, 0.0%hi, 0.0%si, 13.1%st
Mem: 16333484k total, 15681836k used, 651648k free, 627268k buffers
Swap: 16777212k total, 0k used, 16777212k free, 7869332k cachedVeremos que este porcentaje crecerá si la métrica de CPU Ready crece. En este ejemplo, vemos que es de un 13.1% (13.0%st).
Con el comando vmstat podemos saber si hay muchos procesos corriendo o esperando para ejecutarse, en la columna «r»:
r: The number of runnable processes (running or waiting for run time).
man del comando vmstat
Otros motivos por los que podemos tener un LOAD alto
- Tenemos poca potencia de cálculo para la cantidad de procesos que necesitamos ejecutar. Las CPUs no dan abasto y se comienzan a encolar procesos, provocando un load alto.
- Tenemos procesos en estado «defunct». Estos los mataremos con un «kill -9» y veremos como baja el load. Al fin y al cabo, son procesos que no estaban haciendo nada.
- Tenemos procesos bloqueados. Por ejemplo, si hemos lanzado varios «df -k» o comandos que se quedan esperando respuesta de entrada/salida, hacia un filesystem que no responde, como podría ser un NFS que se ha caído. Estos procesos también se quedan esperando indefinidamente sin hacer nada, incrementando el load del servidor.
Te puede interesar
Mi pasión por la tecnología me lleva constantemente a explorar las últimas tendencias y aplicaciones, buscando siempre formas de implementar soluciones innovadoras que mejoren la eficiencia. En puerto53.com comparto contenido valioso para ayudar a otros profesionales y entusiastas de la informática a navegar y dominar el complejo mundo de la tecnología. Mi especialidad en Linux RedHat.
Más sobre mí en el este enlace,
