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

J'ai un cluster LAMP qui partage des files via NFS et, occasionnellement, l'un d'entre eux sera frappé pendant un certain time lorsque des process de chasse mystérieux commenceront à apparaître.

Quelqu'un peut-il m'aider? La seule façon de résoudre ceci est de redémarrer – le fait de tuer les process ne génère 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

Votre système est surchargé avec des requêtes d'écriture de disque et votre configuration "rapport sale" n'est pas optimale pour votre environnement.

Vous pouvez définir deux parameters administratifs pour la memory virtuelle:

Ce sont les dirty_background_ratio et dirty_ratio localisables dans /proc/sys/vm/

Ces parameters représentent un pourcentage de memory.

Si vous définissez une valeur faible pour dirty_ratio Vous pouvez get plus de charge de disque, mais réduirait la consommation de RAM pour une gestion de memory sale.

La dirty_background_ratio est le pourcentage de memory résiduelle minimale, qui a provoqué l'arrêt de l'écriture de données sales dans le disque du système. Cela signifie que vous devez find le meilleur compromis entre la dimension des morceaux sales pour écrire (process de chasse d'eau) et une memory minimale où le système s'arrêtera dans le process d'écriture.

La 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, parmi les causes les plus courantes, il y a une quantité insuffisante de RAM pour gérer les autres fois installés, cela peut être dû simplement à une baisse des performances de la memory installée sur votre server avec des causes allant de pauvres ventilation à une alimentation incorrecte.

Bien que la plupart des problèmes se présentent sous la forme de bogues de logiciels, il n'est pas connu de plusieurs de ces erreurs en raison de la mauvaise confluración du matériel par rapport aux services installés. Surtout dans le cas des machines louées.


Pour aider ceux less familiers avec les machines Linux, les parameters mentionnés ci-dessus peuvent être remplacés de cette manière:

Mode permanent:
(exécutez ces deux commands une seule fois, sinon modifiez ce file avec votre éditeur préféré)

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

Mode temporaire:

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

Vous pouvez find plus d'informations sur ces parameters sur ce lien

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

0005972: Le haut et le time de disponibilité affichent une valeur moyenne de mauvaise charge – CentOS Bug Tracker

Au dernier message, 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.

Avez-vous un EnableMMAP Off dans votre file de configuration Apache?

Si vous mettez en memory un file situé sur un système de files monté sur NFS et qu'un process sur une autre machine cliente NFS supprime ou tronque le file, votre process peut générer une erreur de bus la prochaine fois qu'il tente d'accéder au contenu du file mappé.

Pour les installations où l'un de ces facteurs s'applique, vous devez utiliser EnableMMAP désactivé pour désactiver le mappage de memory des files livrés.

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

Si vous disposez d'un système de files ext4, vérifiez ce bug. Enregistrements lents à la partition ext4 – INFO: tâche flush-253: 7: 2137 bloquée pendant plus de 120 secondes. qui a été corrigé dans les kernelx récents RHSA-2011-1530 que vous pouvez également get, bien sur, de Centos.