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
Réponses:
Voici quelques outils pour trouver l'activité du disque:
iotopvmstat 1iostat 1lsofstrace -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.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 source
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.
la source
Exécutez
iotopouatop -dDpour voir ce que font les processus io. À utiliserstracesi vous avez besoin de regarder de plus près.la source
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.
la source
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à.la source
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.
la source