Utilisation des ressources
Utilisez ce script perl (appelé « top_guide.pl ») pour évaluer l’utilisation à long terme des ressources clés sur votre serveur. Ce script est compatible avec Mac OS X Server 10.4 et version ultérieure.
Par le biais de la commande top -d, le script analyse et résume l’utilisation sur le long terme qui a été faite des ressources clés. Si aucun argument n’est ajouté, le résultat obtenu à l’aide du script top_guide.pl est similaire à l’exemple suivant :
-------- ----------- ------------ ------------- ------------- ------------- ------------- ------ CPU usage: 300-s Reads/sec: Writes/sec: Net in/sec: Net out/sec: kernel Time: user sys Idle avg. number MB number MB pkts Mb pkts Mb CPU% -------- ----- ----- ----- ----- ------ ------ ------ ------ ------ ------ ------ ------ ------ 08:44:36 0.1 0.1 99.8 99.8 0 0.0 0 0.0 11 0.0 0 0.0 0.4 08:44:46 0.1 0.3 99.6 99.8 0 0.0 0 0.1 12 0.0 0 0.0 0.4 08:44:56 0.0 0.2 99.8 99.8 0 0.0 0 0.0 17 0.0 0 0.0 0.4 08:45:06 0.0 0.2 99.8 99.8 0 0.0 0 0.0 6 0.0 0 0.0 0.4 08:45:16 0.0 0.2 99.8 99.8 0 0.0 0 0.0 9 0.0 0 0.0 0.4 08:45:26 8.7 24.6 66.7 98.6 43 0.8 98 0.6 803 1.0 1399 1.1 5.0 08:45:37 5.7 83.6 10.7 95.7 48 0.4 1085 116.9 95366 1053.1 61830 35.4 72.4 08:45:47 11.5 88.5 0.0 92.4 23 0.2 3228 426.9 337955 3843.6 207872 114.0 284.8 08:45:58 4.6 95.4 0.0 89.0 4 0.0 594 596.7 447499 5215.5 266449 140.9 370.0
Les trois domaines clés identifiés sont le processeur, les E/S de disque et la mise en réseau. Les colonnes rapportent les informations suivantes :
- Heure (Time) : l’heure de fin de la ligne de résumé la plus récente. Par défaut, les échantillons sont séparés par des intervalles de 10 secondes.
- Utilisation du processeur : utilisateur (CPU usage: user) : utilisation du processeur en mode utilisateur. Cette valeur correspond au pourcentage du total des ressources processeur disponibles sur le système. Par exemple, un système à huit processeurs présentant 50 % d’utilisation processeur par l’utilisateur fait usage de quatre processeurs pour l’exécution des applications ouvertes.
- Utilisation du processeur : sys (CPU usage: sys) : utilisation du processeur en mode noyau, représentée par un pourcentage de la capacité processeur disponible.
- Inactif (Idle) : processeur inactif, représenté par un pourcentage des ressources disponibles.
- Moy sur 300 s (300-s avg.) : moyenne arrondie du pourcentage de disponibilité du processeur, calculée sur la base des 300 dernières secondes. Le calcul et le nom de la colonne sont différents si l’option « -r » est utilisée pour ajuster l’intervalle de moyenne.
- Nombre de lectures/s (Reads/sec - number) : le nombre d’opérations de lecture unique du disque exécutées dans l’intervalle d’échantillonnage.
- Mo lus/s (Reads/sec - MB) : volume total (en Mo) de données lues sur les disques dans l’intervalle d’échantillonnage.
- Nombre d’écritures/s (Writes/sec - number) : le nombre d’opérations d’écriture unique sur disque, exécutées dans l’intervalle d’échantillonnage.
- Mo écrits/s (Writes/sec - MB) : volume total (en Mo) de données écrites sur disque dans l’intervalle d’échantillonnage.
- Paquets d’entrées réseau/s (Net in/sec - pkts) : total des paquets reçus dans l’intervalle d’échantillonnage.
- Volume (en Mo) des entrées réseau/s (Net in/sec - Mb) : volume total des entrées réseau (en Mo) par seconde dans l’intervalle d’échantillonnage.
- Paquets d’entrées réseau/s (Net out/sec - pkts) : total des paquets réseau envoyés dans l’intervalle d’échantillonnage.
- Volume (en Mo) des sorties réseau/s (Net out/sec - Mb) : volume total des sorties réseau (en Mo) par seconde dans l’intervalle d’échantillonnage.
Les autres options prises en charge par le script sont les suivantes :
-h: affichage des informations relatives à l’usage.-o nom_du_fichier: création d’une copie des résultats dans un fichier dont les valeurs sont séparées par des tabulations. Ce format de présentation des résultats permet l’importation dans un tableur ou tout autre script d’analyse des données. La première ligne inclut les en-têtes de colonne afin que les résultats soient facilement compréhensibles.-d: affichage de l’horodatage. Cette option s’avère particulièrement utile pour les utilisateurs se connectant pendant de longues périodes à un serveur sur lequel l’administrateur conserve un historique.-S nomDesProcessus: contrôle des processus à instance unique. Cette option s’avère utile si un service spécifique du serveur (possédant un identifiant de processus unique) vous intéresse tout particulièrement. Prenons pour exemple un serveur AFP. Dans ce cas, vous devez ajouter les arguments-S AppleFileServerpour créer une nouvelle colonne consacrée à l’utilisation du processeur par l’utilisateur, pour le processus AppleFileServer. Vous pouvez indiquer plusieurs noms de processus, séparés par des virgules.-M nomDesProcessus: cette commande est semblable à la commande-S, bien qu’elle soit employée lorsque l’application utilise plusieurs processus. Par exemple, le démonsmbdutilise un processus par connexion. Sur un système principalement utilisé avec Samba, saisissez la commande-M smbdpour faire s’afficher une colonne résumant l’utilisation du processeur par l’utilisateur pour toutes les activités Samba.
Bien qu’une analyse complète des performances du serveur dépasse le cadre de cet article, les résultats proposés par le script top_guide.pl offrent un résumé de l’utilisation des ressources (processeur, stockage sur disque, mise en réseau) du système. Un administrateur souhaitant poursuivre son analyse plus en profondeur peut comparer ces résultats avec le matériel et la charge du système pour choisir par quelle zone commencer. Les outils décrits ci-dessous peuvent être utiles à l’analyse des zones.
Utilisation processeur
Si le processeur est utilisé de façon intensive, l’objectif principal de l’analyse doit être orienté vers l’amélioration des performances de l’application. Ce sujet dépasse le cadre de cet article. Cependant, le processeur n’est parfois pas utilisé. Certains outils peuvent vous aider à analyser les cas dans lesquels une part importante du processeur reste inactive, bien que vous disposiez d’assez de ressources réseau et sur disque pour augmenter la charge.
La sous-utilisation du processeur peut être due à deux phénomènes :
- le verrouillage des fils de l’application ;
- le verrouillage des ressources du noyau.
Apparue sous Mac OS X 10.5 Leopard, la commande plockstat(1) permet d’étudier les conflits de verrouillage pthread pour une application spécifique. Les processus présentant des conflits de verrouillage pthread peuvent être identifiés grâce à l’examen des résultats obtenus à l’aide de la commande top -d pour les processus disposant d’un nombre important de commutations de contextes (colonne CSW). Identifiez les processus pour lesquels une analyse de conflit de verrouillage pthread est nécessaire, puis saisissez la commande suivante : # plockstat -C -e 10 -p <pid>.
Mutex block Count nsec Lock Caller ------------------------------------------------------------------------------- 8540 29622 0x805eb0 a.out`process_request+0x3d1 8361 28284 0x805eb0 a.out`release_block+0xac R/W reader block Count nsec Lock Caller ------------------------------------------------------------------------------- 1 3014987 0xa781e8 a.out`key_find+0x121 5 78831 0xa3d158 a.out`key_find+0x121 2 120532 0xa3d158 a.out`key_delete+0x137 R/W writer block Count nsec Lock Caller ------------------------------------------------------------------------------- 10 5336318 0xa781e8 a.out`key_replace+0x80 13 3827632 0xa75fe8 a.out`key_replace+0x80 3 3644946 0xa5fde8 a.out`key_create+0x37 6 161055 0xa3d158 a.out`key_replace+0x80 1 785267 0xa37758 a.out`key_create+0x37
Vous pouvez examiner ces résultats et consulter le total de nsec bloqués derrière divers verrouillages. Si cette valeur est élevée, le temps d’exécution est ralenti par les conflits de verrouillage. Ces informations peuvent permettre au développeur de l’application d’identifier les problèmes affectant une application et d’améliorer ses performances. Si des symboles sont disponibles, le champ Appelant contient le nom symbolique de la fonction concernée par le blocage. En outre, si le total de blocages est élevé (supérieur à une moyenne de 250 par seconde), la replanification entre fils a un impact négatif sur l’efficacité de l’application. Les taux de blocage élevés ne sont pas toujours des facteurs de ralentissement des performances, mais ils entraînent souvent une perte d’efficacité et doivent donc être examinés.
Les problèmes de conflits de ressources affectent parfois les ressources du noyau. Le noyau de Mac OS X gère la plupart des ressources multifils avec mutex de noyau et blocages lecteur-rédacteur. Les conflits de mutex peuvent être évalués à l’aide de scripts dtrace(1M), comme :
lockstat:::adaptive-block
{
@often[arg0, stack(5)] = count();
}
profile:::tick-5sec
{
normalize(@often, 5);
printa(@often);
}
Une liste hiérarchisée est alors imprimée. Celle-ci présente les chemins et verrouillages les plus courants au bas de chaque blocage de sortie imprimé après cinq secondes d’échantillonnage. Voici un exemple de résultat :
375517140 mach_kernel`lck_mtx_lock_wait_x86+0x1c7 mach_kernel`lck_mtx_lock+0x217 mach_kernel`ip_output_list+0xd34 mach_kernel`tcp_setpersist+0x18b mach_kernel`tcp_output+0x17a0 0 375571960 mach_kernel`lck_mtx_lock_wait_x86+0x1c7 mach_kernel`lck_mtx_lock+0x217 mach_kernel`vnode_ref+0x32 mach_kernel`fcntl_nocancel+0x4b3 mach_kernel`unix_syscall64+0x26d 0
Dans de tels cas, le script indique que le mutex du noyau à l’adresse 375517140 est bloqué par un chemin sur lequel la fonction tcp_output() entraîne la fonction tcp_setpersist(), qui elle-même entraîne la fonction ip_output_list(). Le nombre de blocages par secondes est nul sur chacun des verrouillages, ce qui indique que le conflit de verrouillage ne pose pas de problème. Cette forme de script ne répertorie pas toutes les instances de chaque verrouillage. Si le script utilisé était :
lockstat:::adaptive-block
{
@often[arg0] = count();
}
profile:::tick-5sec
{
normalize(@often, 5);
printa(@often);
}
Le résultat serait probablement :
1301055072 9 1417504384 9 353318336 10 359381776 10 1301055088 11 5387344 165
Ceci indique que le verrouillage situé à l’adresse de noyau 5387344 présente un conflit certes non négligeable, mais pas inquiétant étant donné qu’il ne dépasse pas la limite de 250.
Le script peut également se concentrer sur les verrouillages de lecteur-rédacteur du noyau s’il est modifié de la manière suivante :
lockstat:::rw-block
{
@often[arg0, stack(4)] = count();
}
profile:::tick-5sec
{
normalize(@often, 5);
printa(@often);
clear(@often);
}
Quelques rappels concernant les scripts lockstat dtrace(1M) et la commande plockstat(1) :
- La collecte de statistiques de verrouillage affecte les performances. Les outils en question sont susceptibles de causer un ralentissement du système. Utilisez-les avec précaution et n’oubliez pas que tout impact sur les performances augmentera le taux de conflit par rapport à un fonctionnement normal du système.
- Certaines configurations ne sont pas affectées par le blocage de verrous. Verrouillez une ressource qui subit peu de modifications pour pouvoir la gérer plus facilement. Le verrouillage peut être conservé jusqu’à ce qu’une opération s’exécutant sur une longue période arrive à terme.
Les temps d’attente de ces verrouillages sont susceptibles d’être plus longs, sans toutefois avoir d’impact sur les performances.
Utilisation du disque
iopending(1) fournit des informations sur la longueur des queues E/S sous forme d’histogrammes. Exemple :
2008 May 21 10:35:26, load: 0.99, disk_r: 0 KB, disk_w: 392 KB
value ------------- Distribution ------------- count < 0 | 0 0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 9298 1 | 12 2 | 5 3 | 4 4 | 2 5 | 3 6 | 2 7 | 2 8 | 3 9 | 2 10 | 3 11 | 2 12 | 2 13 | 2 14 | 2 15 | 0
Ceci témoigne d’une certaine activité sur le disque. Cette activité n’est toutefois pas inquiétante car presque toutes les queues E/S présentent une longueur nulle. De plus, l’option iopending peut vous permettre de vous concentrer sur un disque ou volume de fichiers en particulier. Par exemple, pour concentrer vos efforts sur le volume /Volumes/MyRAID, utilisez l’option : iopending -m MonRAID.
Enfin, vous pouvez attribuer une E/S à des processus spécifiques et évaluer la latence à l’aide de la commande fs_usage(1). Vous pouvez obtenir des informations supplémentaires sur l’utilisation de Shark et de l’option fs_usage(1) en consultant le document Developer Connection.
Utilisation réseau
De nombreux serveurs disposent d’interfaces réseau et de client multiples, situés à différentes distances sur le réseau. L’analyse des performances peut donc s’avérer complexe. Cependant, dans le cas de réseaux LAN où les clients sont connectés directement par le biais de vitesses connues, les mesures rapportées par le script top_guide.pl et l’option netstat -i fournissent des informations sur l’utilisation des capacités disponibles. Pour interpréter ces valeurs, prenez en compte les indications suivantes :
Réseaux Gigabit - Full Duplex, MTU 1 500 octets
Taux maximum - petits paquets : 1 488 Kp/s 762 Mbits/s
Taux maximum pour paquets - paquets de 1 500 octets : 81 Kp/s 987 Mbits/s
(Kp/s = milliers de paquets par seconde)
Il peut également être utile de consulter les résultats proposés par l’option netstat -s pour les problèmes de taux de retransmissions de paquets en excédent (problème qui dépasse le cadre de cet article).
Informations supplémentaires
- Pour obtenir des informations supplémentaires sur le contrôle de l’utilisation des systèmes de fichiers, consultez l’article Examen de l’utilisation des systèmes de fichiers.
- Pour obtenir des informations sur l’outil de profilage temporel Shark, consultez le guide de l’utilisateur de Shark.
- Pour obtenir des informations supplémentaires sur l’utilisation de Dtrace, consultez le document Utilisation de Dtrace.