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:
iotopvmstat 1iostat 1lsofstrace -e trace=open <application>strace -e trace=open -p <pid>
Dans ps auxf vous verrez également quels processus sont en veille disque ininterprétable (D) car ils attendent des E/S.
Certains jours, la charge augmente pour atteindre 40 sans augmentation du nombre de visiteurs.
Vous pouvez également 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 - est 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.
Les longs temps d'attente des 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, ce qui peut ne pas être un problème dans votre cas.
note de bas de page: 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 iotop ou atop -dD, pour voir ce que font les processus io. Utilisez strace si 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 VM partage un hôte seront en concurrence pour une part du I/O ressource.
Comme d'autres l'ont souligné, des outils comme iotop vous aideront à approfondir les tâches qui attendent 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/changer d'index serait utile. L'analyse de vos tableaux peut aider (mais probablement pas beaucoup).
C.
J'ai obtenu cette très forte utilisation du processeur wa sur un serveur. Il s'est avéré qu'il n'avait pas assez de mémoire disponible et le kswapd0 le processus était à l'origine de cette utilisation élevée du processeur wa.
Le serveur n'avait pas de mémoire Swap, j'ai donc créé un (1 Go) en exécutant ces commandes (serveur Ubuntu):
Sudo fallocate -l 1G /swapfile
Sudo chmod 600 /swapfile
Sudo mkswap /swapfile
Sudo swapon /swapfile
L'utilisation du processeur wa est désormais très faible, ou à 0% la plupart du temps.
Après avoir vérifié tous les outils iotop et autres, vérifiez également la file d'attente "dmesg", vous pourriez voir le problème racine pour ce problème. Dans mon cas, c'était "CIFS VFS: le serveur file.core.windows.net n'a pas répondu en 120 secondes. Reconnexion ..."