Charger la bizarrerie moyenne sur Linux Ubuntu

Au cours des derniers jours, j'ai essayé de comprendre l'étrangeté qui se passe dans notre infrastructure, mais je n'ai pas pu le comprendre, alors je me tourne vers vous pour me donner quelques indices.

J'ai remarqué dans Graphite, des pointes dans load_avg qui se produisent avec une régularité mortelle environ toutes les 2 heures - ce n'est pas exactement 2 heures mais c'est très régulier. Je joins une capture d'écran de ce que j'ai prise de Graphite

Je suis resté coincé à enquêter sur cela - la régularité de cela m'a amené à penser que c'est une sorte de travail cron ou quelque chose comme ça, mais qu'il n'y a AUCUN cronjobs en cours d'exécution sur ces serveurs - en fait, ce sont des machines virtuelles exécutées dans le cloud Rackspace. Ce que je recherche, c'est une sorte d'indication qui pourrait être à l'origine de ces problèmes et comment enquêter plus avant.

Les serveurs sont assez inactifs - il s'agit d'un environnement de transfert, donc il n'y a presque pas de trafic entrant / il ne devrait y avoir aucune charge sur eux. Ce sont tous les 4 VM de cœurs virtuels. Ce que je sais avec certitude, c'est que nous prenons un tas d'échantillons de graphite toutes les 10 secondes environ, mais si c'est la cause de la charge, je m'attends à ce qu'elle soit constamment élevée plutôt que de se produire toutes les 2 heures par vagues sur différents serveurs.

Toute aide sur la façon d'enquêter serait grandement appréciée!

Voici quelques données de sar pour app01 - qui est le premier pic bleu sur l'image ci-dessus - je n'ai pu tirer AUCUNE conclusion à partir des données. Ce n'est pas non plus que le pic d'écriture des octets que vous voyez se produire toutes les demi-heures (PAS TOUS LES 2 HEURES) soit dû au chef-client qui s'exécute toutes les 30 minutes. J'essaierai de rassembler plus de données même si je l'ai déjà fait, mais je ne peux pas vraiment en tirer de conclusions non plus.

CHARGE

09:55:01 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
10:05:01 PM         0       125      1.28      1.26      0.86         0
10:15:01 PM         0       125      0.71      1.08      0.98         0
10:25:01 PM         0       125      4.10      3.59      2.23         0
10:35:01 PM         0       125      0.43      0.94      1.46         3
10:45:01 PM         0       125      0.25      0.45      0.96         0
10:55:01 PM         0       125      0.15      0.27      0.63         0
11:05:01 PM         0       125      0.48      0.33      0.47         0
11:15:01 PM         0       125      0.07      0.28      0.40         0
11:25:01 PM         0       125      0.46      0.32      0.34         0
11:35:01 PM         2       130      0.38      0.47      0.42         0
11:45:01 PM         2       131      0.29      0.40      0.38         0
11:55:01 PM         2       131      0.47      0.53      0.46         0
11:59:01 PM         2       131      0.66      0.70      0.55         0
12:00:01 AM         2       131      0.81      0.74      0.57         0

CPU

09:55:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:05:01 PM     all      5.68      0.00      3.07      0.04      0.11     91.10
10:15:01 PM     all      5.01      0.00      1.70      0.01      0.07     93.21
10:25:01 PM     all      5.06      0.00      1.74      0.02      0.08     93.11
10:35:01 PM     all      5.74      0.00      2.95      0.06      0.13     91.12
10:45:01 PM     all      5.05      0.00      1.76      0.02      0.06     93.10
10:55:01 PM     all      5.02      0.00      1.73      0.02      0.09     93.13
11:05:01 PM     all      5.52      0.00      2.74      0.05      0.08     91.61
11:15:01 PM     all      4.98      0.00      1.76      0.01      0.08     93.17
11:25:01 PM     all      4.99      0.00      1.75      0.01      0.06     93.19
11:35:01 PM     all      5.45      0.00      2.70      0.04      0.05     91.76
11:45:01 PM     all      5.00      0.00      1.71      0.01      0.05     93.23
11:55:01 PM     all      5.02      0.00      1.72      0.01      0.06     93.19
11:59:01 PM     all      5.03      0.00      1.74      0.01      0.06     93.16
12:00:01 AM     all      4.91      0.00      1.68      0.01      0.08     93.33

09:55:01 PM       tps      rtps      wtps   bread/s   bwrtn/s
10:05:01 PM      8.88      0.15      8.72      1.21    422.38
10:15:01 PM      1.49      0.00      1.49      0.00     28.48
10:25:01 PM      1.54      0.00      1.54      0.03     29.61
10:35:01 PM      8.35      0.04      8.31      0.32    411.71
10:45:01 PM      1.58      0.00      1.58      0.00     30.04
10:55:01 PM      1.52      0.00      1.52      0.00     28.36
11:05:01 PM      8.32      0.01      8.31      0.08    410.30
11:15:01 PM      1.54      0.01      1.52      0.43     29.07
11:25:01 PM      1.47      0.00      1.47      0.00     28.39
11:35:01 PM      8.28      0.00      8.28      0.00    410.97
11:45:01 PM      1.49      0.00      1.49      0.00     28.35
11:55:01 PM      1.46      0.00      1.46      0.00     27.93
11:59:01 PM      1.35      0.00      1.35      0.00     26.83
12:00:01 AM      1.60      0.00      1.60      0.00     29.87

RÉSEAU:

10:25:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
10:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:35:01 PM      eth1      7.07      4.77      5.24      2.42      0.00      0.00      0.00
10:35:01 PM      eth0      2.30      1.99      0.24      0.51      0.00      0.00      0.00
10:45:01 PM        lo      8.35      8.35      2.18      2.18      0.00      0.00      0.00
10:45:01 PM      eth1      3.69      3.45      0.65      2.22      0.00      0.00      0.00
10:45:01 PM      eth0      1.50      1.33      0.15      0.36      0.00      0.00      0.00
10:55:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:55:01 PM      eth1      3.66      3.40      0.64      2.19      0.00      0.00      0.00
10:55:01 PM      eth0      0.79      0.87      0.08      0.29      0.00      0.00      0.00
11:05:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:05:01 PM      eth1      7.29      4.73      5.25      2.41      0.00      0.00      0.00
11:05:01 PM      eth0      0.82      0.89      0.09      0.29      0.00      0.00      0.00
11:15:01 PM        lo      8.34      8.34      2.18      2.18      0.00      0.00      0.00
11:15:01 PM      eth1      3.67      3.30      0.64      2.19      0.00      0.00      0.00
11:15:01 PM      eth0      1.27      1.21      0.11      0.34      0.00      0.00      0.00
11:25:01 PM        lo      8.32      8.32      2.18      2.18      0.00      0.00      0.00
11:25:01 PM      eth1      3.43      3.35      0.63      2.20      0.00      0.00      0.00
11:25:01 PM      eth0      1.13      1.09      0.10      0.32      0.00      0.00      0.00
11:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:35:01 PM      eth1      7.16      4.68      5.25      2.40      0.00      0.00      0.00
11:35:01 PM      eth0      1.15      1.12      0.11      0.32      0.00      0.00      0.00
11:45:01 PM        lo      8.37      8.37      2.18      2.18      0.00      0.00      0.00
11:45:01 PM      eth1      3.71      3.51      0.65      2.20      0.00      0.00      0.00
11:45:01 PM      eth0      0.75      0.86      0.08      0.29      0.00      0.00      0.00
11:55:01 PM        lo      8.30      8.30      2.18      2.18      0.00      0.00      0.00
11:55:01 PM      eth1      3.65      3.37      0.64      2.20      0.00      0.00      0.00
11:55:01 PM      eth0      0.74      0.84      0.08      0.28      0.00      0.00      0.00

Pour les curieux de cronjobs. Voici le résumé de tous les cronjobs configurés sur le serveur (j'ai choisi app01 mais cela se produit également sur quelques autres serveurs avec les mêmes cronjobs configurés)

$ ls -ltr /etc/cron*
-rw-r--r-- 1 root root  722 Apr  2  2012 /etc/crontab

/etc/cron.monthly:
total 0

/etc/cron.hourly:
total 0

/etc/cron.weekly:
total 8
-rwxr-xr-x 1 root root 730 Dec 31  2011 apt-xapian-index
-rwxr-xr-x 1 root root 907 Mar 31  2012 man-db

/etc/cron.daily:
total 68
-rwxr-xr-x 1 root root  2417 Jul  1  2011 popularity-contest
-rwxr-xr-x 1 root root   606 Aug 17  2011 mlocate
-rwxr-xr-x 1 root root   372 Oct  4  2011 logrotate
-rwxr-xr-x 1 root root   469 Dec 16  2011 sysstat
-rwxr-xr-x 1 root root   314 Mar 30  2012 aptitude
-rwxr-xr-x 1 root root   502 Mar 31  2012 bsdmainutils
-rwxr-xr-x 1 root root  1365 Mar 31  2012 man-db
-rwxr-xr-x 1 root root  2947 Apr  2  2012 standard
-rwxr-xr-x 1 root root   249 Apr  9  2012 passwd
-rwxr-xr-x 1 root root   219 Apr 10  2012 apport
-rwxr-xr-x 1 root root   256 Apr 12  2012 dpkg
-rwxr-xr-x 1 root root   214 Apr 20  2012 update-notifier-common
-rwxr-xr-x 1 root root 15399 Apr 20  2012 apt
-rwxr-xr-x 1 root root  1154 Jun  5  2012 ntp

/etc/cron.d:
total 4
-rw-r--r-- 1 root root 395 Jan  6 18:27 sysstat
$ sudo ls -ltr /var/spool/cron/crontabs 
total 0
$

Comme vous pouvez le voir, il n'y a pas de cronjobs HORAIRES. Uniquement par jour / semaine, etc.

J'ai rassemblé un tas de statistiques (vmstat, mpstat, iostat) - même si j'essaye, je ne vois tout simplement pas de pistes qui suggéreraient un mauvais comportement d'un composant VM ... Je commence à me pencher vers des problèmes potentiels à l'hyperviseur. N'hésitez pas à consulter les statistiques L'essentiel commence par la sortie de sar -q autour du moment "offensant" et ensuite vous pouvez voir vm, mp et iostats ....

En gros, c'est toujours un mystère total pour moi ...

— milosgajdos
source

Avez-vous des données interactives que vous pouvez partager pour approfondir votre recherche (c.-à-d. Qu'est-ce que les affichages «top», «htop» et «iotop» pendant les pics de charge récurrents)? De plus, avez-vous vérifié vos journaux d'application pendant les périodes en question pour voir s'ils présentent un comportement étrange? De plus, avez-vous des hôtes avec des configurations similaires non hébergés sur une infrastructure de cloud public, et si oui, présentent-ils un comportement similaire?

— esquireofoz

En termes de journaux d'application - il ne se passe rien. Les seules entrées de journal qu'il contient sont des contrôles de surveillance qui se produisent chaque minute - fondamentalement, le système de surveillance frappe le site principal et signale le code de résultat - à part que les journaux sont complètement vides. De plus, comme vous pouvez le voir, il existe une variété d'hôtes ci-dessus - cela se produit sur chacun d'eux (redis, serveur d'applications, serveur de chef, etc.)

— milosgajdos

Avez-vous essayé d'utiliser psacct pour le réduire?

— HTTP500

vous assumez la régularité, mais les données que vous montrez ne montrent aucun pic régulier. Veuillez être plus précis quant à la période exacte à laquelle il montre la régularité (sur plusieurs jours peut-être? sur la photo, il n'y a pas de régularité.) vous pourriez exécutez un "top -n 1" tous les 1 mn environ et conservez-les dans un fichier, ce qui pourrait aider à voir quels autres processus sont en concurrence pour le processeur en même temps qu'un pic se produit. Si App1 est une application accessible sur Internet, c'est peut-être simplement quelqu'un qui y accède et qui force ce comportement? ajouter une journalisation régulière "netstat -an" aussi (toutes les minutes?)

— Olivier Dulac

Avez-vous vu la capture d'écran ci-jointe? Si cela ne montre pas la régularité, je ne sais pas ce que cela signifie. J'ai maintenant augmenté la période d'échantillonnage pour sar donc j'échantillonne toutes les 5 minutes. La régularité sur la photo est plus qu'évidente - elle se produit toutes les deux heures. Il s'agit d'un environnement intermédiaire sans trafic du tout - comme vous pouvez certainement le voir sur les sorties sar ci-dessus pour les statistiques du réseau.

— milosgajdos

Intéressant.

Tout d'abord, pouvez-vous augmenter la fréquence de journalisation de sar. Au lieu de 10 minutes, essayez de vous connecter toutes les minutes. Le cronjob sysstat est configurable.

Ensuite, essayez de créer un script pour les commandes suivantes.

ps auxf > /tmp/ps.out
vmstat 1 50 > /tmp/vm.out
mpstat -P ALL 1 50 > /tmp/mp.out
iostat -xdk 1 50 > /tmp/io.out
cat /proc/meminfo > /tmp/meminfo.out

Rassemblez cet ensemble de données à chaque itération lorsque la moyenne de charge augmente manuellement ou via cron. Il serait bon d'avoir des données d'au moins une journée de travail complète.

Maintenant, je comprends que les serveurs sont inactifs mais certaines applications doivent toujours être en cours d'exécution. Que sont-ils?

Est-il possible que vous puissiez exécuter un outil de profilage, comme perf ou oprofile.

Un composant matériel du serveur a-t-il été modifié? Même quelque chose d'aussi inoffensif qu'une mise à niveau du micrologiciel ou une mise à niveau logicielle.

Hé, une question. Quel est le planificateur que vous exécutez. Je crois que c'est cfq, toute chance que vous puissiez le changer en noop. Mettez elevator=noople paramètre de ligne de commande du noyau et redémarrez le système et voyez s'il l'améliore.

— Soham Chakraborty
source

J'ai ajouté une petite modification sur le planificateur. veuillez voir le résultat.

— Soham Chakraborty

Journaliser les principaux processus

Étant donné que l'occurrence est très régulière, configurez un travail cron pour surveiller les principaux processus pendant cette période

#app01
20-59 0/2 * * * root /usr/bin/top -b -n 1 | /usr/bin/head -n 15 >> /var/log/top.log

Changez 20-59pour *enregistrer toute l'heure pour chaque nombre pair d'heures. La tâche Cron s'exécutera une fois par minute dans les deux cas.

Vous souhaiterez peut-être ajouter le fichier top.log pour enregistrer la rotation afin qu'il n'occupe pas tout l'espace au cas où vous oublieriez de le désactiver.

Vérifier le fichier journal

Rechercher des entrées de fichier journal à une période de charge élevée

Prenez l'exemple de chargement suivant comme exemple

10:25:01 PM         0       125      4.10      3.59      2.23         0

Faire

grep ' 22:2' /var/log/*
grep ' 22:2' /var/log/apache2/*

Cela affichera toutes les entrées de journal pour 22:2x:xx. Peut devoir inclure d'autres répertoires de journaux.

Dim 6 janv 21:00:07 2013: xvda w_await spike

Graphique xvda - Le pic w_await est au dim 6 janvier 21:00:07 2013 entrez la description de l'image ici

— John Siu
source

Une chose que je vérifierais certainement:

Graphiques vSphere pour le même modèle, peut-être qu'une autre machine virtuelle sur le même hôte mange les processeurs (ainsi la charge sur votre machine virtuelle augmente car il faut plus de temps pour traiter la même quantité de données avec un flux constant en raison de moins de temps processeur disponible pour votre VM).

Edit: Je ne l'ai pas obtenu la première fois :) Vous exécutez sur Rackspace, donc aucun contrôle sur l'hyperviseur, mais il vaut peut-être la peine de demander à rackspace s'ils peuvent vérifier si ce modèle est commun sur d'autres VM sur le même hôte .

— Martino Dino
source

Je me méfie également de cela - ce ne serait pas la première fois que le cloud Rackspace provoquerait une sorte de folie. Je doute qu'ils surveillent l'un de leurs serveurs hyperviseurs - je veux dire en termes de mauvais comportement des machines virtuelles, mais j'aimerais exclure toute possibilité "interne" avant de passer au dernier recours - le support Rackspace.

— milosgajdos

Les performances de l'hyperviseur affectent-elles la charge moyenne apparente d'une machine virtuelle? Cela m'amène à réfléchir à la façon dont la moyenne de charge est calculée. Cela pourrait-il être un effet de la fonction d'économie d'énergie / verte qui déplace périodiquement le travail vers moins de cœurs à l'insu du système d'exploitation? Ou que diriez-vous de changer dynamiquement la fréquence d'horloge en fonction, par exemple, des entrées environnementales?

— trp

La moyenne de charge est calculée par l'algorithme de planification, en termes simples, si vous avez 100 tâches dans votre file d'attente de traitement et l'hyperviseur est 100% efficace pour exécuter 10 tâches par 1 seconde, alors vous avez besoin de 10 secondes pour exécuter 100 tâches, si votre hyperviseur n'est efficace qu'à 50% (peut-être un surapprovisionnement du processeur), il faudra 20 secondes pour exécuter la même quantité de tâches, ce qui entraînera une augmentation de la charge. Explication complète: blog.scoutapp.com/articles/2009/07/31/…

— Martino Dino