Question Flush-0: n process provoquant un goulot d'étranglement massif


J'ai un cluster LAMP qui partage des fichiers via NFS et parfois l'un d'entre eux sera frappé pendant un certain temps lorsque de mystérieux processus de vidage commencent à apparaître.

Quelqu'un peut-il m'aider? Le seul moyen de résoudre ce problème est de redémarrer l'ordinateur. Tuer les processus n'en crée que de nouveaux.

top - 19:43:43 up 104 days,  4:52,  1 user,  load average: 27.15, 56.72, 33.31
Tasks: 301 total,   9 running, 292 sleeping,   0 stopped,   0 zombie
Cpu(s): 15.6%us, 77.0%sy,  0.0%ni,  4.2%id,  2.0%wa,  0.0%hi,  1.2%si,  0.0%st
Mem:   8049708k total,  7060492k used,   989216k free,   157156k buffers
Swap:  4194296k total,   483228k used,  3711068k free,   928768k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                           
840 root      20   0     0    0    0 R 98.0  0.0   6:45.83 flush-0:24                                                                                                        
843 root      20   0     0    0    0 R 97.6  0.0   5:50.32 flush-0:25                                                                                                        
835 root      20   0     0    0    0 R 96.0  0.0   6:42.44 flush-0:22                                                                                                        
836 root      20   0     0    0    0 R 95.0  0.0   6:51.56 flush-0:27                                                                                                        
833 root      20   0     0    0    0 R 94.3  0.0   6:27.21 flush-0:23                                                                                                        
841 root      20   0     0    0    0 R 93.7  0.0   6:46.97 flush-0:26                                                                                                        
2305 apache    20   0  772m  31m  25m S 23.6  0.4   0:07.60 httpd                                                                                                             
2298 apache    20   0  772m  31m  25m S 13.6  0.4   0:08.98 httpd                                                                                                             
26771 apache    20   0  775m  47m  41m S 10.3  0.6   4:07.97 httpd                                                                                                             
2315 apache    20   0  770m  29m  25m S  9.0  0.4   0:07.44 httpd                                                                                                             
24370 memcache  20   0  457m 123m  608 S  8.6  1.6  66:20.28 memcached                                                                                                         
1191 apache    20   0  770m  30m  26m S  8.3  0.4   0:13.54 httpd                                                                                                             
2253 apache    20   0  771m  32m  27m S  8.3  0.4   0:11.75 httpd                                                                                                             
3476 varnish   20   0 52.9g 2.0g  20m S  8.0 25.6   0:15.30 varnishd                                                                                                          
17234 apache    20   0  775m  50m  45m S  7.0  0.6   9:22.09 httpd                                                                                                             
23161 apache    20   0  780m  54m  43m S  7.0  0.7   6:33.40 httpd

Merci


6
2018-01-25 19:50


origine


Est-ce le serveur ou le client NFS qui a ce problème? Quel système de fichiers utilisez-vous? Quelle version de Centos et quel noyau? - ramruma
Y a-t-il quelque chose dans dmesg ou /var/log/messages cette allusion à quelque chose? - R. S.
Est-ce que le problème commence toujours au même moment? At-il un motif? - John Siu


Réponses:


Votre système est surchargé de demandes d’écriture sur disque et de votre configuration. "rapport sale" n'est pas optimal pour votre environnement.

Vous pouvez définir deux paramètres administratifs pour la mémoire virtuelle:

Voici les dirty_background_ratio et dirty_ratio repérable dans /proc/sys/vm/

Ces paramètres représentent un pourcentage de mémoire.

Si vous définissez une valeur basse pour dirty_ratio Vous pouvez obtenir plus de charge sur le disque, mais cela réduirait la consommation de RAM pour la gestion de la mémoire sale.

le dirty_background_ratio est le pourcentage de mémoire résiduelle minimale qui a entraîné l'arrêt de l'écriture de données altérées sur le disque à partir du système. Cela signifie que vous devez trouver le meilleur compromis entre la dimension des morceaux sales pour écrire (processus de rinçage) et la mémoire minimale où le système sera arrêté dans le processus d'écriture.

Relation pour une bonne performance pourrait être:

dirty_ratio 90%
dirty_background_ratio 5%

un ratio moyen:

dirty_ratio 40~50%
dirty_background_ratio 10~20%

Les causes de ce déséquilibre dans votre système peuvent être multiples. L'une des causes les plus courantes est le manque de mémoire vive (RAM) pour la gestion de l'installation. D'autres fois, cela peut simplement être dû à une baisse des performances de la mémoire installée sur votre serveur, allant d'une mauvaise ventilation à une alimentation incorrecte.

Bien que la plupart des problèmes se présentent sous la forme de bogues logiciels, beaucoup d’erreurs non connues sont dues à une mauvaise configuration du matériel par rapport aux services installés. Surtout dans le cas de machines louées.


Pour aider ceux qui sont moins familiers avec les machines Linux, les paramètres mentionnés ci-dessus peuvent être remplacés de la manière suivante:

Mode permanent:
(exécutez ces deux commandes une seule fois, sinon éditez ce fichier avec votre éditeur favori)

# echo "vm.dirty_ratio = 40" >> /etc/sysctl.conf
# echo "vm.dirty_background_ratio = 10" >> /etc/sysctl.conf

Temporairement en mode:

# echo "40" > /proc/sys/vm/dirty_ratio
# echo "10" > /proc/sys/vm/dirty_background_ratio

Vous pouvez trouver plus d'informations sur ces paramètres sur ce lien


7
2018-01-29 00:06





J'ai trouvé le lien suivant avec une discussion similaire:

0005972: La durée maximale et la disponibilité affichent une valeur de charge moyenne incorrecte - CentOS Bug Tracker

au dernier post il dit:

The high load average issue is resolved in a newer version of the hpvsa driver (1.2.4-7) that is now released by HP. Contact HP Support to obtain a copy of the new driver.


1
2018-01-28 18:26



Votre suggestion est longue, OP n'a jamais laissé entendre qu'il est sur du matériel HP. Je préfère me référer à ceci: serverfault.com/questions/341123/… - fuero
c’est le cas, mais j’ai le même problème et j’utilise HP aussi .. - alexus


As tu un EnableMMAP Off dans votre fichier de configuration Apache?

Si vous mappez en mémoire un fichier situé sur un système de fichiers monté sur NFS et un fichier   traiter sur un autre ordinateur client NFS supprime ou tronque le fichier,   votre processus peut obtenir une erreur de bus la prochaine fois qu'il tente d'accéder au   contenu du fichier mappé.

Pour les installations où l'un ou l'autre de ces facteurs s'applique, vous devez   utilisez EnableMMAP off pour désactiver le mappage en mémoire des fichiers livrés.

Je ne sais pas si ce sont les symptômes, mais ça vaut le coup d'essayer


0
2018-01-28 20:44





Si vous avez un système de fichiers ext4, vérifiez ce bogue Lente écrit sur la partition ext4 - INFO: tâche flush-253: 7: 2137 bloquée pendant plus de 120 secondes.qui a été corrigé dans les noyaux récents RHSA-2011-1530 que vous pouvez également obtenir, bien sûr, auprès de Centos.


0
2018-01-28 21:36