ps aux colgando en alta cpu / IO con procesos java

13

Tengo algunos problemas con el proceso de Java y las comprobaciones de nrpe. Tenemos algunos procesos que a veces usan 1000% de CPU en un sistema de 32 núcleos. El sistema responde bastante bien hasta que haces un

ps aux

o intente hacer algo en / proc / pid # like

[[email protected] /proc/18679]# ls
hangs..

Una capa de ps aux

stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/dev/pts1", 0x7fffb8526f00)       = -1 ENOENT (No such file or directory)
stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
readlink("/proc/15693/fd/2", "/dev/pts/1", 127) = 10
stat("/dev/pts/1", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
write(1, "root     15693 15692  0 06:25 pt"..., 55root     15693 15692  0 06:25 pts/1    00:00:00 ps -Af
) = 55
stat("/proc/18679", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/18679/stat", O_RDONLY)      = 5
read(5, "18679 (java) S 1 18662 3738 3481"..., 1023) = 264
close(5)                                = 0
open("/proc/18679/status", O_RDONLY)    = 5
read(5, "Name:\tjava\nState:\tS (sleeping)\nT"..., 1023) = 889
close(5)                                = 0
open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

el proceso de Java está funcionando y se completará bien, pero el problema es que hace que nuestro monitoreo se vuelva loco.

He intentado hacer algo como

 nice -19 ionice -c1 /usr/lib64/nagios/plugins/check_procs -w 1:1 -c 1:1 -a 'diamond' -u root -t 30

sin suerte

EDITAR

Especificaciones del sistema

  • CPU de 32 núcleos Intel (R) Xeon (R) E5-2650 0 @ 2.00GHz
  • 128gig de ram
  • 12 unidades de 4Tb 7200
  • CentOS 6.5
  • No estoy seguro del modelo pero el vendedor es SuperMicro

La carga cuando esto sucede es alrededor de 90-160ish por 1 minuto.

La parte extraña es que puedo entrar en cualquier otro / proc / pid # y funciona bien. El sistema responde cuando hago un ssh. Al igual que cuando nos alertan de una gran carga, puedo hacer un ssh bien.

Otra edición

He estado usando la fecha límite para el planificador

[[email protected] ~]# for i in {a..m}; do cat /sys/block/sd${i}/queue/scheduler; done
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq

Mount se parece a

[[email protected] ~]# mount
/dev/sda3 on / type ext4 (rw,noatime,barrier=0)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/sdb1 on /disk1 type xfs (rw,nobarrier)
/dev/sdc1 on /disk2 type xfs (rw,nobarrier)
/dev/sdd1 on /disk3 type xfs (rw,nobarrier)
/dev/sde1 on /disk4 type xfs (rw,nobarrier)
/dev/sdf1 on /disk5 type xfs (rw,nobarrier)
/dev/sdg1 on /disk6 type xfs (rw,nobarrier)
/dev/sdh1 on /disk7 type xfs (rw,nobarrier)
/dev/sdi1 on /disk8 type xfs (rw,nobarrier)
/dev/sdj1 on /disk9 type xfs (rw,nobarrier)
/dev/sdk1 on /disk10 type xfs (rw,nobarrier)
/dev/sdl1 on /disk11 type xfs (rw,nobarrier)
/dev/sdm1 on /disk12 type xfs (rw,nobarrier)

Ok, intenté instalar sintonizado y configurarlo para el rendimiento de rendimiento. 

[[email protected] ~]# tuned-adm profile throughput-performance
Switching to profile 'throughput-performance'
Applying deadline elevator: sda sdb sdc sdd sde sdf sdg sdh[  OK  ] sdk sdl sdm
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf:                                [  OK  ]
Calling '/etc/ktune.d/tunedadm.sh start':                  [  OK  ]
Applying sysctl settings from /etc/sysctl.d/99-chef-attributes.conf
Applying sysctl settings from /etc/sysctl.conf
Starting tuned:                                            [  OK  ]
linux centos java cpu-usage high-load Miguel
fuente
¿Puede proporcionar información sobre el entorno del servidor? La distribución del sistema operativo y la versión, la plataforma de hardware serían relevantes.
ewwhite
La carga de su sistema en el momento en que esto sucede también es importante.
ewwhite
Hice algunas ediciones con especificaciones y cuál es la carga
Mike
¿Cómo se ve la salida de mount?
ewwhite
Muy bien. Considere usar el tuned-adm profile enterprise-storagecomando para manejar el interruptor de nobarrier y la fecha límite. ¿Qué dmesg|tailmuestra la salida? ¿Estás viendo tiempos de espera de E / S?
ewwhite

Respuestas:

8

En general, he visto que esto suceda debido a una lectura estancada. Esto es confirmado por su stracesalida. El intento de leer / proc / xxxx / cmdline se bloquea mientras ejecuta el ps auxcomando.

Los picos momentáneos en E / S están privando a los recursos del sistema. Una carga de 90-160 es una noticia extremadamente mala si está relacionada con el subsistema de almacenamiento.

Para la matriz de almacenamiento, ¿puede decirnos si hay un controlador RAID de hardware? ¿La aplicación principal en el servidor está sesgada? Los discos que menciona (12 x 4 TB) son discos SAS o SATA nearline de baja velocidad. Si no hay forma de almacenamiento en caché de escritura frente a la matriz de unidades, las escrituras son capaces de empujar la carga del sistema hacia arriba. Si se trata de unidades SATA puras en una placa posterior Supermicro, no descarte la posibilidad de otros problemas de disco ( tiempos de espera, unidad defectuosa, placa posterior, etc. ) ¿Esto sucede en todos los nodos de Hadoop?

Una prueba fácil es intentar correr iotopmientras esto sucede. Además, como se trata de EL6.5, ¿tiene alguna de las tuned-admconfiguraciones habilitadas? ¿Están habilitadas las barreras de escritura?

Si no ha cambiado el elevador de E / S del servidor, ionicepuede tener un impacto. Si lo ha cambiado a otro que no sea CFQ , ( este servidor probablemente debería estar en la fecha límite ), ioniceno hará ninguna diferencia.

Editar:

Otra cosa extraña que he visto en entornos de producción. Estos son procesos Java, y supongo que son muy multiproceso. ¿Cómo te va con los PID? ¿Cuál es el sysctlvalor para kernel.pid_max ? He tenido situaciones en las que antes agotaba los PID y tenía una carga alta resultante.

Además, usted menciona la versión del kernel 2.6.32-358.23.2.el6.x86_64 . Tiene más de un año y es parte de la versión CentOS 6.4, pero el resto de su servidor es 6.5. ¿Has puesto en la lista negra las actualizaciones del kernel en yum.conf? Probablemente debería estar en el kernel 2.6.32-431.xx o más reciente para ese sistema. Podría haber un problema de páginas enormes con el núcleo anterior que tiene . Si no puede cambiar el núcleo, intente deshabilitarlos con:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled.

ewwhite
fuente
hay una tarjeta raid pero solo se usa para manejar 12 unidades en el servidor. Es parte de un clúster de Hadoop, por lo que escribe mucho, pero también estos bloqueos se implementan cuando el hilo extrae una gran cantidad de datos para un trabajo de reducción de mapas.
Mike
Estoy haciendo que el centro de datos me llame para ver si saben a qué está configurado el controlador RAID para la caché de escritura. En cuanto a la tarjeta 3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID , verifiqué que también son unidades SATA Western Digital WD RE WD4000FYYZ
Mike
1
@mike Si no puede hacer el cambio de kernel, intente: echo never > /sys/kernel/mm/redhat_transparent_hugepage/enableden una máquina afectada. Supongo que esto es lo suficientemente reproducible como para que pueda observar un antes / después con esta configuración.
ewwhite
44
Parece que la sintonización y la desactivación de la página enorme ayudaron a solucionar el problema.
Mike
1
@ Mike excelente. Una actualización del núcleo también puede proporcionar algo de alivio. Pero si está atascado con el kernel en ejecución, me alegra que esta solución funcione.
ewwhite
3

El problema es claro, no un problema relacionado con el disco. Y esto queda claro por la cadena ahorcada:

open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

/ proc es una interfaz entre el núcleo y el espacio de usuario. No toca el disco en absoluto. Si algo se cuelga leyendo los argumentos de un comando, generalmente es un problema relacionado con el kernel y es poco probable que sea uno de almacenamiento. Ver el comentario de @kasperd.

La carga es solo un efecto secundario del problema y el alto número no cuenta la historia completa. Podría tener un servidor con una carga muy alta en el que la aplicación se comporta sin ningún problema técnico.

Puede obtener más información sobre lo que está sucediendo cat /proc/$PID/stack. ¿Dónde $PIDestá la ID del proceso donde se detiene la lectura?

En su caso, comenzaría con una actualización del kernel.

Mircea Vutcovici
fuente
2
Estás equivocado. Lo que es devuelto por la lectura /proc/%d/cmdlinees la parte del espacio de direcciones del proceso en el que el núcleo almacena la línea de comandos durante la execvellamada. Al igual que cualquier otra parte del espacio del usuario, puede intercambiarse. Por lo tanto, acceder a él puede tener que esperar a que se vuelva a intercambiar la página.
kasperd
Este es un muy buen argumento. Gracias por levantarte. Sin embargo, creo que las posibilidades de que strace comience cuando su intercambio no responde son bajas, pero no imposibles. Actualizaré mi respuesta.
Mircea Vutcovici
2

Entonces, incluso con todos los ajustes y una actualización al último kernel 2.6 que proporciona CentOS, todavía estábamos viendo los bloqueos. No tanto como antes, pero todavía los veo.

La solución fue actualizar al núcleo de la serie 3.10.x que CentOS proporciona en su repositorio centosplus aquí

http://mirror.centos.org/centos/6/xen4/x86_64/Packages/

Esto ha eliminado todos los bloqueos del árbol de procesos. Como dije, el sistema no estaba bajo una carga loca donde ejecutar nuevos procesos no era rápido. Entonces, la mayoría será un problema de kernel 2.6 en alguna parte.

Miguel
fuente
0

Esta es otra solución.

Parece que estamos ejecutando el siguiente controlador de incursión

Adaptec 71605

He estado haciendo actualizaciones de firmware para todas las máquinas afectadas a la última versión y parece estar aclarando el problema.

Tuvimos que bajar del experimento del kernel 3.10 debido a otros problemas aleatorios al instalar 3.10 en CentOS 6, pero la actualización del firmware parece solucionar el problema.

Miguel
fuente