Cargue la rareza promedio en Linux Ubuntu

En los últimos días he estado tratando de entender la rareza que está sucediendo en nuestra infraestructura, pero no he podido entenderlo así que me dirijo a ustedes para darme algunas pistas.

He estado notando en Graphite, picos en load_avg que ocurren con regularidad mortal aproximadamente cada 2 horas: no son exactamente 2 horas, pero es muy regular. Adjunto una captura de pantalla de esto que tomé de Graphite

Me he quedado atrapado investigando esto; la regularidad de esto me llevó a pensar que es una especie de trabajo cron o algo así, pero NO hay cronjobs ejecutándose en estos servidores; en realidad, estas son máquinas virtuales que se ejecutan en la nube Rackspace. Lo que estoy buscando es algún tipo de indicación de que podría estar causando estos problemas y cómo investigar más a fondo.

Los servidores están bastante inactivos: este es un entorno provisional, por lo que casi no entra tráfico / no debería haber carga en ellos. Estas son las 4 máquinas virtuales de núcleos virtuales. Lo que sé con certeza es que estamos tomando un montón de muestras de grafito cada 10 segundos, pero si esa es la causa de la carga, entonces esperaría que sea constantemente alta en lugar de suceder cada 2 horas en olas en diferentes servidores.

Cualquier ayuda para investigar esto sería muy apreciada.

Aquí hay algunos datos de sar para app01, que es el primer pico azul en la imagen de arriba, no pude sacar ninguna conclusión de los datos. Tampoco es que el pico de escritura de bytes que ves que ocurre cada media hora (NO CADA 2 HORAS) se deba a que el chef-cliente se ejecuta cada 30 minutos. Intentaré recopilar más datos aunque ya lo haya hecho, pero tampoco podría sacar ninguna conclusión de ellos.

CARGA

09:55:01 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
10:05:01 PM         0       125      1.28      1.26      0.86         0
10:15:01 PM         0       125      0.71      1.08      0.98         0
10:25:01 PM         0       125      4.10      3.59      2.23         0
10:35:01 PM         0       125      0.43      0.94      1.46         3
10:45:01 PM         0       125      0.25      0.45      0.96         0
10:55:01 PM         0       125      0.15      0.27      0.63         0
11:05:01 PM         0       125      0.48      0.33      0.47         0
11:15:01 PM         0       125      0.07      0.28      0.40         0
11:25:01 PM         0       125      0.46      0.32      0.34         0
11:35:01 PM         2       130      0.38      0.47      0.42         0
11:45:01 PM         2       131      0.29      0.40      0.38         0
11:55:01 PM         2       131      0.47      0.53      0.46         0
11:59:01 PM         2       131      0.66      0.70      0.55         0
12:00:01 AM         2       131      0.81      0.74      0.57         0

UPC

09:55:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:05:01 PM     all      5.68      0.00      3.07      0.04      0.11     91.10
10:15:01 PM     all      5.01      0.00      1.70      0.01      0.07     93.21
10:25:01 PM     all      5.06      0.00      1.74      0.02      0.08     93.11
10:35:01 PM     all      5.74      0.00      2.95      0.06      0.13     91.12
10:45:01 PM     all      5.05      0.00      1.76      0.02      0.06     93.10
10:55:01 PM     all      5.02      0.00      1.73      0.02      0.09     93.13
11:05:01 PM     all      5.52      0.00      2.74      0.05      0.08     91.61
11:15:01 PM     all      4.98      0.00      1.76      0.01      0.08     93.17
11:25:01 PM     all      4.99      0.00      1.75      0.01      0.06     93.19
11:35:01 PM     all      5.45      0.00      2.70      0.04      0.05     91.76
11:45:01 PM     all      5.00      0.00      1.71      0.01      0.05     93.23
11:55:01 PM     all      5.02      0.00      1.72      0.01      0.06     93.19
11:59:01 PM     all      5.03      0.00      1.74      0.01      0.06     93.16
12:00:01 AM     all      4.91      0.00      1.68      0.01      0.08     93.33

09:55:01 PM       tps      rtps      wtps   bread/s   bwrtn/s
10:05:01 PM      8.88      0.15      8.72      1.21    422.38
10:15:01 PM      1.49      0.00      1.49      0.00     28.48
10:25:01 PM      1.54      0.00      1.54      0.03     29.61
10:35:01 PM      8.35      0.04      8.31      0.32    411.71
10:45:01 PM      1.58      0.00      1.58      0.00     30.04
10:55:01 PM      1.52      0.00      1.52      0.00     28.36
11:05:01 PM      8.32      0.01      8.31      0.08    410.30
11:15:01 PM      1.54      0.01      1.52      0.43     29.07
11:25:01 PM      1.47      0.00      1.47      0.00     28.39
11:35:01 PM      8.28      0.00      8.28      0.00    410.97
11:45:01 PM      1.49      0.00      1.49      0.00     28.35
11:55:01 PM      1.46      0.00      1.46      0.00     27.93
11:59:01 PM      1.35      0.00      1.35      0.00     26.83
12:00:01 AM      1.60      0.00      1.60      0.00     29.87

RED:

10:25:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
10:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:35:01 PM      eth1      7.07      4.77      5.24      2.42      0.00      0.00      0.00
10:35:01 PM      eth0      2.30      1.99      0.24      0.51      0.00      0.00      0.00
10:45:01 PM        lo      8.35      8.35      2.18      2.18      0.00      0.00      0.00
10:45:01 PM      eth1      3.69      3.45      0.65      2.22      0.00      0.00      0.00
10:45:01 PM      eth0      1.50      1.33      0.15      0.36      0.00      0.00      0.00
10:55:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:55:01 PM      eth1      3.66      3.40      0.64      2.19      0.00      0.00      0.00
10:55:01 PM      eth0      0.79      0.87      0.08      0.29      0.00      0.00      0.00
11:05:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:05:01 PM      eth1      7.29      4.73      5.25      2.41      0.00      0.00      0.00
11:05:01 PM      eth0      0.82      0.89      0.09      0.29      0.00      0.00      0.00
11:15:01 PM        lo      8.34      8.34      2.18      2.18      0.00      0.00      0.00
11:15:01 PM      eth1      3.67      3.30      0.64      2.19      0.00      0.00      0.00
11:15:01 PM      eth0      1.27      1.21      0.11      0.34      0.00      0.00      0.00
11:25:01 PM        lo      8.32      8.32      2.18      2.18      0.00      0.00      0.00
11:25:01 PM      eth1      3.43      3.35      0.63      2.20      0.00      0.00      0.00
11:25:01 PM      eth0      1.13      1.09      0.10      0.32      0.00      0.00      0.00
11:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:35:01 PM      eth1      7.16      4.68      5.25      2.40      0.00      0.00      0.00
11:35:01 PM      eth0      1.15      1.12      0.11      0.32      0.00      0.00      0.00
11:45:01 PM        lo      8.37      8.37      2.18      2.18      0.00      0.00      0.00
11:45:01 PM      eth1      3.71      3.51      0.65      2.20      0.00      0.00      0.00
11:45:01 PM      eth0      0.75      0.86      0.08      0.29      0.00      0.00      0.00
11:55:01 PM        lo      8.30      8.30      2.18      2.18      0.00      0.00      0.00
11:55:01 PM      eth1      3.65      3.37      0.64      2.20      0.00      0.00      0.00
11:55:01 PM      eth0      0.74      0.84      0.08      0.28      0.00      0.00      0.00

Para personas curiosas sobre cronjobs. Aquí está el resumen de todos los cronjobs configurados en el servidor (elegí app01 pero esto también está sucediendo en algunos otros servidores con la misma configuración de cronjobs)

$ ls -ltr /etc/cron*
-rw-r--r-- 1 root root  722 Apr  2  2012 /etc/crontab

/etc/cron.monthly:
total 0

/etc/cron.hourly:
total 0

/etc/cron.weekly:
total 8
-rwxr-xr-x 1 root root 730 Dec 31  2011 apt-xapian-index
-rwxr-xr-x 1 root root 907 Mar 31  2012 man-db

/etc/cron.daily:
total 68
-rwxr-xr-x 1 root root  2417 Jul  1  2011 popularity-contest
-rwxr-xr-x 1 root root   606 Aug 17  2011 mlocate
-rwxr-xr-x 1 root root   372 Oct  4  2011 logrotate
-rwxr-xr-x 1 root root   469 Dec 16  2011 sysstat
-rwxr-xr-x 1 root root   314 Mar 30  2012 aptitude
-rwxr-xr-x 1 root root   502 Mar 31  2012 bsdmainutils
-rwxr-xr-x 1 root root  1365 Mar 31  2012 man-db
-rwxr-xr-x 1 root root  2947 Apr  2  2012 standard
-rwxr-xr-x 1 root root   249 Apr  9  2012 passwd
-rwxr-xr-x 1 root root   219 Apr 10  2012 apport
-rwxr-xr-x 1 root root   256 Apr 12  2012 dpkg
-rwxr-xr-x 1 root root   214 Apr 20  2012 update-notifier-common
-rwxr-xr-x 1 root root 15399 Apr 20  2012 apt
-rwxr-xr-x 1 root root  1154 Jun  5  2012 ntp

/etc/cron.d:
total 4
-rw-r--r-- 1 root root 395 Jan  6 18:27 sysstat
$ sudo ls -ltr /var/spool/cron/crontabs 
total 0
$

Como puede ver, no hay cronjobs HORARIOS. Solo diariamente / semanalmente, etc.

He reunido un montón de estadísticas (vmstat, mpstat, iostat); por mucho que lo intento, simplemente no puedo ver ninguna pista que sugiera un mal comportamiento de cualquier componente de VM ... Estoy empezando a inclinarme hacia posibles problemas en el hipervisor. Siéntase libre de echar un vistazo a las estadísticas La esencia comienza con la salida sar -q alrededor del tiempo "ofensivo" y luego puede ver vm, mp y iostats ...

Básicamente sigue siendo un misterio total para mí ...

— milosgajdos
fuente

¿Tiene algún dato interactivo que pueda compartir para investigar más a fondo (es decir, ¿qué muestran 'top', 'htop' e 'iotop' durante los picos de carga recurrentes)? Además, ¿ha revisado los registros de su aplicación durante los tiempos en cuestión para ver si exhiben algún comportamiento extraño? Además, ¿tiene hosts con configuraciones similares que no estén alojadas en la infraestructura de la nube pública y, de ser así, muestran un comportamiento similar?

— esquireofoz

En términos de registros de aplicaciones, no sucede nada. Las únicas entradas de registro que contiene son verificaciones de monitoreo que ocurren cada minuto, básicamente el sistema de monitoreo llega al sitio principal e informa el código de resultado, aparte de que los registros están completamente vacíos. Además, como puede ver, hay una variedad de hosts arriba: esto está sucediendo en todos ellos (redis, servidor de aplicaciones, servidor de chef, etc.)

— milosgajdos

¿Has intentado usar psacct para reducirlo ?

— HTTP500

asume la regularidad, pero los datos que muestra no muestran picos que sucedan regularmente ... por favor sea más específico en cuanto al período exacto en el que muestra la regularidad (¿quizás durante varios días? en la imagen, no hay regularidad). ejecute un "top -n 1" cada 1 millón más o menos y manténgalos en un archivo, y esto podría ayudar a ver qué otros procesos compiten por la CPU al mismo tiempo que ocurre un pico. Si App1 es una aplicación con conexión a Internet, ¿tal vez es solo alguien que tiene acceso a ella y forza ese comportamiento? agregue un registro regular "netstat -an" también (¿cada minuto?)

— Olivier Dulac

¿Viste la captura de pantalla adjunta? Si eso no se muestra regularmente, no sé qué hace. Ahora he aumentado el período de muestreo para sar, así que estoy muestreando cada 5 minutos. La regularidad en la foto es más que obvia: ocurre cada dos horas. Este es un entorno de ensayo sin tráfico en absoluto, como seguramente puede ver en las salidas sar anteriores para las estadísticas de red.

— milosgajdos

Interesante.

En primer lugar, ¿puede aumentar la frecuencia del registro sar? En lugar de 10 minutos, intente iniciar sesión cada minuto. El cronjob de sysstat es configurable.

A continuación, intente escribir los siguientes comandos.

ps auxf > /tmp/ps.out
vmstat 1 50 > /tmp/vm.out
mpstat -P ALL 1 50 > /tmp/mp.out
iostat -xdk 1 50 > /tmp/io.out
cat /proc/meminfo > /tmp/meminfo.out

Reúna este conjunto de datos en cada iteración cuando el promedio de carga aumente manualmente o mediante cron. Sería bueno tener datos de al menos un día hábil completo.

Ahora, entiendo que los servidores están inactivos pero aún algunas aplicaciones deben estar ejecutándose. ¿Qué son?

¿Es posible que pueda ejecutar alguna herramienta de creación de perfiles, como perf u oprofile?

¿Se ha cambiado algún componente de hardware del servidor? Incluso algo tan inocuo como una actualización de firmware o una actualización de software.

Hola, una pregunta. ¿Cuál es el planificador que está ejecutando? Creo que es cfq, cualquier posibilidad de que pueda cambiarlo a noop. Ponga elevator=noopel parámetro de línea de comando del núcleo y reinicie el sistema y vea si lo mejora.

— Soham Chakraborty
fuente

Agregué una pequeña edición sobre el planificador. Por favor vea el resultado.

— Soham Chakraborty

Procesos principales de registro

Dado que la ocurrencia es muy regular, configure el trabajo cron para monitorear los principales procesos durante ese período

#app01
20-59 0/2 * * * root /usr/bin/top -b -n 1 | /usr/bin/head -n 15 >> /var/log/top.log

Cambiar 20-59a *registrará toda la hora por cada número par horas. El trabajo de Cron se ejecutará una vez por minuto en cualquier caso.

Es posible que desee agregar el archivo top.log al registro de rotación para que no ocupe todo el espacio en caso de que olvide deshabilitarlo.

Verificar archivo de registro

Buscar entradas de archivo de registro en el período de carga alta

Tome la siguiente entrada de carga como ejemplo

10:25:01 PM         0       125      4.10      3.59      2.23         0

Hacer

grep ' 22:2' /var/log/*
grep ' 22:2' /var/log/apache2/*

Eso mostrará todas las entradas de registro para 22:2x:xx. Puede que tenga que incluir otros directorios de registro.

Dom 6 de enero 21:00:07 2013: xvda w_await spike

Gráfico xvda - El pico de w_await es el domingo 6 de enero 21:00:07 2013 ingrese la descripción de la imagen aquí

— John Siu
fuente

Una cosa que definitivamente verificaría:

vSphere grafica para el mismo patrón, tal vez otra VM en el mismo host está consumiendo las CPU (por lo tanto, la carga en su VM aumenta a medida que toma más tiempo procesar la misma cantidad de datos con un flujo constante debido a que hay menos tiempo de CPU disponible para tu VM).

Editar: no lo obtuve la primera vez :) Está ejecutando en Rackspace, por lo que no tiene control sobre el hipervisor, sin embargo, podría valer la pena preguntar a rackspace si podrían verificar si este patrón es común en otras máquinas virtuales en el mismo host .

— Martino Dino
fuente

Sospecho de eso también: no sería la primera vez que la nube Rackspace estaría causando algún tipo de locura. Sin embargo, dudo que supervisen cualquiera de sus servidores de hipervisor; quiero decir, en términos de mal comportamiento de las máquinas virtuales, sin embargo, me gustaría descartar cualquier posibilidad "interna" antes de recurrir al último recurso: soporte de Rackspace.

— milosgajdos

¿El rendimiento del hipervisor afectaría el promedio de carga aparente de una VM? Esto me lleva a pensar en cómo se calcula el promedio de carga. ¿Es posible que esto sea un efecto de la función de ahorro de energía / verde que periódicamente cambia el trabajo a menos núcleos desconocidos para el sistema operativo? ¿O qué tal cambiar dinámicamente la frecuencia de reloj basada, por ejemplo, en datos ambientales?

— trp

El promedio de carga se calcula mediante el algoritmo de programación, en palabras simples, si tiene 100 tareas en su cola de procesamiento y el hipervisor es 100% eficiente en la ejecución de 10 tareas por 1 segundo, entonces necesita 10 segundos para ejecutar 100 tareas, si su hipervisor es solo un 50% eficiente (tal vez un sobreaprovisionamiento de la CPU), llevará 20 segundos ejecutar la misma cantidad de tareas, lo que lleva a una mayor carga. Explicación completa: blog.scoutapp.com/articles/2009/07/31/…

— Martino Dino