Red Hat Summit2.3. Diskdevstat et netdevstat
Diskdevstat et netdevstat sont des outils SystemTap qui collectent des informations détaillées sur les activités disque et réseau de toutes les applications exécutées sur un système. Ces outils ont été inspirés par PowerTOP, qui montre le nombre de réveils CPU par seconde de chaque application (reportez-vous à Section 2.2, « PowerTOP »). Les statistiques collectées par ces outils vous permettent d'identifier les applications qui utilisent de l'énergie inutilement avec beaucoup de petites opérations d'E/S, au lieur de peu d'opérations de grande taille. Les autres outils de surveillance ne mesurant que la vitesse de transfert n'aident pas à identifier ce type d'utilisation.
Installez ces outils avec SystemTap à l'aide de la commande :
yum install systemtap tuned-utils kernel-debuginfo
yum install systemtap tuned-utils kernel-debuginfo
Exécutez ces outils avec la commande :
diskdevstat
diskdevstat
ou avec la commande :
netdevstat
netdevstat
Ces deux commandes peuvent inclure jusqu'à trois paramètres, comme suit :
diskdevstat update_interval total_duration display_histogram
netdevstat update_interval total_duration display_histogram
- update_interval
- Le temps en secondes entre les mises à jour de l'affichage. Par défaut :
5 - total_duration
- Le temps en secondes pour la totalité de l'exécution. Par défaut :
86400(1 jour) - display_histogram
- Indiquez s'il faut inclure toutes les données collectées dans l'histogramme à la fin de l'exécution.
La sortie ressemble à celle de PowerTOP. Ci-dessous figure un exemple de sortie d'une plus longue exécution de diskdevstat sur un système Fedora 10 exécutant KDE 4.2 :
Les colonnes sont :
- PID
- l'ID du processus de l'application
- UID
- l'ID utilisateur sous lequel l'application est exécutée
- DEV
- le périphérique sur lequel les E/S ont eu lieu
- WRITE_CNT
- le nombre total des opérations d'écriture
- WRITE_MIN
- le temps le moins long pris pour deux écritures consécutives (en secondes)
- WRITE_MAX
- le temps le plus long pris pour deux écritures consécutives (en secondes)
- WRITE_AVG
- le temps moyen pris pour deux écritures consécutives (en secondes)
- READ_CNT
- le nombre total des opérations de lecture
- READ_MIN
- le temps le moins long pris pour deux lectures consécutives (en secondes)
- READ_MAX
- le temps le plus long pris pour deux lectures consécutives (en secondes)
- READ_AVG
- le temps moyen pris pour deux lectures consécutives (en secondes)
- COMMAND
- le nom du processus
Dans cet exemple, trois applications se démarquent de manière évidente :
PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd
PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND
2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma
2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd
2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd
Ces trois applications ont un
WRITE_CNT plus important que 0, ce qui veut dire qu'elles ont effectuées quelque sorte d'écriture pendant la mesure. De celles-ci, plasma fut la pire et de loin : cette application a effectuée la plupart des opérations d'écriture, et bien sûr le temps moyen entre les écritures était le plus bas. Plasma serait donc l'application idéale à étudier si vous vous sentiez concerné par les applications inefficaces au niveau de la consommation d'énergie.
Utilisez les commandes strace et ltrace pour examiner les applications de plus près en retraçant tous les appels système de l'ID du processus. Dans l'exemple présent, vous pourriez exécuter :
strace -p 2789
strace -p 2789
Dans cet exemple, la sortie de
strace contient un schéma se répétant toutes les 45 secondes qui ouvre le fichier cache de l'icône KDE de l'utilisateur pour une écriture, suivi par la fermeture immédiate du fichier. Ceci a nécessairement conduit à une écriture physique sur le disque dur puisque les métadonnées du fichier (plus spécifiquement l'heure de la modification) avaient changées. Le correctif final servait à prévenir ces appels inutiles lorsqu'il n'y avait pas eu de mises à jour des icônes.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}