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
[[email protected] /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
[[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
La monture ressemble
[[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, j'ai essayé d'installer réglé et de le régler sur les performances de débit.
[[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 ]
mount?tuned-adm profile enterprise-storagecommande pour gérer le nobarrier et le commutateur de délai. Que montre ladmesg|tailsortie? Voyez-vous des délais d'expiration d'E / S?Réponses:
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 laps 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 destuned-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.la source
3a0613065fa Adaptec \ 71605 \ SATA/SAS RAIDj'ai vérifié, ce sont aussi des disques SATAWestern Digital WD RE WD4000FYYZecho 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.Le problème n'est clairement pas un problème lié au disque. Et cela ressort clairement de l'entretoise pendue:
/ 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.
la source
/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.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.
la source
Ceci est un autre correctif.
On dirait que nous utilisons le contrôleur de raid suivant
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.
la source