Comment trouver la cause de l'augmentation de la charge du serveur

12

J'ai des problèmes de chargement avec mon serveur et même si je suis un administrateur Linux quelque peu expérimenté, je n'ai plus d'idées maintenant.

Le problème est une charge lentement mais régulièrement croissante sur le serveur sans aucune cause apparente.

Le serveur est un processeur AMD Athlon (tm) 64 X2 Dual Core 6000+ avec 6 Go de RAM. Il exécute Debian Stable avec Linux gir 2.6.26-2-amd64 # 1 SMP mer 19 août 22:33:18 UTC 2009 x86_64 GNU / Linux.

Le serveur exécute essentiellement Lighttpd, plusieurs processus PHP FastCGI et une base de données MySQL. Tâches typiques du serveur Web.

Le CPU n'est jamais vraiment complètement utilisé et la mémoire est principalement utilisée pour les tampons et le cache, ce qui est bien. J'ai essayé de redémarrer les différents services pour voir si l'un d'eux diminuerait à nouveau la charge, mais sans chance.

Voici des graphiques montrant la charge, le CPU et IOStat:

La question est donc la suivante: qu'est-ce qui pourrait provoquer une charge lentement mais toujours croissante? Et comment savoir ce qui est responsable?

Mise à jour: J'ai oublié de mentionner que lorsque je redémarrerai le serveur, la charge sera réduite à environ 0,3 à 0,6 et recommencera à grimper lentement au cours des prochaines semaines.

linux

— Andreas Gohr
source

1

Les images que vous avez publiées n'existent plus. N'hésitez pas à les télécharger à nouveau si vous en avez encore des copies.

— Michael Hampton

6

Chaque processus zombie ajoute 1.0 à la charge. Vous pourriez voir une accumulation de zombies.

Oui. Vérifiez le graphique " Nombre de processus ".

— Teddy

Si c'était correct, la saisie for N in {1..100} ; do sleep 60 & done ; exec sleep 500devrait suffire à provoquer une charge élevée. Mais ce n'est pas le cas. Cette commande produit 100 zombies, mais la charge sur mon ordinateur est restée inférieure à 1.

— kasperd

5

J'ai trouvé un excellent indice en réponse à une autre question .

La recherche de processus dans l'état «D» montre quatre processus PHP qui semblent se bloquer pendant un certain temps correspondant aux «étapes» de la courbe de charge:

#> ps aux | awk '$8 ~ /D/  { print $0 }'
wiki      6651  0.0  0.0      0     0 ?        D    Oct04   0:41 [php-cgi]
bugs      6731  0.0  0.0      0     0 ?        D    Oct27   0:14 [php-cgi]
manpages  7536  0.0  0.0      0     0 ?        D    Oct30   0:21 [php5-cgi]
wiki     23847  0.0  0.0      0     0 ?        D    Oct06   1:32 [php-cgi]

Donc, cela semble être le problème. Je dois maintenant savoir pendant que ces processus se bloquent et comment y remédier. Merci tout le monde.

— Andreas Gohr
source

Cette réponse a résolu mon problème. La charge passe de 0,5 à 350 et continue d'augmenter. C'était dû à des processus zombies essayant de lire un dossier distant supprimé.

— Philippe Delteil

2

Je suppose que le serveur est privé d'IO, peut-être que vous devriez ajouter les statistiques iotop aux graphiques

Je me demande si vous pouvez avoir une activité io par application qui est également un facteur pour la charge du serveur

http://rt.wiki.kernel.org/index.php/I/Otop_utility

l'autre outil est dstat

— Mariuz
source

J'ai également ajouté des graphiques pour IOStat. Le disque IO n'augmente pas comme le fait la charge. C'est bien ce que vous visiez?

— Andreas Gohr,

Oh et dstat semble utile. Je dois en lire un peu plus.

— Andreas Gohr

2

S'il s'agissait d'E / S, il verrait alors l'iowait (rose) sur les graphiques du processeur.

— 3molo
source

0

Ce genre de problèmes provenait souvent du disque dur qui n'est pas assez rapide pour servir les données requises par la base de données MySQL et le serveur HTTP. Vous devriez regarder la commande iostat

IO me semble normal. Et cela n'expliquerait pas pourquoi la charge augmente lentement.

— Andreas Gohr

-1

En général, ce n'est pas une mauvaise chose d'avoir une charge de serveur élevée; cela signifie que vous n'êtes pas assis au ralenti et que vous faites moins que vous ne le pourriez autrement. Une charge de 80% à 90% de votre capacité totale (avec une pièce "éclatée") est ce qui est généralement recherché. Je recommanderais de vérifier la sortie de mpstat et vmstat. En particulier, les 2 premiers chiffres de vmstat peuvent vous donner des informations plus significatives sur la façon dont vous êtes "sauvegardé" en termes de processus dans la file d'attente d'exécution. La dernière colonne ("wa") de la sortie vmstat peut vous indiquer si, et pendant combien de temps, vous attendez la fin des E / S. La taille de la file d'attente d'exécution et le temps d'attente des E / S sont souvent corrélés. Consultez également sar (du package sysstat): cela vous donne une vue détaillée de ce qui se passe sur une période de temps; les mesures qu'il enregistre sont très approfondies.