ps aux suspendu sur un processeur / IO élevé avec des processus java


13

J'ai des problèmes avec le processus java et les vérifications nrpe. Nous avons certains processus qui utilisent parfois 1000% de CPU sur un système à 32 cœurs. Le système est assez réactif jusqu'à ce que vous fassiez

ps aux 

ou essayez de faire quoi que ce soit dans le / proc / pid # comme

[root@flume07.domain.com /proc/18679]# ls
hangs..

Une bande 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,

le processus java fonctionne et se terminera très bien, mais le problème est que notre surveillance devient folle, les processus de réflexion sont arrêtés car il expire en attendant la fin d'un ps aux.

J'ai essayé de faire quelque chose comme

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

sans chance

ÉDITER

Spécifications du système

  • Processeur Intel (R) Xeon (R) 32 cœurs E5-2650 0 à 2,00 GHz
  • 128gig de bélier
  • 12 disques 4 To 7200
  • CentOS 6.5
  • Je ne suis pas sûr du modèle mais le vendeur est SuperMicro

La charge lorsque cela se produit est d'environ 90-160ish pendant 1 minute.

La partie étrange est que je peux aller dans n'importe quel autre / proc / pid # et cela fonctionne très bien. Le système est réactif lorsque je ssh. Comme lorsque nous sommes alertés d'une charge élevée, je peux ssh très bien.

Un autre montage

J'utilise la date limite pour le planificateur

[root@dn07.domain.com ~]# 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

La monture ressemble

[root@dn07.manage.com ~]# 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, j'ai essayé d'installer réglé et de le régler sur les performances de débit.

[root@dn07.domain.com ~]# 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  ]

Pouvez-vous fournir des informations sur l'environnement du serveur? La distribution et la version du système d'exploitation, la plate-forme matérielle seraient pertinentes.
ewwhite

La charge de votre système au moment où cela se produit est également importante.
ewwhite

J'ai fait quelques modifications avec les spécifications et la charge
Mike

À quoi ressemble la sortie de mount?
ewwhite

Très bien. Pensez à utiliser la tuned-adm profile enterprise-storagecommande pour gérer le nobarrier et le commutateur de délai. Que montre la dmesg|tailsortie? Voyez-vous des délais d'expiration d'E / S?
ewwhite

Réponses:


8

En général, j'ai vu cela se produire à cause d'une lecture au point mort. Ceci est confirmé par votre stracesortie. La tentative de lecture du fichier / proc / xxxx / cmdline se bloque pendant l'exécution de la ps auxcommande.

Les pics momentanés d'E / S affaiblissent les ressources du système. Une charge de 90-160 est une très mauvaise nouvelle si elle est liée au sous-système de stockage.

Pour la matrice de stockage, pouvez-vous nous dire s'il y a un contrôleur RAID matériel en place? L'application principale sur le serveur est-elle biaisée en écriture? Les disques que vous mentionnez (12 x 4 To) sont des disques SAS ou SATA nearline à faible vitesse. S'il n'y a aucune forme de mise en cache d'écriture devant la baie de disques, les écritures sont capables de pousser la charge du système vers le haut. S'il s'agit de disques SATA purs sur un fond de panier Supermicro, ne négligez pas la possibilité d'autres problèmes de disque ( délais d'attente, disque défaillant, fond de panier, etc. ). Cela se produit-il sur tous les nœuds Hadoop?

Un test simple consiste à essayer de fonctionner iotoppendant que cela se produit. De plus, comme c'est EL6.5, avez-vous des tuned-admparamètres activés? Les barrières d'écriture sont-elles activées?

Si vous n'avez pas modifié l'élévateur d'E / S du serveur, cela ionicepeut avoir un impact. Si vous l'avez changé en autre chose que CFQ , ( ce serveur devrait probablement être dans les délais ), ionicecela ne fera aucune différence.

Éditer:

Une autre chose étrange que j'ai vue dans les environnements de production. Ce sont des processus Java, et je suppose qu'ils sont fortement multithread. Comment allez-vous sur les PID? Quelle est la sysctlvaleur de kernel.pid_max ? J'ai eu des situations où j'ai épuisé des PID auparavant et j'ai eu une charge élevée résultante.

Vous mentionnez également la version 2.6.32-358.23.2.el6.x86_64 du noyau . Cela fait plus d'un an et fait partie de la version CentOS 6.4, mais le reste de votre serveur est 6.5. Avez-vous mis la liste des mises à jour du noyau sur yum.conf? Vous devriez probablement être sur le noyau 2.6.32-431.xx ou plus récent pour ce système. Il pourrait y avoir un énorme problème de pages avec l'ancien noyau que vous avez . Si vous ne pouvez pas changer le noyau, essayez de les désactiver avec:

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


il y a une carte raid mais elle est juste utilisée pour gérer 12 disques sur le serveur. Cela fait partie d'un cluster Hadoop, il écrit donc beaucoup, mais ces verrous se mettent en place lorsque le fil tire beaucoup de données pour une tâche de réduction de carte.
Mike

Je demande au centre de données de m'appeler pour voir s'ils savent à quoi le contrôleur de raid est configuré pour le cache d'écriture. Quant à la carte, c'est un que 3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID j'ai vérifié, ce sont aussi des disques SATA Western Digital WD RE WD4000FYYZ
Mike

1
@mike Si vous ne pouvez pas modifier le noyau, essayez: echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabledsur une machine affectée. Je suppose que cela est suffisamment reproductible pour que vous puissiez observer un avant / après avec ce paramètre.
ewwhite

4
ressemble à l'écoute et la désactivation de l'énorme page a aidé à résoudre le problème!
Mike

1
@Mike Excellent. Une mise à jour du noyau peut également apporter un certain soulagement. Mais si vous êtes bloqué avec le noyau en cours d'exécution, je suis content que ce correctif fonctionne.
ewwhite

3

Le problème n'est clairement pas un problème lié au disque. Et cela ressort clairement de l'entretoise pendue:

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

/ proc est une interface entre le noyau et l'espace utilisateur. Il ne touche pas du tout au disque. Si quelque chose est pendu lors de la lecture des arguments d'une commande, il s'agit généralement d'un problème lié au noyau, et peu probable d'un problème de stockage. Voir le commentaire @kasperd.

La charge n'est qu'un effet secondaire du problème et le nombre élevé ne raconte pas toute l'histoire. Vous pourriez avoir un serveur avec une charge très élevée sur laquelle l'application se comporte sans aucun problème.

Vous pouvez obtenir plus d'informations sur ce qui se passe cat /proc/$PID/stack. Où $PIDest l'ID de processus où la lecture s'arrête.

Dans votre cas, je commencerais par une mise à niveau du noyau.


2
Tu te trompes. Ce qui est retourné par la lecture /proc/%d/cmdlineest la partie de l'espace d'adressage du processus dans laquelle le noyau a stocké la ligne de commande pendant l' execveappel. Comme toute autre partie de l'espace utilisateur, elle peut être remplacée. L'accès peut donc en effet devoir attendre que la page soit à nouveau échangée.
kasperd

C'est un très bon argument. Merci de vous être levé. Cependant, je pense que les chances que Strace commence lorsque votre échange ne répond pas sont faibles, mais pas impossibles. Je mettrai à jour ma réponse.
Mircea Vutcovici

2

Donc, même avec tous les ajustements et une mise à niveau vers le dernier noyau 2.6 fourni par CentOS, nous voyions toujours les blocages. Pas autant qu'avant mais toujours en les voyant.

Le correctif consistait à mettre à niveau le noyau de la série 3.10.x que CentOS fournit dans son référentiel centosplus ici

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

Cela a supprimé tous les blocages d'arbre de processus. Comme je l'ai dit, le système n'était pas sous une charge folle où l'exécution de nouveaux processus n'était pas rapide. Donc, la plupart sont un problème de noyau 2.6 quelque part.


0

Ceci est un autre correctif.

On dirait que nous utilisons le contrôleur de raid suivant

Adaptec 71605

J'ai effectué des mises à jour du firmware de toutes les machines concernées vers la dernière version et cela semble résoudre le problème.

Nous avons dû rétrograder à partir de l'expérience du noyau 3.10 en raison d'autres problèmes aléatoires lors de l'installation de 3.10 sur CentOS 6, mais la mise à niveau du micrologiciel semble résoudre le problème.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.