wa (En attente d'E / S) de la commande supérieure est grand

J'ai un forum avec beaucoup de visiteurs, certains jours l'augmentation de la charge pour atteindre 40 sans augmentation du nombre de visiteurs. Comme vous pouvez le voir sur la sortie ci-dessous, le temps d'attente est élevé (57%). comment puis-je trouver la raison de cela?
Le logiciel serveur est Apache, MySQL et PHP.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

Voici quelques outils pour trouver l'activité du disque:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

En ps auxfvous verrez également quels sont les processus sont dans le sommeil de disque ininterprétable ( D) parce qu'ils attendent d' E / S.

Certains jours, la charge augmente pour atteindre 40 sans augmentation du nombre de visiteurs.

Vous pouvez également vouloir créer une sauvegarde et voir si le disque dur échoue lentement. Un disque dur commence généralement à ralentir avant de s'éteindre. Cela pourrait également expliquer la charge élevée.

La sortie par le haut suggère que le SGBD connaît la plupart des attentes d'E / S, donc les problèmes de réglage de la base de données sont un candidat évident à étudier.

Les E / S en attente sur un serveur de base de données - en particulier sur les pics de charge - sont un indice que votre SGBD peut être lié au disque (c'est-à-dire que vous avez besoin d'un sous-système de disque plus rapide) ou qu'il peut avoir un problème de réglage. Vous devriez probablement également étudier le profilage de votre serveur de base de données - c'est-à-dire obtenir une trace de ce qu'il fait et des requêtes qui prennent du temps.

Quelques points de départ pour diagnostiquer les problèmes de réglage de la base de données: -

• Recherchez les requêtes qui prennent le plus de temps et examinez les plans de requête. Voyez si certains ont des plans de requête étranges comme une analyse de table où ils ne devraient pas être. Peut-être que la base de données a besoin d'un index ajouté.

• Les longs temps d'attente pour les ressources peuvent signifier que certains pools de ressources clés doivent être étendus.

• De longs temps d'attente d'E / S peuvent signifier que vous avez besoin d'un sous-système de disque plus rapide.

• Vos volumes de journaux et de données sont-ils sur des disques séparés? Les journaux de base de données ont beaucoup de petites écritures séquentielles (essentiellement, ils se comportent comme un tampon en anneau). Si vous avez une charge de travail à accès aléatoire occupée partageant les mêmes disques que vos journaux, cela affectera de manière disproportionnée le débit de la journalisation. Pour qu'une transaction de base de données soit validée, les entrées de journal doivent être écrites sur le disque, ce qui créera un goulot d'étranglement sur l'ensemble du système.
  
  Notez que certains moteurs de stockage MySQL n'utilisent pas de journaux, donc cela peut ne pas être un problème dans votre cas.

Footnote: Systèmes de file d'attente

Les systèmes de file d'attente (un modèle statistique pour le débit) deviennent hyperboliquement plus lents lorsque le système approche de la saturation. Pour une approximation de haut niveau, un système saturé à 50% a une longueur de file d'attente moyenne de 2. Un système saturé à 90% a une longueur de file d'attente de 10, un système saturé à 99% a une longueur de file d'attente de 100.

Ainsi, sur un système proche de la saturation, de petits changements de charge peuvent entraîner des modifications importantes des temps d'attente, se manifestant dans ce cas par le temps passé à attendre les E / S. Si la capacité d'E / S de votre sous-système de disque est presque saturée, de petits changements de charge peuvent entraîner des changements importants dans les temps de réponse.

Exécutez iotopou atop -dDpour voir ce que font les processus io. À utiliser stracesi vous avez besoin de regarder de plus près.

Dans les deux écrans, il semble que "mysqld" soit responsable.

Vous devez voir ce que fait ce démon ... quelles requêtes sont en cours d'exécution.

Certains jours, la charge augmente pour atteindre 40 sans augmentation du nombre de visiteurs.

Ce que font les utilisateurs pourrait être aussi important que le nombre qui s'y trouve réellement. Des opérations telles que la recherche sur le forum seront plus exigeantes que le simple chargement et la visualisation de threads individuels ou de listes de threads.

Aussi: exécutez-vous sur un serveur dédié ou un VPS? Si votre service n'est pas sur un serveur dédié, les actions des applications s'exécutant sur le même hôte auront un effet, car les machines virtuelles avec lesquelles votre machine virtuelle partage un hôte seront en concurrence pour une part de la ressource d'E / S.

Comme d'autres l'ont souligné, des outils comme iotopvous aideront à approfondir les tâches à accomplir en attendant les réponses d'E / S et les fichiers auxquels ils accèdent à ce moment-là.

Comme le dit Flip, il semble que le problème concerne ce que fait mysql.

Environ la moitié de votre mémoire physique est actuellement utilisée pour la mise en cache des E / S - le logiciel de forum génère généralement de nombreuses requêtes rapides renvoyant un petit nombre de lignes, avec des zones de disque très asymétriques - il se passe donc quelque chose de compliqué si le système dépense autant de temps en attente.

Je ne vois que l'utilisation du processeur / disque comme ça lors de l'exécution de requêtes qui mettent à jour des millions de lignes.

La moyenne de charge élevée est la conséquence directe des E / S.

Augmentez votre journalisation mysql pour voir s'il y a du mauvais code là-dedans / changer les index serait utile. L'analyse de vos tableaux peut aider (mais probablement pas beaucoup).

C.