AIX 4.3 Guide D'optimisation 86F272AP04

Bull
AIX 4.3 Guide doptimisation
AIX
REFERENCE
86 F2 72AP 04
Bull
AIX
Logiciel
Octobre 1999
BULL ELECTRONICS ANGERS

CEDOC
34 Rue du Nid de Pie BP 428
49004 ANGERS CEDEX 01
FRANCE
REFERENCE
86 F2 72AP 04
The following copyright notice protects this book under the Copyright laws of the United States of America
and other countries which prohibit such actions as, but not limited to, copying, distributing, modifying, and
making derivative works.
Copyright
Bull S.A. 1992, 1999
Imprim en France
Vos suggestions sur la forme et le fond de ce manuel seront les bienvenues. Une feuille
destine recevoir vos remarques se trouve la fin de ce document.
Pour commander dautres exemplaires de ce manuel ou dautres publications techniques
Bull, veuillez utiliser le bon de commande galement fourni en fin de manuel.
Marques dposes
Toutes les marques dposes sont la proprit de leurs titulaires respectifs.
AIXR est une marque dpose dIBM Corp. et est utilise sous licence.
UNIX est une marque dpose licencie exclusivement par X/Open Company Ltd
An 2000
Le produit document dans ce manuel est prt pour lAn 2000.
La loi du 11 mars 1957, complte par la loi du 3 juillet 1985, interdit les copies ou reproductions destines
une utilisation collective. Toute reprsentation ou reproduction intgrale ou partielle faite par quelque
procd que ce soit, sans consentement de lauteur ou de ses ayants cause, est illicite et constitue une contrefaon sanctionne par les articles 425 et suivants du code pnal.
Ce document est fourni titre dinformation seulement. Il nengage pas la responsabilit de Bull S.A. en cas
de dommage rsultant de son application. Des corrections ou modifications du contenu de ce document
peuvent intervenir sans pravis ; des mises jour ultrieures les signaleront ventuellement aux destinataires.
Table des matires

A propos de ce manuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xi
Chapitre 1. Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vitesse dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Estimation de la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamique dexcution des programmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamique systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procdure doptimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des charges de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dfinition des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des ressources critiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rduction des contraintes de ressources critiques . . . . . . . . . . . . . . . . . . . . . . . . .
Modification de laffectation des ressources en fonction des priorits . . . . . . . . .
Rptition des tapes doptimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mise en uvre de ressources supplmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . .
Essais comparatifs les donnes de performance sont invitablement modifies
1-1
1-1
1-2
1-2
1-6
1-8
1-8
1-8
1-9
1-10
1-10
1-10
1-11
1-12
Chapitre 2. Gestion des ressources AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Performances du programmateur CPU sous AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prise en charge des routines sous AIX version 4.1 . . . . . . . . . . . . . . . . . . . . . . . . .
Planification des routines de porte concurrentielle globale ou locale . . . . . . . . .
Priorit des processus et des routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File dattente dexcution du programmateur dAIX . . . . . . . . . . . . . . . . . . . . . . . . .
Tranche horaire CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voir aussi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances du gestionnaire de mmoire virtuelle (VMM) . . . . . . . . . . . . . . . . . . . .
Gestion de la mmoire relle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilitaire de contrle de loccupation mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation et rclamation demplacements dans lespace de pagination . . . . . .
Gestion AIX du stockage sur disque fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lecture squentielle anticipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ecriture diffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers mapps et criture diffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rgulation des E/S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pile de disques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-1
2-2
2-2
2-2
2-3
2-4
2-4
2-4
2-5
2-5
2-8
2-11
2-13
2-14
2-15
2-15
2-16
2-16
Chapitre 3. Introduction au multitraitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multitraitement symtrique (SMP) concepts et architecture . . . . . . . . . . . . . . . . . .
Multiprocesseurs symtriques et asymtriques . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Srialisation des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Granularit du verrouillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Charge lie au verrouillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cohrence des mmoires cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affinit avec un processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conflits dutilisation de mmoire et de bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances des systmes SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rpartition de la charge de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dbit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Temps de rponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adaptation des programmes un environnement SMS . . . . . . . . . . . . . . . . . . . . . . .
3-1
3-2
3-2
3-3
3-4
3-4
3-5
3-5
3-5
3-6
3-6
3-6
3-6
3-7
Prface
iii
iv
Charge de travail dun SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multitraitement de la charge de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
chelle de dbit dans un systme multiprocesseur . . . . . . . . . . . . . . . . . . . . . . . . .
Temps de rponse dun systme multiprocesseur . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmation dans un systme SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traitement programm de charges de travail migres . . . . . . . . . . . . . . . . . . . . . .
Variables de lalgorithme de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planification des variables denvironnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affinit avec un processeur et liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-8
3-8
3-8
3-10
3-11
3-11
3-11
3-12
3-14
Chapitre 4. Planification, conception et implantation . . . . . . . . . . . . . . . . . . . . . .

Identification des composants de la charge de travail . . . . . . . . . . . . . . . . . . . . . . .
Dfinition des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
valuation des ressources requises par la charge de travail . . . . . . . . . . . . . . . . .
Conception et implantation de programmes performants . . . . . . . . . . . . . . . . . . . . . .
Programmes CPU limite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conception et codage pour lexploitation optimale des mmoires cache . . . . . .
Registres et pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cache et tampon TLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prprocesseurs et compilateurs XL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Niveaux doptimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Options XL C pour loptimisation de la sous-routine string.h . . . . . . . . . . . . . . . . .
Style de codage optimis C et C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Temps dexcution des compilateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmes CPU limite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conseils pour une installation performante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prinstallation dAIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prinstallation de la CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prinstallation de la mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prinstallation du disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prinstallation des cartes de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-1
4-2
4-2
4-3
4-11
4-11
4-11
4-13
4-13
4-14
4-18
4-18
4-19
4-20
4-20
4-23
4-23
4-23
4-23
4-24
4-27
Chapitre 5. Contrle systme et diagnostics des performances . . . . . . . . . . . .

Contrle continu des performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes de contrle iostat, netstat et vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-1
5-2
5-3
Chapitre 6. Contrle et optimisation de la CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Contrle de la CPU via vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mesure de la CPU via time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conseils relatifs time et timex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrle de la CPU via xmperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des gros consommateurs de CPU via ps . . . . . . . . . . . . . . . . . . . . . . . .
Analyse des programmes via tprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple thorique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyse du flux de commande via stem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyse de stem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restructuration des excutables via fdpr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrle des conflits pour la CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Priorit des processus utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Excution dune commande priorit non standard via nice . . . . . . . . . . . . . . . . .
Dfinition dune priorit fixe via setpri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affichage de la priorit des processus via ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modification de la priorit dun processus en cours via renice . . . . . . . . . . . . . . . .
Clarification de la syntaxe nice/renice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation du calcul de la priorit dun processus via schedtune . . . . . . . . . . .
6-1
6-2
6-3
6-4
6-5
6-6
6-10
6-10
6-17
6-17
6-19
6-20
6-20
6-20
6-20
6-21
6-21
6-22
6-23
Modification de la tranche horaire du programmateur . . . . . . . . . . . . . . . . . . . . . . . . .

Administration des ID utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-25
6-26
Chapitre 7. Contrle et optimisation de la mmoire . . . . . . . . . . . . . . . . . . . . . . . .

Quantit de mmoire utilise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
svmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemples de sortie vmstat, ps et svmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmes perte de mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voir aussi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyse de lexploitation de la mmoire via BigFoot . . . . . . . . . . . . . . . . . . . . . . . . . .
Estimation de la mmoire requise via rmss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mthodes dexploitation de rmss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation du contrle de charge mmoire VMM . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation du contrle de charge mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation du remplacement de page VMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramtres minfree et maxfree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramtres minperm et maxperm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voir aussi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-1
7-2
7-2
7-2
7-3
7-3
7-4
7-4
7-5
7-6
7-6
7-14
7-14
7-16
7-16
7-17
7-18
Chapitre 8. Contrle et optimisation des E/S disque . . . . . . . . . . . . . . . . . . . . . . .

Prinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
laboration dune base doptimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
valuation des performances disque aprs installation . . . . . . . . . . . . . . . . . . . . .
valuation du placement physique des donnes sur disque . . . . . . . . . . . . . . . . .
Rorganisation dun groupe ou dun volume logique . . . . . . . . . . . . . . . . . . . . . . .
Rorganisation dun systme de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances et espaces de pagination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mesure des E/S disque globales via vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyse dtaille des E/S via filemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmes disque limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extension de la configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voir aussi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des lectures squentielles anticipes . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rgulation des E/S disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances et rpartition des volumes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conception dun volume logique rparti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des E/S dun volume logique rparti . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances et taille de fragment du systme de fichiers . . . . . . . . . . . . . . . . . . . .
Performances et compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances et E/S disque asynchrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances et E/S disque brutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances et sync/fsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modification du paramtre max_coalesce du pilote SCSI . . . . . . . . . . . . . . . . . . . . . .
Limites de la file dattente de lunit de disque et de la carte SCSI . . . . . . . . . . . . . .
Unit de disque non BULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pile de disques non BULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limitation des requtes externes sur une carte disque . . . . . . . . . . . . . . . . . . . . . .
Contrle du nombre de pbufs systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-1
8-1
8-2
8-2
8-3
8-5
8-6
8-7
8-7
8-8
8-9
8-10
8-10
8-11
8-13
8-13
8-15
8-16
8-16
8-17
8-18
8-19
8-20
8-21
8-22
8-23
8-23
8-23
8-24
8-25
Chapitre 9. Contrle et optimisation des E/S de communication . . . . . . . . . . . .

Performances UDP/TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de la mmoire du sous-systme de communication (mbuf) . . . . . . . . . .
9-1
9-2
9-3
Prface
Couche socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonctions UDP et TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Couche UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Couche TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Couche IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Couche IF (couche Demux sous AIX version 4.1) . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes rseau local et pilotes dunit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation de TCP et UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des files de transmission et de rception de la carte . . . . . . . . . . . .
Optimisation de la taille maximum de segment (MSS) TCP . . . . . . . . . . . . . . . . .
Optimisation des performances du protocole IP . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des performances Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des performances anneau jeton (4 Mo) . . . . . . . . . . . . . . . . . . . . .
Optimisation des performances anneau jeton (16 Mo) . . . . . . . . . . . . . . . . . . . .
Optimisation des performances FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des performances ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des performances SOCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des performances HIPPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation du pool mbuf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonction de gestion des mbuf : gnralits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des polls mbuf : quand ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des polls mbuf : comment ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rcapitulatif des paramtres doptimisation UDP, TCP/IP et mbuf . . . . . . . . . . . . . .
thewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sockthresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sb_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rfc1323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
udp_sendspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
udp_recvspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tcp_sendspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tcp_recvspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ipqmaxlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xmt_que_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rec_que_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voir aussi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nombre de biod et de nfsd requis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performances et montages logiciels et matriels de NFS . . . . . . . . . . . . . . . . . . .
Optimisation des retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation du cache dattribut de fichier NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dsactivation du support ACL NFS inutilis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation de la mise en cache des donnes NFS . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des autres couches pour amliorer les performances NFS . . . . . .
Augmentation de la taille du tampon du socket NFS . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du disque du serveur NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acclrateurs matriels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Du bon usage de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service des stations de travail sans disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Particularits dun systme sans disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Excution dun programme sur une station de travail sans disque . . . . . . . . . . . .
Pagination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ressources requises pour les stations de travail sans disque . . . . . . . . . . . . . . .
vi
9-3
9-5
9-5
9-6
9-10
9-11
9-11
9-12
9-12
9-13
9-21
9-23
9-23
9-24
9-24
9-24
9-25
9-25
9-25
9-26
9-26
9-27
9-29
9-31
9-31
9-31
9-32
9-32
9-32
9-32
9-33
9-33
9-33
9-34
9-34
9-35
9-35
9-36
9-36
9-37
9-38
9-38
9-39
9-39
9-39
9-39
9-40
9-40
9-40
9-41
9-41
9-41
9-42
9-44
9-45
Optimisation des performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Performance des commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etude de cas 1 Environnement de bureau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etude de cas 2 Environnement de dveloppement de logiciels . . . . . . . . . . . . .
Voir aussi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation des connexions asynchrones pour transferts haut dbit . . . . . . . . . . .
Configurations et objectifs des mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 8/16 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 64 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 128 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Techniques doptimisation du port asynchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transfert rapide de fichiers avec fastport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation des performances rseau avec netpmon . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyse des problmes de performance avec iptrace . . . . . . . . . . . . . . . . . . . . . . . . .
9-46
9-48
9-49
9-51
9-53
9-54
9-54
9-55
9-55
9-55
9-56
9-57
9-58
9-59
9-61
Chapitre 10. Optimisation des performances DFS . . . . . . . . . . . . . . . . . . . . . . . . .

Cache DFS sur disque ou en mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille du cache DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille de la tranche de mmoire cache DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nombre de tranches de cache DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Emplacement du cache disque DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille du tampon dtat du cache DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille des articles et lectures/critures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramtres de communication DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation du serveur de fichiers DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimisation LFS DCE pour les performances DFS . . . . . . . . . . . . . . . . . . . . . . . . . .
10-1
10-1
10-2
10-2
10-2
10-2
10-3
10-3
10-3
10-4
10-4
Chapitre 11. Analyse des performances avec lutilitaire de suivi . . . . . . . . . . . .

Prsentation de lutilitaire de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limitation de la quantit de donnes collectes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement et contrle du suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formatage des donnes de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Consultation des donnes de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple dutilisation de lutilitaire de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Obtention dun fichier de suivi chantillon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formatage de lchantillon de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interprtation dun compte rendu de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Filtrage du compte rendu de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement et contrle du suivi depuis la ligne de commande . . . . . . . . . . . . . . . . . .
Contrle du suivi en mode sous-commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrle du suivi par commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement et contrle du suivi depuis un programme . . . . . . . . . . . . . . . . . . . . . . . .
Contrle du suivi via les sous-routines de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrle du suivi via des appels ioctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ajout dvnements de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formes dun article vnement de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Canaux de suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Macros denregistrement des vnements de suivi . . . . . . . . . . . . . . . . . . . . . . . . .
ID dvnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemples de codage et de formatage dvnements . . . . . . . . . . . . . . . . . . . . . . .
Syntaxe des strophes du fichier de format de suivi . . . . . . . . . . . . . . . . . . . . . . . . .
11-1
11-2
11-2
11-2
11-3
11-3
11-4
11-4
11-4
11-5
11-5
11-6
11-6
11-6
11-7
11-7
11-7
11-9
11-9
11-9
11-10
11-10
11-11
11-13
Prface
vii
viii
Chapitre 12. Outil de diagnostic PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Structure de PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Porte de lanalyse PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de compte rendu PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation et activation de PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Personnalisation de PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rponse aux messages PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bote outils PTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostics en fonction dun symptme particulier . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ralentissement dun programme particulier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ralentissement gnral un moment donn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ralentissement gnral et imprvisible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ralentissement des programmes dun utilisateur particulier . . . . . . . . . . . . . . . . .
Ralentissement simultan de certains systmes du rseau local . . . . . . . . . . . . .
Ralentissement gnral intermittent sur une unit ou un service . . . . . . . . . . . . .
Diagnostics laide de PerfPMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrle avant modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des ressources limitatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aperu des performances du systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dtermination du facteur limitatif sur un programme . . . . . . . . . . . . . . . . . . . . . . . .
Disque ou mmoire ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de la charge de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-1
12-1
12-2
12-4
12-5
12-6
12-10
12-16
12-17
12-17
12-18
12-18
12-19
12-19
12-20
12-21
12-22
12-23
12-23
12-25
12-25
12-29
Chapitre 13. Gestion dun possible dfaut de performance AIX . . . . . . . . . . . . .

Base de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compte rendu du problme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Obtention et installation de PerfPMR (AIX version 3.2.5) . . . . . . . . . . . . . . . . . . . . . .
Installation de PerfPMR partir du Web (inclut la version 4) . . . . . . . . . . . . . . . . . . .
Donnes danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capture des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13-1
13-1
13-1
13-2
13-3
13-3
13-4
Annexe A. Commandes de contrle et doptimisation des performances AIX

Commande emstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commande schedtune . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commande vmtune . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Script pdt_config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Script pdt_report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-1
A-5
A-6
A-9
A-12
A-13
Annexe B. Sous-routines lies aux performances . . . . . . . . . . . . . . . . . . . . . . . . .
B-1
Annexe C. Mmoire cache et adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Prliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Consultation du cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Consultation du TLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accs RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C-1
C-1
C-1
C-3
C-4
C-4
C-5
Annexe D. Commande ld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Excutables rditables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bibliothques de sous-routines prdites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-1
D-1
D-1
D-2
Annexe F. Gestion de la mmoire des applications . . . . . . . . . . . . . . . . . . . . . . . .
F-1
Annexe G. Bibliothques partages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Avantages et inconvnients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dfinition dexcutables partags ou non . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Choix de loption approprie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G-1
G-1
G-1
G-1
Annexe H. Accs lhorloge du processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Accs lhorloge unique dune architecture POWER . . . . . . . . . . . . . . . . . . . . . . . . .
Accs aux registres dhorloge dans les systmes PowerPC . . . . . . . . . . . . . . . . . . .
Exemple dutilisation de la routine second . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H-1
H-2
H-3
H-3
Annexe I. Support NLS (National Language Support) . . . . . . . . . . . . . . . . . . . . . .

Remarques sur la programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quelques rgles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrle de lenvironnement local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I-1
I-1
I-2
I-2
Annexe J. Rcapitulatif des paramtres AIX optimisables . . . . . . . . . . . . . . . . .

Augmentation de la tranche horaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
arpt_killc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Calcul de la priorit dun processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compte biod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dcompte nfsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dog_ticks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intervalle de ressai fork() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intervalle syncd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ipforwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ipfragttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ipqmaxlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ipsendredirects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limites des requtes en sortie sur une carte disque . . . . . . . . . . . . . . . . . . . . . . . . . .
Longueur de file dattente dunit disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
loop_check_sum (version 3.2.5 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lowclust (version 3.2.5 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lowmbuf (version 3.2.5 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lvm_bufcnt (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maxrandwrt (AIX version 4.1.3 et ultrieure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maxbuf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
max_coalesce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maxfree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maxperm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maxpgahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maxpin (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maxpout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maxttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mb_cl_hiwat (version 3.2.5 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
minfree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
minperm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
minpgahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
minpout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nfs_chars (version 3.2.5), nfs_socketsize (AIX version 4.1) . . . . . . . . . . . . . . . . . . . .
nfs_gather_threshold (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nfs_portmon (version 3.2.5), portcheck (AIX version 4.1) . . . . . . . . . . . . . . . . . . . . . .
nfs_repeat_messages (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . .
nfs_setattr_error (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nfsudpcksum (version 3.2.5), udpchecksum (AIX version 4.1) . . . . . . . . . . . . . . . . .
J-1
J-1
J-1
J-2
J-2
J-3
J-3
J-3
J-4
J-4
J-4
J-5
J-5
J-5
J-6
J-6
J-6
J-7
J-7
J-7
J-8
J-8
J-8
J-9
J-9
J-9
J-10
J-10
J-10
J-11
J-11
J-11
J-12
J-12
J-13
J-13
J-13
J-14
J-14
J-14
Prface
ix
nonlocsrcroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
npskill (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
npswarn (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
numclust (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
numfsbuf (AIX version 4.1 seulement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramtres de contrle de charge mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
pd_npages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rec_que_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rfc1122addrchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rfc1323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
sb_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
subnetsarelocal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille de lespace de pagination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tcp_keepidle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tcp_keepintvl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tcp_mssdflt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tcp_recvspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tcp_sendspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tcp_ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
thewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
udp_recvspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
udp_sendspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
udp_ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xmt_que_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
J-15
J-15
J-15
J-16
J-16
J-16
J-17
J-17
J-17
J-18
J-18
J-18
J-19
J-19
J-19
J-20
J-20
J-20
J-21
J-21
J-21
J-22
J-22
J-22
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
X-1
A propos de ce manuel
Avertissement: Dans ce manuel, ce qui sapplique au DPX/20 sapplique galement aux
systmes Unix suivants : ESCALA et ESTRELLA.
Ce manuel, AIX - Guide doptimisation, donne des informations sur les concepts, les outils
et les techniques dvaluation et doptimisation dAIX sur les systmes ESCALA. Il traite de
la conception et de limplantation du systme et des applications, ainsi que de loptimisation
post-implantation de lutilisation de la CPU et de la mmoire, et des E/S disque et de
communication. La plupart des conseils doptimisation ont t tests ou valids sur la
version 3.2.5. Des prcisions sur AIX version 4.1 sont galement fournies. Les informations
qui ne sappliquent qu AIX version 4.1 sont signales dans le texte.
Destin aux administrateurs systme, programmeurs et utilisateurs finals concerns par
loptimisation des systmes AIX. Ce manuel suppose une bonne connaissance de
lenvironnement dexploitation AIX. Des sections de prsentation permettent aux utilisateurs
moins chevronns dacqurir les notions indispensables et aux autres de se familiariser
avec la terminologie propre loptimisation.
Ce manuel est une version totalement revue du manuel AIX version 3.2 Performance
Monitoring and Tuning Guide, tant au niveau de la structure que des conseils fournis.
Notons notamment les modifications intervenues au niveau du conditionnement et du
contenu des outils danalyse de performances dans AIX version 4.1.
Gestion des performances AIX : structure

Il existe des outils pour chaque phase de la gestion de loptimisation dAIX. Certains sont
fournis par Bull, dautres par des fournisseurs tiers. La figure suivante illustre les phases de
cette analyse dans un environnement rseau local simple et indique les outils applicables
chaque phase. Ce manuel donne galement des informations sur chaque phase.
extension
planification installation
(inoccup)
BEST/1
Predict
AIX SMIT
contrle
optimisation
(dsquilibr)
(quilibr)
AIX BOS
Perf. Toolbox
AIX PDT
BEST/1 Monitor
AIX BOS
BEST/1 Acquire
(surcharg)
BEST/1
Predict
Phases danalyse des performances et outils correspondants
Prface
xi
Outils et documentation
Le conditionnement des outils de performance permet lanalyste de ninstaller sur un
systme que les outils requis pour contrler et optimiser ce systme. Les modules et leurs
principales fonctions sont dcrits ci-aprs.
BEST/1
BEST/1 est un outil de planification de la capacit qui exploite des modles de mise en file
dattente pour prvaluer les performances dune configuration donne lors du traitement
dune charge donne. Les prvisions peuvent tre fondes sur :
les descriptions de charge issues dune application,
les donnes de la charge collectes par surveillance des systmes existants.
BEST/1 est constitu de trois modules principaux :
Collect
Collecte des informations dtailles sur le traitement dune charge par

un systme existant.
Analyze
Transforme les informations dtailles en comptes rendus et en un

modle de mise en file dattente de lactivit de traitement de la charge.
Predict
Utilise le modle de mise en file dattente pour estimer les effets de

modification de la charge ou de la configuration sur les performances.
BEST/1 pour UNIX est un produit de BGS Systems, Inc. Vous pouvez contacter BGS
Systems au 18008910000 (aux EtatsUnis).
Outil de diagnostic des performances AIX (PDT)

Loutil Performance Diagnostic Tool (PDT), lment installable en option dAIX version 4.1,
value la configuration du systme et dtermine les principaux axes dutilisation des
ressources. Si PDT dtecte un problme de performance, rel ou potentiel, il lindique
ladministrateur systme. Ce manuel traite des fonctions de PDT.
Systme dexploitation de base AIX (BOS)

Le systme dexploitation de base AIX propose un certain nombre doutils de contrle et
doptimisation, historiquement intgrs aux systmes UNIX ou requis pour grer les
caractristiques dimplantation propres AIX. Voici les fonctions et commandes BOS
essentielles lanalyse des performances :
xii
iostat
Rapporte les statistiques relatives la CPU et aux E/S.
lsattr
Affiche les attributs des units.
lslv
Affiche des informations sur un volume logique ou les affectations de volumes

logiques sur un volume physique.
netstat
Affiche le contenu des structures de donnes relatives au rseau.
nfsstat
Affiche des statistiques sur les activits NFS (Network File System) et RPC
(Remote Procedure Call).
nice
Excute une commande un niveau de priorit suprieur ou infrieur son

niveau normal.
no
Affiche ou dfinit des options rseau.
ps
Affiche ltat des processus.
renice
Modifie la priorit dun ou de plusieurs processus.
reorgvg
Rorganise laffectation des partitions physiques dans un groupe de volumes.
sar
Collecte et rend compte ou enregistre des informations sur lactivit du

systme.
time
Imprime la dure dexcution coule et les temps de traitement utilisateur et

systme attribus une commande.
trace
Enregistre et rend compte dvnements systme slectionns.
vmstat
Rend compte de lactivit de la mmoire virtuelle et dautres statistiques

systme.
Les commandes BOS AIX sont dcrites en dtail dans les manuels de rfrence de
commandes dAIX.
Bote outils Performance Toolbox (PTX)

La bote outils Performance Toolbox for AIX (PTX) propose des outils de contrle et
doptimisation de lactivit de systmes locaux et distants. Ce produit sous licence est
constitu de deux composants principaux : PTX Manager et PTX Agent. PTX Agent est
disponible sous licence distincte sous lappellation Performance Aide for AIX. La figure
illustre une configuration de rseau local simplifi o PTX Manager contrle lactivit de
plusieurs systmes.
Agent
Agent
Manager
Agent
xmperf
Display
Agent
Agent
Configuration de rseau local exploitant Performance Toolbox
Lobjectif principal de PTX Manager est de collecter et dafficher les donnes issues de
diffrents systmes de la configuration. xmperf est le principal programme ddi cet
objectif. Le principal programme utilis par lAgent pour collecter et transmettre les donnes
au Manager est xmservd.
Sous AIX version 4.1, outre les composants de base PTX, les produits sous licence
Performance Toolbox for AIX et Performance Aide for AIX proposent un ensemble doutils
de contrle et doptimisation distinct, dont lessentiel fait partie de BOS version 3.2.5 :
fdpr
Optimise un programme excutable pour une charge de travail donne.
filemon
Exploite lutilitaire de suivi pour contrler et rendre compte de lactivit

du systme de fichiers AIX.
fileplace
Affiche la position des blocs dun fichier dans des volumes physiques
ou logiques.
lockstat
Affiche des statistiques relatives aux verrouillages de noyau.
netpmon
Exploite lutilitaire de suivi pour rendre compte de lutilisation de CPU

par les E/S rseau et les activits relatives au rseau.
rmss
Simule des systmes dots de mmoires de tailles diffrentes pour

tester les performances.
svmon
Capture et analyse les informations concernant lexploitation de la

mmoire virtuelle.
syscalls
Enregistre et compte les appels systme.
Prface
xiii
tprof
Exploite lutilitaire de suivi pour rendre compte de lutilisation de CPU au

niveau module et instructions du code source.
bf
Rend compte des schmas daccs mmoire des processus (AIX

version 4.1 seulement).
stem
Autorise linstrumentation des entres/sorties au niveau sous-routine

des excutables existants (AIX version 4.1 seulement).
La principale documentation relative aux commandes et fonctions de PTX est le manuel

Performance Toolbox 1.2 and 2.1 for AIX: Users Guide, bien que la syntaxe des outils cits
plus haut soit documente dans le manuel AIX Commands Reference. Lutilisation des
commandes de la liste est intgre aux divers scnarios de diagnostics et doptimisation de
ce manuel.
Outil de collecte des donnes de performance PMR AIX (PerfPMR)

Loutil de collecte des donnes de performance PMR AIX (PerfPMR) sert collecter les
donnes de performances et de configuration, joindre un rapport signalant un dfaut
suppos au niveau des performances AIX. Ce manuel contient une description des
fonctions de PerfPMR.
Outils non pris en charge sous AIX version 4.1

Le programme rmap de compte rendu et de rduction des donnes de suivi nest pas pris
en charge par AIX version 4.1.
Mode demploi du manuel

Contenu
Ce manuel est compos des chapitres et annexes suivants :
Chapitre 1 : Performances : introduction lanalyse des performances. Pour les
utilisateurs dj familiers des techniques doptimisation, ce chapitre a surtout lintrt de
prsenter la terminologie propre ce type dopration.
Chapitre 2 : Gestion des ressources AIX : structures et algorithmes de base des
principaux composants de gestion des ressources AIX.
Chapitre 3 : Introduction au multitraitement : prsentation des performances des
systmes multi-traitement.
Chapitre 4 : Planification, conception et implantation : lments relatifs aux performances
prendre en compte lors de la prparation dune application.
Chapitre 5 : Contrle systme et diagnostics des performances : tapes prliminaires de
dtection dun problme de performance.
Chapitre 6 : Contrle et optimisation de la CPU : techniques de vrification de lutilisation
optimale des ressources CPU.
Chapitre 7 : Contrle et optimisation de la mmoire : dtermination de la quantit de
mmoire relle et virtuelle effectivement utilise, et techniques pour viter ou dtecter les
insuffisances courantes.
Chapitre 8 : Contrle et optimisation des E/S disque : description de la dynamique des
E/S disque sous AIX et effet des choix utilisateur sur cette dynamique.
Chapitre 9 : Contrle et optimisation des E/S de communication : techniques
doptimisation des diffrents types dE/S de communication.
Chapitre 10 : Optimisation des performances DFS : description des paramtres DFS
ayant une incidence sur les performances.
Chapitre 11 : Analyse des performances avec lutilitaire de suivi : explication dtaille de
lexploitation de lutilitaire de suivi, puissant outil doptimisation et base de nombreux
autres outils dcrits dans le manuel.
xiv
Chapitre 12 : Outil de diagnostic PDT : description dun nouvel outil dAIX version 4.1, qui
value les configurations au niveau de leur quilibre et tient jour un historique des
donnes de performance pour en identifier les tendances.
Chapitre 13 : Gestion dun possible dfaut de performance AIX : description de la marche
suivre pour signaler un possible dfaut de performance au niveau dAIX et du mode de
collecte et de transmission des donnes requises.
Annexe A : Commandes de contrle et doptimisation des performances AIX : liste des
commandes AIX les plus utiles pour le contrle et loptimisation dAIX et dtail de la
syntaxe et des fonctions des commandes schedtune, vmtune, pdt_config et
pdt_report.
Annexe B : Sous-routines lies aux performances : description de plusieurs sous-routines
lies aux performances.
Annexe C : Mmoire cache et adressage : aperu de limpact des caches sur les
performances des programmes.
Annexe D : Commande Id : techniques dutilisation de lditeur de liens AIX.
Annexe E : Outils de performance : consommation de ressources et temps de rponse
des outils de performance.
Annexe F : Gestion de la mmoire des applications : distinction entre les versions
dorigine et courante des sous-routines malloc et realloc.
Annexe G : Bibliothques partages : avantages et inconvnients des bibliothques
partages au niveau des performances.
Annexe H : Accs lhorloge du processeur : mthodes dutilisation de lhorloge du
processeur pour calculer des dures.
Annexe I : Support NLS (National Language Support) : effet de lutilisation du
support NLS (National Language Support) dAIX sur les performances.
Annexe J : Rcapitulatif des paramtres AIX optimisables : liste des paramtres dAIX
modifiables par lutilisateur, ayant une incidence directe ou indirecte sur les
performances.
Conventions typographiques
Voici les conventions typographiques adoptes dans ce manuel :
Gras
Commandes, sous-routines, mots-cls, fichiers, rpertoires et autres

lments dont le nom est prdfini par le systme. Objets graphiques
slectionner (boutons, tiquettes, icnes, etc.).
Italique
Paramtres dont le nom ou la valeur est fourni par lutilisateur.
Espacement
fixe
Exemples (de valeurs spcifiques, de texte affich, de code

programme), messages systme ou donnes entres par lutilisateur.
ISO 9000
Ce produit rpond aux normes qualit ISO 9000.
Bibliographie
Les manuels suivants concernent le contrle des performances :
AIX - Bibliographie, rfrence 86 F2 71WE.
AIX 4.3 Guide de lutilisateur : systme dexploitation et units,
rfrence 86 F2 97HX.
AIX 4.3 Guide dadministration : systme dexploitation et units,
rfrence 86 F2 99HX.
Prface
xv
AIX 4.3 Guide dadministration : communications et rseaux,

rfrence 86 F2 31JX.
AIX Commands Reference, rfrence 86 A2 38JX 86 A2 43JX.
AIX General Programming Concepts : Writing and Debugging Programs,
rfrence 86 A2 34JX.
AIX Technical Reference, Volume 1: Base Operating System and Extensions,
rfrence 86 A2 81AP.
AIX Technical Reference, Volume 2: Base Operating System and Extensions,
rfrence 86 A2 82AP.
Performance Toolbox 1.2 and 2.1 for AIX: Users Guide, rfrence 86 A2 10AQ.
Optimization and Tuning Guide for XL Fortran, XL C and XL C++,
rfrence 86 A2 99WG
Comer, D., Internetworking with TCP/IP Vol I, 2nd ed., Englewood Cliffs:
Prentice-Hall, 1991.
Ferrari, D., Serazzi, G., and Zeigner, A., Measurement and Tuning of Computer Systems,
New York: Prentice-Hall, 1983.
Lazowska, D., Zahorjan, J., Graham, G., and Sevchik, K., Quantitative System
Performance, New York: Prentice-Hall, 1984.
Leffler, McKusick, Karels, and Quarterman, The Design and Implementation of the
4.3 BSD Unix Operating System, Reading: Addison-Wesley, 1989.
Smith, C. U., Performance Engineering of Software Systems, Reading:
Addison-Wesley, 1990.
Stern, H., Managing NFS and NIS, Sebastopol, CA: OReilly & Associates, Inc., 1992.
Commande de manuels
Vous pouvez commander ces publications auprs de votre reprsentant commercial.
Si vous disposez du manuel AIX - Bibliographie, consultezle.
xvi
Chapitre 1. Performances
Toute personne exploitant un ordinateur a son opinion sur ses performances.

Malheureusement, ces opinions sont souvent bases sur des ides simplistes quant la
dynamique de lexcution des programmes. Des intuitions non tayes peuvent conduire
des interprtations errones et coteuses, sur les capacits dun systme et des solutions
aux problmes de performance perus.
Ce chapitre dcrit le fonctionnement dynamique des programmes et les concepts utiles
lvaluation des performances dun systme. Elle comporte les sections suivantes :
Vitesse dexcution : introduction la mesure des performances.
Estimation de la charge : dtermination des objectifs de performances.
Dynamique dexcution des programmes : identification des points de ralentissement
durant lexcution des programmes.
Dynamique systme : description de linteraction des programmes.
Vitesse dexcution
Les termes de vitesse et de rapidit, que lon continue demployer pour dcrire les
ordinateurs, font rfrence une ralit aujourdhui dpasse. Le temps nest plus en effet
o il tait possible de lire un programme, de calculer la somme des dures dexcution de
ses instructions pour valuer son temps dexcution. Le travail de milliers de programmeurs
et dingnieurs depuis trente ans a rendu ce type de calcul sinon impossible, du moins
dnu de sens.
Les machines daujourdhui sont plus puissantes que leurs anctres. Le remplacement des
lampes vide par des circuits intgrs et le raccourcissement significatif des cycles
dexcution ont certes contribu cette volution, mais les innombrables nouveauts en
matire darchitecture matrielle et logicielle ont t dcisives. Chaque avance en terme
de densit de circuit intgr fait progresser dautant les performances, non seulement parce
quune mme opration est alors excutable sur une surface moindre une vitesse
dhorloge suprieure, mais aussi parce que le gain despace induit offre aux ingnieurs un
nouvel espace dexprimentation. Bref, les machines ont vu leur capacit saccrotre en
gagnant la fois en complexit et en rapidit.
La complexit des machines modernes et des systmes dexploitation va de pair avec celle
de leur environnement. Outre lexcution de programmes individuels, les ordinateurs ont
aujourdhui grer un nombre variable dinterruptions imprvisibles issues des units dE/S
et de communication. Au point que les meilleures ides des ingnieurs, bases sur
lhypothse dun seul programme excut sur une machine autonome, sont aujourdhui
largement rattrapes et dpasses par les impondrables du monde rel. Ds lors quil est
tenu compte de ce caractre alatoire, certaines erreurs peuvent tre compenses. Les
gains et les pertes varient ainsi dun programme lautre au cours du temps.
Le solde net entre les gains et les pertes au niveau logiciel et matriel donne la
performance du systme. La rapidit dun systme est le dbit avec lequel il traite une
squence spcifique de demandes. Si les demandes simbriquent bien aux architectures
matrielle et logicielle du systme, on peut dire : Le systme excute rapidement cette
charge de travail. Nous ne pouvons pas dire Le systme est rapideou du moins, nous
ne le devrions pas.
Performances
1-1
Estimation de la charge
Lvaluation complte et exacte de la charge dun systme est dterminante pour la
prvision et lanalyse de ses performances. Toute variation de la charge a en effet
davantage dincidence sur la mesure des performances quune diffrence au niveau de la
vitesse dhorloge CPU ou de la taille de la RAM. La charge du systme doit tenir compte
non seulement du type et du dbit des demandes soumises, mais aussi de lensemble des
modules logiciels et des programmes dapplication internes impliqus.
Il convient de suivre au mieux lactivit des utilisateurs des applications existantes pour
disposer dune valuation exacte et dynamique de leur interaction avec les stations de
travail et les terminaux.
Veillez inclure dans votre valuation lactivit sousjacente du systme. Par exemple, si
le systme est dot de systmes de fichiers NFS frquemment sollicits par dautres
systmes, vous devez considrer ces accs comme une portion significative de la charge
globale, mme si le systme ne joue pas officiellement le rle de serveur.
Un raccourci risqu : les bancs dessai standard

Un banc dessai est une charge normalise destine servir de rfrence dans la
comparaison de systmes dissemblables. Tout banc dessai suffisamment prouv, devenu
standard de facto de lindustrie, est bien entendu tudi de faon exhaustive par les
dveloppeurs : systmes dexploitation, compilateurs et, dans certains cas, matriels ont
t optimiss pour exploiter ce banc dessai dans des temps record.
Mais, dans la ralit, les charges de travail concordent rarement avec les algorithmes et
lenvironnement dun banc dessai. En effet, ces bancs dessai standard, issus
dapplications relles, ont gnralement t simplifis et homogniss pour sadapter
une grande varit de platesformes matrielles. Par ailleurs, leur environnement
dexploitation a t restreint afin doffrir des conditions de mesure reproductibles.
Autrement dit, un raisonnement du type le systme A offre un dbit en mgax de 50 %
suprieur au systme B, donc le systme A doit excuter mon programme 50 % plus vite
que le systme B est tentant mais faux. Aucun banc dessai noffre une telle applicabilit
universelle. La seule utilit relle dun banc dessai est de rduire le champ des systmes
candidats une valuation srieuse. Il nexiste pas de substitut pour raliser une analyse
claire de votre charge de travail et des performances systmes impliques.
Objectifs de performances
Une fois la charge de travail value, vous pouvez dfinir vos critres de performances et
fixer vos objectifs en consquence. Les principaux critres de performances globales des
systmes informatiques sont le temps de rponse et le dbit. Le temps de rponse est le
laps de temps coul entre le lancement dune opration et lobtention des informations
utiles pour la reprise du travail, alors que le dbit est le nombre doprations comprises
dans la charge de travail et pouvant tre accomplies par unit de temps. La relation entre
ces mesures est complexe. Dans certains cas, vous devez modifier les deux mesures. Dans
dautres, une seule modification suffit amliorer la situation.
Pour une optimisation planifie, vous devez dterminer clairement vos objectifs en termes
de temps de rponse et de dbit pour une charge de travail prcise. Faute de quoi, vous
risquez de perdre temps et argent pour lamlioration dun aspect secondaire du systme.
Dynamique dexcution des programmes

Gnralement, un programmeur conoit son programme comme une squence continue
dinstructions excutant une fonction spcifique. Beaucoup defforts et de crativit ont t
dploys, au niveau du systme dexploitation et du matriel, pour conserver aux
programmeurs cette vision idalise, leur vitant trop de questions sur les notions despace,
de vitesse et de multiprogrammation/multitraitement. Les programmes reposant sur cette
vision illusoire risquent dtre inutilement coteux (en temps) et inefficaces en termes de
performances.
1-2
Une analyse claire des performances lies une charge de travail doit sappuyer sur un
modle dynamique et non statique de lexcution dun programme, comme illustr la
figure Hirarchie dexcution dun programme cidessous.
Matriel
Pipeline processeur
Cache
TLB
Mmoire
relle
Systme dexploitation
Instruction courante
Routine en cours de diffusion
Routines diffusables
Routines en attente/
Gestionnaires
dinterruption
Disque
Programmes
excutables
Hirarchie dexcution dun programme
Lors de son excution, un programme traverse, de faon plus ou moins parallle, la

hirarchie matrielle et logicielle. Plus lon slve dans la hirarchie matrielle, plus les
lments sont rares et coteux. La transition dun niveau lautre prend du temps, dautant
que, pour chaque ressource, le programme se trouve en concurrence avec dautres. Pour
analyser la dynamique dun programme, il faut en apprhender le fonctionnement chaque
niveau hirarchique.
Hirarchie matrielle
En gnral, le temps requis pour passer dun niveau matriel lautre correspond
approximativement au dlai de latence de niveau infrieur laps de temps entre lmission
dune requte et la rception des premires donnes.
Disques fixes
Lors de lexcution dun programme, lopration la plus coteuse en temps (hormis une
entre manuelle au clavier) est la rcupration de code ou de donnes stocks sur disque :
le contrleur de disque doit savoir quels blocs accder (temps dattente en file) ;
le bras du disque doit trouver le cyclindre concern (temps de recherche) ;
les ttes de lecture et dcriture doivent attendre le positionnement et la rotation des
blocs recherchs (dlai de rotation) ;
les donnes doivent tre transmises au contrleur (temps de transmission) et transfres
au programme dapplication (temps de traitement des interruptions).
Les oprations sur disque ont des origines diverses qui ne se limitent pas aux demandes
explicites dE/S effectues par un programme. Une grande part de loptimisation du systme
consiste souvent liminer les E/S disque inutiles.
Mmoire relle
La RAM est plus rapide que le disque, mais elle consomme davantage par octet. Les
systmes dexploitation tentent de conserver dans la RAM les codes et donnes
frquemment utiliss et de transfrer les donnes en sus sur le disque (ou du moins de ne
pas les transfrer initialement sur la RAM).
Cependant, la RAM nest pas ncessairement plus rapide que le processeur. Sur un
ESCALA, un dlai de latence RAM de plusieurs cycles processeurs scoule entre le
Performances
1-3
moment o le matriel dtecte la ncessit dun accs RAM et celui o les donnes ou les
instructions sont mises disposition du processeur.
Si laccs se fait sur une page de mmoire virtuelle stocke qui a t sur disque (ou
destine ltre), un dfaut de page se produit et le programme est suspendu jusqu ce
que la page soit lue depuis le disque.
Tampons TLB (Translation Lookaside Buffer)
La mmoire virtuelle est lun des moyens permettant de librer les programmeurs de tout
souci quant aux limites physiques du systme. Ils peuvent concevoir et coder des
programmes sans se proccuper de la capacit mmoire effective : cest le systme qui se
charge de traduire les adresses virtuelles des donnes et instructions du programme en
adresses relles, requises pour rcuprer ces donnes et instructions en RAM. Pour limiter
ces oprations de traduction, coteuses en temps, les adresses relles des pages de
mmoire virtuelle rcemment sollicites sont conserves dans une mmoire cache appele
tampon TLB (Translation Lookaside Buffer). Ainsi, tant que le programme sollicite un mme
jeu rduit de pages de donnes et de programmes, il est inutile de retraduire les adresses
chaque accs la RAM. En revanche, si le systme tente daccder une page de
mmoire virtuelle qui ne bnficie pas dune entre TLB (absence en TLB), des dizaines de
cycles processeurs (attente pour absence en TLB) sont gnralement ncessaires pour
traduire les adresses.
Mmoires cache
Pour limiter la frquence des dlais de latence RAM, les ESCALA sont quips de
mmoires cache destines aux instructions et aux donnes. Si linstruction ou les donnes
requises se trouvent dj en mmoire cache (prsence en cache), elles sont mises
disposition du processeur ds le cycle suivant (sans dlai dattente) ; sinon (absence en
cache), un temps dattente RAM se produit.
Certains systmes disposent de deux niveaux de mmoire cache, appels gnralement L1
et L2. Si une recherche est infructueuse sur le niveau L1, elle se poursuit sur le niveau L2.
En cas de nouvel chec, la recherche est reporte sur la RAM.
Sur les ESCALA, la taille et la structure des mmoires cache varient en fontion du modle
mais leur principe dexploitation est identique. Reportezvous lannexe C, Mmoire cache
et adressage pour une prsentation dtaille de larchitecture des mmoires cache et TLB pour information ou pour optimiser un programme de niveau infrieur.
Pipeline et registres
Larchitecture en pipeline, trs volutive, du ESCALA rend possible, dans certains cas, le
traitement simultan de plusieurs instructions. De vastes ensembles de registres gnraux
et de registres virgule flottante permettent de conserver une quantit considrable de
donnes de programme dans les registres, au lieu de les stocker et de les recharger
continuellement.
Les compilateurs doptimisation du ESCALA sont conus pour exploiter au mieux ces
fonctionnalits. Il est conseill de recourir aux compilateurs chaque gnration dun
programme excutable (mme court). Le manuel Optimization and Tuning Guide for XL
Fortran, XL C and XL C++ explique comment optimiser les programmes.
Hirarchie logicielle
Lors de son excution, un programme doit galement traverser diverses tapes dans la
hirarchie logicielle.
Programmes excutables
Lorsquun utilisateur demande lexcution dun programme, AIX accomplit un certain
nombre doprations pour rendre oprationnel le programme excutable sur disque. Tout
dabord, le systme recherche dans les rpertoires spcifis la variable denvironnement
courante PATH de lutilisateur la copie correcte du programme. Ensuite, le programme de
1-4
chargement du systme ( ne pas confondre avec lditeur de liens ld) rsout toutes les
rfrences externes du programme aux bibliothques partages.
Le systme dexploitation soumet la requte de lutilisateur sous forme dun processus,
cestdire dun ensemble de ressources, tel quun segment dadresse virtuelle prive,
comme le requiert tout programme excutable.
Sous AIX version 4.1, le systme dexploitation cre en outre automatiquement une routine
unique lintrieur de ce processus. Une routine est ltat dexcution actuel dune seule
instance dun programme. Sous AIX version 4.1, laccs au processeur et dautres
ressources est affect sur la base de routines et non de processus. Un programme
dapplication peut crer plusieurs routines au sein dun processus. Ces routines partagent
les ressources du processus dont elles dpendent.
Enfin, le systme se branche sur le point dentre du programme. Si la page de programme
contenant ce point dentre nest pas encore charge en mmoire (cas notamment dun
programme rcemment compil, excut ou copi), linterruption pour dfaut de page
provoque la lecture de la page.
Gestionnaires dinterruption
Lorsquun vnement externe se produit, le systme dexploitation en est averti par une
interruption de la routine en cours et le contrle est transfr un gestionnaire
dinterruptions. Au pralable, lessentiel de ltat matriel doit tre sauvegard pour que le
contexte de la routine puisse tre restaur une fois linterruption traite. Les gestionnaires
dinterruption appels pour la premire fois subissent tous les temps dattente lis au
passage dans la hirarchie matrielle (except ceux causs par des dfauts de page). Sauf
excution trs rcente du gestionnaire dinterruption (ou programmes impliqus
particulirement conomiques), il est peu probable que les codes ou les donnes soient
conservs dans les tampons TLB ou les mmoires cache.
Lorsque la routine interrompue est relance, son contexte dexcution (contenu des
registres par exemple) est logiquement restaur pour que la routine fonctionne
normalement. En revanche, le contenu des tampons TLB et des mmoires cache doit tre
reconstitu partir des demandes de programme qui ont suivi. Le gestionnaire
dinterruption et la routine dexcution subissent gnralement des temps dattente
importants du fait des absences en mmoire cache et en TLB rsultant de linterruption.
Routines en attente
Chaque fois quune requte soumise par un programme ne peut tre satisfaite
immdiatement (par exemple, opration dE/S explicite ou conscutive un dfaut de
page), la routine est mise en attente jusqu lexcution de la requte. Gnralement, des
temps dattente dans les tampons TLB et en mmoire cache sajoutent au temps requis
pour lexcution de la requte.
Routines diffusables
Une routine diffusable mais non encore excute est plus prjudiciable quutile. En effet, si
paralllement, des routines sont en cours dexcution, les lignes de mmoire cache (zones
du cache contenant les instructions et/ou les donnes de la routine voir annexe C :
Mmoire cache et adressage) peuvent tre rutilises et les pages de mmoire virtuelle
appeles, retardant davantage la diffusion de la routine.
Routine en cours de diffusion
Le programmateur choisit la routine dont la demande de processeur est la plus forte. (Les
considrations qui affectent ce choix sont discutes dans Performance du programmateur
de CPU AIX, page 2-2.) Une fois la routine diffuse, ltat logique du processeur au
moment de linterruption de la routine est restaur.
Instructions courantes
Sur les ESCALA, la plupart des instructions machine sont mme dexcuter un cycle
processeur unique, condition de ne pas rencontrer dabsence en cache ou en TLB. En
Performances
1-5
revanche, si un programme se branche rapidement sur diffrentes zones de lexcutable

et/ou accde des donnes issues de zones trs diverses (gnrant un taux dabsence en
cache et TLB lev), le nombre moyen de cycles processeur par instruction excute peut
tre bien suprieur un. On dit alors que le programme montre un faible regroupement
rfrentiel. Il peut utiliser le nombre minimum dinstructions ncessaires pour accomplir le
travail mais consommer un nombre excessif de cycles. Cette disparit entre le nombre
dinstructions et le nombre de cycles explique en partie quil nest plus possible dobtenir
directement une valeur de temps en calculant simplement la longueur du parcours sur le
listing du programme. Si un parcours rduit est gnralement plus rapide quun long
parcours, le rapport de vitesse peut diffrer sensiblement du rapport de longueur de
parcours.
Les compilateurs XL rorganisent les codes selon des mcanismes trs sophistiqus pour
rduire le nombre de cycles ncessaires lexcution du programme. Le premier souci du
programmeur dsireux doptimiser les performances doit tre de fournir au compilateur
toutes les informations requises et non de tenter de deviner et dappliquer ses techniques.
(Reportezvous Utilisation des prprocesseurs et des compilateurs XL, page 4-14.) Le
seul moyen de vrifier lefficacit de loptimisation est de mesurer les performances dune
charge de travail relle.
Dynamique systme
Crer des programmes individuels les plus efficaces possible ne suffit pas. Gnralement,
la personne responsable des performances na pas particip la cration des programmes
effectivement excuts. En outre, la plupart des niveaux de la hirarchie dcrits
prcdemment sont grs par une ou plusieurs parties dAIX. Dans tous les cas, ds lors
que des programmes dapplication ont t acquis et optimiss au mieux, le seul moyen
damliorer les performances globales du systme est dintervenir au niveau du systme.
Les principaux lments concerns sont :
Disques fixes
Le gestionnaire de volume logique (LVM) contrle lemplacement

des systmes de fichiers et des espaces de pagination sur le
disque, or lemplacement peut avoir un impact important sur le
temps de recherche ncessaire au systme.
Les pilotes dunit de disque contrlent lordre de traitement des
requtes dE/S.
Mmoire relle
Le gestionnaire de mmoire virtuelle (VMM) contrle le pool des

trames de mmoire virtuelle disponibles et dtermine quand et
qui voler des trames pour ralimenter le pool.
Routine en cours
Le programmateur dtermine lentit diffusable qui prendra le

contrle ensuite. (Sous AIX version 4.1, lentit diffusable nest
plus un processus mais une routine. Reportezvous Prise en
charge des routines sous AIX version 4.1, page 2-2).
E/S de
communication
Selon le type de charge et de liaison de communication, il peut

tre ncessaire de moduler la configuration des pilotes dunit de
communication, TCP/IP ou NFS.
Classes de charge de travail

Les charges de travail se rpartissent gnralement en un nombre limit de classes. Les
types cidessous servent le plus souvent classifier des systmes. Mais, un seul systme
tant gnralement sollicit pour traiter plusieurs classes, le terme charge de travail
semble plus appropri dans un contexte de performance.
1-6
Station de
travail
Charge de travail constitue dun seul utilisateur qui soumet des

travaux via le clavier natif du systme et en reoit les rsultats sur la
console native. En rgle gnrale, lobjectif de performance prioritaire
est, dans ce cas, un temps de rponse minimal pour le demandeur.
Multi
utilisateur
Charge de travail constitue de plusieurs utilisateurs qui soumettent

des travaux via leurs terminaux respectifs. En rgle gnrale, lobjectif
de performance prioritaire est, dans ce cas, un dbit maximum avec un
temps de rponse assorti dun seuil maximal, ou un temps de rponse
optimal pour une charge de travail relativement constante.
Serveur
Charge de travail constitue de requtes issues dautres systmes. Par

exemple, la charge de travail dun serveur de fichiers se compose en
majorit de requtes de lecture/criture sur disque. Il sagit, en
substance, du composant E/S disque dune charge multiutilisateur
(avec en sus lactivit NFS ou DFS), le mme objectif de dbit maximal
avec un temps de rponse limite sapplique. Les charges de serveur
peuvent galement se composer de programmes de calcul intensifs,
transactions de bases de donnes, travaux dimpression, etc.
Lorsquun seul systme traite des charges de travail de plusieurs types, utilisateurs et
analyste des performances doivent stre pralablement concerts sur les priorits relatives
des objectifs en cas de conflit entre diverses charges de travail.
Performances
1-7
Procdure doptimisation
Loptimisation est avant tout une question de gestion des ressources et de configuration du
systme. Voici les tapes de la procdure prconise :
1. Identification des charges de travail sur le systme.
2. Dfinition des objectifs :
a. Dtermination de la mthode dvaluation des rsultats.
b. Quantification et hirarchisation des objectifs.
3. Identification des ressources critiques limitant les performances du systme.
4. Rduction des contraintes de ressources critiques :
a. Utilisation de la ressource la plus approprie, si le choix est possible.
b. Rduction des contraintes de ressources critiques au niveau des programmes et des
fonctions systme.
c. Utilisation parallle des ressources.
5. Modification de laffectation des ressources en fonction des priorits :
a. Modification de la priorit ou des limites de ressources au niveau des programmes.
b. Modification de la configuration des paramtres de gestion des ressources systme.
6. Rptition des tapes 3 5 jusqu ce que les objectifs soient atteints (ou les ressources
satures).
7. Mise en uvre de ressources supplmentaires, le cas chant.
Identification des charges de travail

Identification des charges de travail Il est essentiel didentifier tous les travaux excuts sur
le systme. Sur les systmes connects un rseau local notamment, un ensemble
complexe de systmes de fichiers monts en croisements peut facilement se dvelopper,
avec un simple accord informel des utilisateurs des systmes. Ces lments doivent tre
identifis et pris en compte lors de loptimisation.
Dans le cas de charges multiutilisateur, lanalyste doit quantifier le volume moyen et
maximal des requtes. Il est essentiel de faire une valuation raliste de la dure
dutilisation effective du terminal par un utilisateur.
Il convient de dterminer le systme sur lequel effectuer les mesures et loptimisation :
systme de production ou autre (ou hors des priodes dexploitation) avec une version
simule de la charge effective. Il incombe lanalyste de choisir entre, dune part, les
rsultats issus dun environnement de production par nature, plus proches de
la ralit et, dautre part, la productivit maximale ralisable dans un environnement non
productif (conditions permettant de pratiquer des tests sans risquer de nuire aux
performances du systme).
Dfinition des objectifs

Les objectifs doivent tre dfinis quantitativement, mme si le rsultat souhait est souvent
exprim en termes subjectifs (par exemple, un temps de rponse satisfaisant). De plus,
lanalyste doit viser amliorer ce qui est important mme sil est plus tentant dintervenir
sur ce qui est mesurable. Si aucune mesure fournie par le systme ne correspond aux
amliorations recherches, il vous incombe den fixer une.
Quantifier les objectifs a certes pour finalit dorienter loptimisation vers la ralisation des
valeurs fixes, mais a surtout un rle essentiel quant la libert daction de lanalyste.
Il sagit en effet de dfinir, en concertation avec les utilisateurs, les priorits respecter.
Faute de cette entente pralable, lanalyste se verra sans cesse contraint de consulter les
1-8
intresss, de justifier les mesures quil prend, etc. Perte de temps et dnergie :
loptimisation du travail de lanalyste laisserait beaucoup dsirer. Si lexploitation et la prise
en charge du systme sortent du cadre de lentreprise, il convient de recourir un accord
de service crit entre utilisateurs et fournisseurs pour sassurer que les objectifs de
performance et les priorits ont t clairement compris.
Identification des ressources critiques

En gnral, les performances dune charge donne sont dtermines par la disponibilit et
la rapidit dune ou deux ressources systme critiques. Lanalyste se doit de les identifier
prcisment pour ne pas senfermer dans une boucle sans fin de tests et derreurs.
Les systmes sont dots de ressources relles et logiques. Les ressources critiques relles
sont gnralement plus faciles identifier, grce aux nombreux outils de performances
systme disponibles qui en testent lutilisation. Voici les ressources relles dont limpact sur
les performances est le plus frquent :
cycles CPU,
mmoire,
bus dE/S,
cartes diverses,
bras de disque,
espace disque,
accs rseau.
Lidentification des ressources logiques est moins vidente. Il sagit gnralement
dabstractions de programmation qui partitionnent les ressources relles. Le partitionnement
permet le partage et la gestion des ressources relles.
Voici des exemples de ressources relles partionnes en ressources logiques :
CPU
Tranche horaire CPU
Mmoire
Trames de page
Piles
Tampons
Files dattentes
Tables
Verrous et smaphores
Espace disque
Volumes logiques
Systmes de fichiers
Fichiers
Partitions
Accs rseau
Paquets
Canaux
Il est essentiel de tenir compte des deux types de ressources. En effet, des routines
peuvent tre bloques faute de ressources logiques comme de ressources relles.
Performances
1-9
Augmenter la ressource relle implique ne garantit pas la cration de ressources logiques

supplmentaires. Prenons, par exemple, un dmon dE/S de bloc NFS (biod,
reportez-vous Optimisation de NFS, page 9-36). Un biod est requis sur le client pour
traiter chaque requte NFS dE/S distante en attente. Le nombre doprations dE/S NFS
simultanes est donc limit par le nombre de biod. En cas de pnurie de biod, les
indicateurs de mesure du systme signalent que les liaisons CPU et de communications
sont relativement peu utilises. Vous pouvez ainsi avoir limpression fausse que le systme
est sous-utilis (et trop lent). Or, il sagit simplement dun manque de biod qui limite
lactivit du reste des ressources. Un biod utilise des cycles processeur et de la mmoire,
mais vous ne pouvez rsoudre ce problme en ajoutant simplement de la mmoire relle ou
en passant une CPU plus rapide. La solution consiste crer davantage de ressources
logiques (biod).
Des ressources logiques et des goulots dtranglement peuvent tre crs par inadvertance
pendant la dveloppement dapplications. Une mthode de transmission des donnes ou de
contrle dune unit peut en effet tre lorigine de la cration dune ressource logique.
Dans ce cas, vous ne disposez gnralement daucun outil pour grer lutilisation des
ressources cres ni dinterface pour contrler leur affectation. Par ailleurs, leur existence
nest souvent rvle que lorsque survient un problme spcifique.
Rduction des contraintes de ressources critiques

Choix de la ressource
Privilgier une ressource doit tre le fruit dune analyse minutieuse guide par des objectifs
prcis. Par exemple, pour le dveloppement dune application, il peut tre dcid dopter
pour une consommation CPU mininale, au dtriment de la consommation de mmoire.
De mme, lors de la configuration du systme, il faut dcider du lieu de stockage des
fichiers : localement sur une station de travail ou distance sur un serveur.
Rduction des contraintes

Les applications dveloppes localement doivent tre tudies pour dterminer la
possibilit daugmenter lefficacit dune fonction ou de supprimer des fonctions inutiles.
Au niveau de la gestion du systme, il peut tre envisag de transfrer sur dautres
systmes ou de diffrer les charges peu prioritaires demandant laccs des ressources
critiques.
Utilisation parallle des ressources

Pour leur excution, les charges de travail requirent plusieurs ressources systme. Il faut
donc exploiter le fait que celles-ci soient spares et utilisables en parallle. Par exemple,
les algorithmes de lecture anticipe sous AIX dtectent quun programme accde un
fichier squentiellement et planifient la lecture paralllement au traitement par lapplication
des donnes prcdentes. Ce traitement en parallle sapplique galement la gestion du
systme. Par exemple, si une application accde plusieurs fichiers simultanment, ajouter
une unit de disque et rpartir les fichiers concerns sur plusieurs disques ne peut
quamliorer le taux dE/S disque.
Modification de laffectation des ressources en fonction des priorits

AIX offre plusieurs mthodes pour affecter des niveaux de priorits aux activits. Certaines,
telles que la rgulation disque, sont dfinies au niveau systme. Dautres, telles que la
priorit des processus, peuvent tre dfinies par chaque utilisateur en fonction de
limportance attribue une tche donne.
Rptition des tapes doptimisation

Dans lanalyse des performances, il faut toujours partir du principe quun autre goulot
dtranglement va se produire. Diminuer lexploitation dune ressource se traduit
ncessairement par la rduction du dbit ou laugmentation du temps de rponse dune
autre ressource. Prenons un exemple.
1-10
CPU: 90%
Disk: 70%
Memory 60%
La charge de ce systme est concentre sur la CPU. Si lon rgule la charge de faon
ramener le taux dutilisation de la CPU 45 %, il est probable que les performances soient
doubles. En contrepartie, la charge est limite au niveau des E/S, comme suit :
CPU: 45%
Disk: 90%
Memory 60%
Lamlioration ct CPU permet aux programmes de soumettre plus rapidement les

requtes de disque mais la capacit maximale de lunit de disque est alors atteinte.
Lamlioration effective des performances est en fait de lordre de 30 % au lieu des 100 %
escompts.
Il y a toujours une nouvelle ressource critique. La question est de savoir si les objectifs ont
t atteints avec les ressources disponibles.
Mise en uvre de ressources supplmentaires

Si toutes les mthodes prcdentes nont pas permis datteindre les objectifs de
performancee du systme, il faut envisager damliorer ou daugmenter la ressource
critique. Sil sagit dune ressource logique et que la ressource relle correspondante
convient, la ressource logique peut tre augmente sans surcot. Sil sagit dune ressource
relle, plusieurs questions se posent :
De combien la ressource critique doit-elle tre augmente pour mettre fin au goulot
dtranglement ?
Cette extension sera-t-elle suffisante pour atteindre les objectifs de performance du
systme ?
Ou une autre ressource sera-t-elle sature avant cela ? Dans le cas o plusieurs
ressources critiques successives se prsentent, est-il plus conomique de les augmenter
toutes ou de transfrer une partie de la charge actuelle sur un autre systme ?
Performances
1-11
Essais comparatifs les donnes de performance sont

invitablement modifies
Lorsque lon compare les performances dun logiciel donn dans plusieurs environnements
diffrents, un certain nombre derreurs, techniques et conceptuelles, sont possibles. La
prsente section est une simple mise en garde. Dautres sections de ce manuel traitent des
diffrents moyens de mesure des temps couls et des temps spcifiques aux processus.
Lorsque lon mesure le temps (mesur sur lhorloge murale) ncessaire au traitement dun
appel systme, on obtient un nombre qui constitue la somme des lments suivants :
Temps rel dexcution des instructions de traitement du service.
Plusieurs priodes de temps pendant lesquelles le processeur a t bloqu dans lattente
dinstructions ou de donnes en provenance de la mmoire (cot des absences en
mmoire cache et/ou en TLB).
Temps requis pour accder lhorloge en dbut et en fin dappel.
Temps utilis par les vnements rguliers tels que les interruptions de lhorloge
systme.
Temps utilis par les vnements plus ou moins alatoires tels que les interruptions
dentre-sortie.
Pour minimiser les risques derreur, nous mesurons gnralement plusieurs fois la charge
de travail. Dans la mesure o tous les facteurs externes sajoutent au temps rel,
lensemble des mesures produit gnralement la courbe suivante :
Valeur relle
Moyennes des valeurs mesures
Rpartition des
valeurs mesures
Le faible niveau de la courbe en son extrmit peut indiquer une mise en mmoire cache
optimale de faible probabilit ou rsulter de larrondissement des valeurs.
Un vnement externe rgulier peut entraner la prsence de deux maxima sur la courbe.
Exemple :
Valeur relle
1-12
Moyenne
Une ou deux interruptions longues peuvent modifier encore davantage le trac de la

courbe :
Valeur relle
Moyenne
La rpartition des mesures autour de la valeur relle nest pas alatoire. Il convient donc
dappliquer avec prcaution les tests classiques de statistiques par dduction. En outre,
dans certains cas, ni la moyenne, ni la valeur relle ne caractrisent correctement les
performances.
Voir aussi
CPU
Performances du programmateur de CPU sous AIX : traite de la gestion de la CPU
sous AIX.
Contrle et optimisation de la CPU : prsente les outils et techniques de gestion de la
CPU.
Mmoire
Performances du gestionnaire de mmoire virtuelle (VMM) : dcrit larchitecture de
gestion de mmoire AIX.
Contrle et optimisation de la mmoire : prsente les outils et techniques de gestion de
la mmoire.
Disques
Gestion AIX du stockage sur disque fixe : dcrit la structure du support disque fixe sous
AIX.
Prinstallation du disque : traite de la planification des informations sur les
performances relatives des disques fixes de ESCALA.
Contrle et optimisation des E/S disque : traite du contrle de la rorganisation et de
lextension du stockage sur disque.
Performances
1-13
1-14
Chapitre 2. Gestion des ressources AIX
Ce chapitre dcrit les composants AIX de gestion des ressources ayant le plus dimpact sur
les performances du systme et indique comment les optimiser. Pour des conseils
doptimisation sur une ressource spcifique, reportez-vous au chapitre correspondant.
Performances du programmateur CPU sous AIX
Performances du gestionnaire de mmoire virtuelle (VMM)
Performances de gestion AIX du stockage sur disque fixe
Pour des conseils doptimisation spcifiques, reportez-vous :
Contrle et optimisation de la CPU
Contrle et optimisation de la mmoire
Contrle et optimisation des E/S disque
Gestion des ressources AIX
2-1
Performances du programmateur CPU sous AIX

Le programmateur CPU a t largement remani du fait de la nouvelle prise en charge des
routines sous AIX version 4.1. Dun point de vue conceptuel, lalgorithme de planification et
la politique dattribution des priorits nont pas chang par rapport la version 3.2.5, mais
dans le dtail, nombre de modifications ont t apportes. Pour les applications non
modifies et excutes sur des monoprocesseurs, limpact net des modifications est trs
faible. Cependant, toute personne concerne par loptimisation des performances doit tre
mme de comprendre les modifications et les nouvelles opportunits qui sont offertes.
Prise en charge des routines sous AIX version 4.1

Une routine est comparable un processus systme de niveau infrieur : il sagit dune
entit diffusable qui exige pour sa cration moins de ressources quun processus AIX. Dans
le programmateur dAIX version 4.1, la routine constitue lentit diffusable de base.
Cela ne signifie pas que les routines ont entirement supplant les processus. En fait, les
charges de travail qui ont subi une migration directement partir de versions prcdentes
dAIX crent des processus comme auparavant. Chaque nouveau processus est cr avec
une seule routine qui est en concurrence avec les routines des autres processus pour
laccs aux ressources CPU. Si le processus possde les ressources utilises lors de
lexcution, la routine, quant elle, ne possde que son tat courant.
Lorsque des applications nouvelles ou modifies crent des routines supplmentaires la
faveur du nouveau support de routines dAIX, cette cration a lieu dans le cadre du
processus. Les ressources partagent de ce fait le segment priv et les autres ressources du
processus.
Une routine utilisateur dans un processus est dote dune porte concurrentielle. Si la
porte concurrentielle est globale, la routine est en conccurrence avec toutes les autres
routines du systme pour laccs aux ressources CPU. (La routine cre en mme temps
quun processus est dote dune porte concurrentielle globale.) Si la porte est locale, la
routine est en concurrence uniquement avec les routines de son processus pour le partage
du temps CPU accord aux processus.
Lalgorithme qui permet de dsigner la routine suivante excuter est appel politique de
planification.
Planification des routines de porte concurrentielle globale ou locale

Trois politiques de planification sont disponibles sous AIX version 4 :
2-2
FIFO
La routine est excute jusqu son terme, sauf si un blocage se produit. Elle
utilise la CPU ou une routine dote dune priorit suprieure devient
diffusable. Seules les routines priorit fixe peuvent tre excutes en mode
FIFO.
RR
Cette priode est dfinie selon le mme mcanisme de rpartition par

permutation circulaire (RR) que celui utilis sous AIX version 3 (rpartition
par tranches horaires de 10 ms). La routine se place la fin de la file
dattente des routines diffusables de mme priorit lorsquelle sexcute au
bout dune priode de temps spcifie. Seules les routines priorit fixe
peuvent tre excutes en mode RR.
OTHER
Ce mode est dfini par implantation selon POSIX1003.4a. Sous AIX

version 4.1, le mode OTHER est dclar quivalent au mode RR, ceci prs
quil sapplique aux routines priorit variable. Dans ce cas, la priorit de la
routine en cours est recalcule chaque interruption dhorloge si bien que la
routine peut tre amene passer le contrle une autre routine diffusable.
Cest le mcanisme appliqu sous AIX version 3.
Les routines sont particulirement utiles pour les applications composes de plusieurs
processus asynchrones : ces applications peuvent soumettre au systme une moindre
charge ds lors quelles sont converties en structures multiroutines.
Priorit des processus et des routines

Les outils de gestion des priorits disponibles sous la version 3.2.5 manipulent les priorits
au niveau des processus. Sous AIX version 4.1, la priorit dun processus ne fait
quannoncer celle de la routine. Appeler fork() entrane la cration dun processus
contenant une routine. Cest la routine qui reoit le niveau de priorit auparavant attribu au
processus sous la version 3.2.5 dAIX. La prsente description est applicable aux deux
versions.
Le noyau tient jour pour chaque routine une valeur de priorit (aussi appele priorit de
planification). La priorit est dfinie par un entier positif, inversement proportionnel
limportance de la routine associe. Autrement dit, une valeur de priorit faible dsigne une
routine importante. Lorsque le programmateur cherche la routine suivante diffuser, il
choisit celle dont la priorit a la valeur la plus basse.
Une priorit peut tre fixe ou variable. Une priorit fixe a une valeur constante tandis que la
priorit dune routine priorit variable est la somme de la priorit minimale des routines
utilisateur (constante 40), de la valeur nice (20 par dfaut ou valeur dfinie par la
commande nice ou renice) et de la pnalit dutilisation CPU. La figure Evolution de la
valeur de priorit illustre cette volution.
A linitiation Au bout dun temps
de la routine dexcution
pnalit CPU
Valeur
priorit
(valeur
faible
priorit
leve)
valeur nice
20 par dfaut
priorit de
base 40 par
dfaut
valeur nice
reste gale
20
priorit de
base
constante
40
Aprs
renice 5
Aprs
setpri()
50
pnalit CPU
valeur nice
15
priorit de
base
constante
40
Priorit fixe
de 50
valeur nice et
utilisation
CPU
sans objet
Evaluation de la valeur de priorit

La valeur nice dune routine, dfinie lors de la cration de la routine, est constante pendant
toute la dure de vie de la routine, sauf changement explicite par un utilisateur via la
commande renice ou les appels systme setpri, setpriority ou nice.
La pnalit CPU est un nombre entier calcul daprs lutilisation rcente de la CPU par une
routine. Cette valeur est incrmente de 1 chaque fois que la routine utilise la CPU pendant
une tranche horaire (10 ms), jusqu une valeur maximale de 120. Une fois par seconde, les
valeurs dutilisation rcente de la CPU de toutes les routines sont rduites. Le rsultat
obtenu est :
La priorit dune routine priorit variable dcrot au fur et mesure que lutilisation
rcente de la CPU saccrot, et inversement. Il en dcoule que, en moyenne, plus une
routine a rcemment bnfici de tranches horaires, moins elle a de chance dtre
daffecte la tranche horaire suivante.
La priorit dune routine priorit variable dcrot au fur et mesure que la valeur nice
saccrot, et inversement.
2-3
La priorit dune routine peut tre fixe via la sous-routine setpri. La commande ps permet
dafficher la priorit, la valeur nice et les valeurs dutilisation CPU court terme dun
processus.
Pour en savoir plus sur les commandes nice et renice, reportez-vous Contrle des
conflits pour CPU, page 6-20.
Pour en savoir plus sur le calcul de la pnalit CPU et la diminution des valeurs dutilisation
de la CPU court terme, reportez vous Optimisation du calcul des priorits dun
processus via schedtune, page 6-23.
File dattente dexcution du programmateur dAIX

Le programmateur maintient une file dattente dexcution de toutes les routines prtes
tre diffuses. La figure File dattente dexcution en est une illustration symbolique.
priorit n
routine aaa
routine bbb
priorit n+1
routine iii
routine jjj
priorit n+2
routine xxx
routine yyy
routine ccc
File dattente dexcution

Les routines diffusables dun niveau de priorit donn se suivent dans la file dattente
dexcution.
Lorsquune routine est place en fin de file dattente dexcution (par exemple, lorsquelle
sexcute la fin dune tranche horaire), elle est positionne aprs la dernire routine en
attente dote de la mme priorit.
Tranche horaire CPU

La tranche horaire CPU est lintervalle entre deux recalculs de la priorit. En temps normal,
ce calcul est effectu chaque impulsion de lhorloge systme, cest--dire toutes les
10 millisecondes. Loption t de la commande schedtune (voir page A-6) permet
daugmenter cet intervalle par incrments de 10 millisecondes. Rappelons quune tranche
horaire ne correspond pas une quantit garantie de temps processeur. Il sagit de la dure
maximale pendant laquelle une routine peut sexcuter sans risquer dtre remplace par
une autre. Il existe plusieurs cas de figure o une routine peut tre supplante par une autre
avant de bnficier dune tranche horaire complte.
Voir aussi
Commandes nice, ps et renice
Sous-routine setpri
Sous-routines getpriority, setpriority et nice.
2-4

Lespace dadresse virtuelle du ESCALA est partitionn en segments (pour une description
dtaille de la structure dadressage virtuelle, reportez vous lannexe C, Mmoire cache
et adressage). Un segment est une portion contigu de 256 Mo de lespace dadresse
virtuelle dans laquelle un objet de donnes peut tre mapp. Ladressage
processus-donnes est gr au niveau du segment (ou objet) de sorte quun segment peut
tre partag par des processus ou rester priv. Par exemple, des processus peuvent
partager des segments de codes, mais disposer de segments de donnes privs distincts.
Le gestionnaire de mmoire virtuelle (VMM) est dcrit dans les sections suivantes :
Gestion de la mmoire relle
Utilitaire de contrle de loccupation mmoire
Affectation et rclamation demplacements dans lespace de pagination
Gestion de la mmoire relle

Les segments de mmoire virtuelle sont partitionns en units de taille fixe appeles pages.
La taille dune page sous AIX est de 4 096 octets. Chaque page dun segment peut tre
implante dans la mmoire relle (RAM) ou stocke sur disque tant quelle nest pas
utilise. De mme, la mmoire relle est divise en trames de page de 4 096 octets. Le rle
de VMM est de grer laffectation des trames de page de mmoire virtuelle et de rsoudre
les rfrences dans le programme aux pages de mmoire virtuelle qui ne se trouvent pas
en mmoire relle ou nexistent pas encore (cest par exemple le cas lorsquun processus
fait rfrence pour la premire fois une page de son segment de donnes).
La quantit de mmoire virtuelle utilise un instant donn pouvant tre suprieure la
capacit de la mmoire relle, VMM se charge de stocker le surplus sur disque. En terme
de performances, VMM doit remplir deux objectifs, quelque peu contradictoires :
Rduire le cot global en temps processeur et largeur de bande induit par lutilisation de
la mmoire virtuelle.
Rduire le cot en temps de rponse des dfauts de page.
Dans cette optique, le gestionnaire VMM tient jour une liste des disponibilits de trames
de page en cas de dfaut de page. Il utilise un algorithme de repositionnement de page
pour dterminer les pages de mmoire virtuelle actuellement en mmoire dont les trames
doivent tre raffectes la liste des disponibilits. Le mcanisme de lalgorithme de
repositionnement de page est le suivant :
Les segments de mmoire virtuelle sont rpartis en segments persistants et segments de
travail.
Les segments de mmoire virtuelle sont rpartis en deux autres catgories selon quils
contiennent de la mmoire de calcul ou de la mmoire de fichier.
Les pages de mmoire virtuelle lorigine dun dfaut de page sont recherches.
Parmi les dfauts de page, lalgorithme distingue les dfauts de nouvelle page initiale et
les dfauts de page dj rfrence.
Les statistiques sont tenues jour sur la base des dfauts de pages dj rfrences au
niveau de chaque segment de mmoire virtuelle.
Les limites infrieures dfinies par lutilisateur sont prises en compte par lalgorithme.
Le mcanisme de lalgorithme et du systme de liste des disponibilits est dtaill ci-aprs.
2-5
Liste des disponibilits

Le gestionnaire VMM tient jour la liste des trames de pages disponibles pour faire face
aux dfauts de page. Dans la plupart des environnements, VMM doit mettre jour cette
liste en raffectant les trames de page des processus en cours. Cest lalgorithme de
repositionnement de page de VMM qui dcide des pages de mmoire virtuelle dont les
trames doivent tre raffectes. Le nombre de trames concernes dpend des seuils dfinis
dans VMM.
Sous AIX version 3, le contenu des trames de page raffectes dans la liste des
disponibilits nest pas perdu. Si une page de mmoire virtuelle rfrence avant la trame
quelle occupe est utilise pour compenser un dfaut de page, la trame en question est
supprime de la liste et raffecte au processus dfaillant. Ce phnomne est appel une
rclamation. Les rclamations ne sont pas prises en charge par AIX version 4.1.
Segments persistants et segments de travail

Les pages dun segment persistant bnficient demplacements de stockage permanents
sur disque. Les fichiers contenant des donnes ou des excutables sont mapps des
segments persistants. Ainsi, lorsquune telle page est modifie et ne peut plus tre
conserve en mmoire relle, VMM la rinstalle lemplacement qui lui est rserv. Si la
page na pas t modifie, sa trame est simplement raffecte dans la liste des
disponibilits. Enfin, si elle est de nouveau rfrence, VMM en cre une copie partir de
lemplacement permanent.
Les segments de travail sont des segments temporaires qui ne bnficient pas
demplacements de stockage permanents et dont la dure de vie est limite leur temps
dutilisation par un processus. Les piles de processus et les zones de donnes sont
mappes ces segments de travail, de mme que les segments de texte du noyau et de
lextension du noyau, ainsi que les segments de donnes et de texte des bibliothques
partages. Lorsquelles ne peuvent tre conserves en mmoire relle, les pages des
segments de travail sont galement stockes sur le disque. Le stockage a lieu dans
lespace de pagination du disque.
La figure Segments de stckockage de travail et persistants illustre les relations entre
certains types de segment et lemplacement de leurs pages sur le disque. Elle indique
galement les emplacements rels (arbitraires) des pages se trouvant en mmoire relle.
0 . . . intervalle dadressage . . . . 256 Mo

Processus
Segment de texte de
programme (persistant)
Fichier segment de donnes

et de piles (de travail)
Routine(s)
0 . . . . . .trames de page de 4 ko . . . . . . . . . n
Mmoire
relle
Espace de
pagination
Segment de bibliothque
partage (de travail)
Pages
touches
Fichier
excutable
E/S
relles
Segments persistants et segments de travail

Il existe diffrents types de segments persistants. Les segments client sont utiliss pour
mapper les fichiers distants (tels que les fichiers accessibles via NFS) parmi lesquels les
fichiers excutables. Les pages des segments client sont sauvegardes et restaures via le
rseau, leur emplacement de fichier permanent et non dans lespace de pagination du
disque local. Les segments journaliss et diffrs sont des segments persistants qui doivent
tre mis jour de faon atomique. Si une page dun segment journalis ou diffr est
slectionne pour tre te de la mmoire relle (dcharge), elle doit tre copie dans
2-6
lespace de pagination du disque ( moins que son tat nautorise sa validation, cest--dire
son inscription lemplacement de fichier permanent).
Mmoire de calcul et mmoire de fichier

La mmoire de calcul est constitue des pages appartenant aux segments de stockage de
travail ou aux segments de texte de programme. (Un segment est considr comme texte
de programme si une absence en cache dinstructions se produit sur nimporte laquelle de
ses pages.) La mmoire de fichier est constitue par les autres pages.
Repagination
Il existe deux catgories de dfaut de page : dfaut de nouvelle page et dfaut de page
dj rfrence. Les dfauts qui relvent de la premire catgorie se produisent
lorsquaucun article de la page concerne na t rfrenc rcemment. Ceux de la
seconde catgorie concernent les pages dj rfrences qui le sont nouveau, mais ne
se trouvent pas en mmoire car elles ont t dplaces depuis (ventuellement sur disque).
Une politique idale de repositionnement de page serait dliminer entirement les dfauts
de page dj rfrence (en admettant que la mmoire relle soit suffisante) par le vol
systmatique des trames des pages qui ne sont pas appeles tre de nouveau
rfrences. Ainsi, le nombre de ces dfauts de page est inversement proportionnel
lefficacit de lalgorithme de repositionnement, du fait du vol continu des pages en mmoire
(rduisant dautant le volume global des E/S au profit des performances du systme).
Pour estimer la catgorie du dfaut de page, VMM tient un tampon historique des pages
rfrences o sont consigns les ID des pages ayant fait lobjet des N dfauts de page les
plus rcents (N tant le nombre maximum de trames que la mmoire peut contenir). Par
exemple, une mmoire de 16 Mo requiert un tampon de 4 096 entres pour lhistorique des
pages rfrences. Si lID de la page en entre figure dj dans le tampon, la page est
considre comme dj rfrence. VMM value galement les taux de dfauts de page
rfrence en mmoire de calcul et en mmoire de fichier sparment, en tenant un
compte distinct pour chaque type de mmoire. Ces taux sont multiplis pas 0,9 chaque
excution de lalgorithme pour donner une image de lactivit rcente de repagination plus
fidle que lhistorique.
Seuils VMM
Plusieurs seuils numriques dfinissent les objectifs de VMM. Lorsquun de ces seuils est
dpass, VMM prend les mesures ncessaires pour ramener ltat de la mmoire
lintrieur des limites dfinies. Cette section traite des seuils modifiables par ladministrateur
systme via la commande vmtune.
Le nombre de trames de page figurant dans la liste des disponibilits est contrl par les
paramtres :
minfree
Nombre minimum de trames de page mmoire relle admissibles dans

la liste des disponibilits. Lorsque la taille de la liste des disponibilits
passe en dessous de ce seuil, VMM commence voler des pages. Il
continue en voler jusqu ce que la taille de la liste des disponibilits
atteigne maxfree.
maxfree
Taille maximale que la liste des disponibilits peut atteindre sous leffet
du vol de pages effectu par VMM. Il peut arriver que la liste dpasse
cette taille, lorsque les processus se terminent et librent les pages des
segments de travail ou que des fichiers possdant des pages en
mmoire sont supprims.
VMM tente de maintenir la liste une taille au moins gale minfree. Si, du fait des dfauts
de page et/ou des requtes systme, la taille descend en-de de minfree, lalgorithme de
repositionnement de page sexcute. Il est ncessaire de respecter une taille minimale
(valeur minfree, par dfaut) pour plusieurs raisons. Par exemple, lalgorithme de
prrecherche squentielle dAIX requiert plusieurs trames simultanment pour chaque
processus effectuant une lecture squentielle. De mme, VMM doit veiller ce que
2-7
suffisamment despace soit disponible pour charger une page ncessaire la libration
dune trame de page, faute de quoi un blocage du systme risque de se produire.
Les seuils suivants sont exprims en pourcentages. Ils reprsentent la fraction de la
mmoire relle totale occupe par des pages de fichiers (nappartenant pas un segment
de mmoire de calcul).
minperm
Si le pourcentage de mmoire relle occupe par les pages de fichiers

est infrieur ce niveau, lalgorithme de repositionnement de page vole
la fois les pages de mmoire de calcul et de mmoire de fichier sans
tenir compte des taux de repagination.
maxperm
Si le pourcentage de mmoire relle occupe par les pages de fichiers

dpasse ce niveau, lalgorithme de repositionnement de page ne vole
que les pages de fichiers.
Lorsque le pourcentage de mmoire relle occupe par les pages de fichier est compris
entre minperm et maxperm, VMM ne vole gnralement que les pages de fichiers, mais si
le taux de repagination des pages de fichiers est suprieur celui des pages de mmoire
de calcul, il vole galement ces dernires.
Lalgorithme de repositionnement de page sassure que les pages de mmoire de calcul
sont correctement traites. Par exemple, la lecture squentielle dun fichier de donnes
volumineux stock en mmoire ne doit pas entraner la perte de pages de texte dun
programme susceptibles dtre sollicites court terme. Par le truchement des seuils et des
taux de repagination, lalgorithme contrle le traitement des deux types de page (en
accordant une lgre prfrence aux pages de mmoire de calcul).
Utilitaire de contrle de loccupation mmoire

Lorsquun processus fait rfrence une page de mmoire virtuelle non stocke sur le
disque (quelle ait t dcharge ou jamais charge), la page concerne doit tre charge
et, le plus souvent, une ou plusieurs pages doivent tre dcharges. Ces oprations
gnrent un flux dE/S et retardent la progression du processus.
AIX tente, via lalgorithme de repositionnement de page, de voler de la mmoire relle des
pages peu susceptibles dtre rfrences court terme. Un algorithme efficace permet au
systme dexploitation de conserver en mmoire suffisamment de processus actifs pour
maintenir la CPU en activit. Mais, un certain niveau de sollicitation de mmoire (fonction
de la capacit mmoire totale du systme, du nombre de processus, de lvolution des
besoins en mmoire de chaque processus et de lalgorithme de repositionnement de page),
aucune page ne peut tre dcharge sur le disque car elles sont toutes susceptibles dtre
rutilises court terme par les processus actifs.
Dans ce cas, les pages sont continuellement charges et dcharges. Ce phnomne est
appel emballement. Lemballement gnre une activit incessante dE/S sur le disque de
pagination et rpond ds la diffusion dun processus par un dfaut de page quasi
systmatique. Mais laspect le plus pernicieux de lemballement est quil entrane le systme
dans une boucle infinie alors mme quil na t provoqu que par un excs bref et fortuit de
la charge (par exemple, si tous les utilisateurs du systme appuient sur la touche Entre
la mme seconde).
AIX dispose dun algorithme de contrle de la charge mmoire qui, lorsquil dtecte un
emballement du systme, interrompt des processus actifs et retarde quelque temps le
lancement de nouveaux processus. Cinq paramtres dfinissent les taux et les seuils pour
lalgorithme. Les valeurs par dfaut de ces paramtres ont t choisies pour sadapter un
vaste ventail de types de charges de travail. Dans certains cas, il est possible de recourir
un mcanisme de modulation (ou de dsactivation) du contrle de charge (reportez-vous
Optimisation du contrle de charge mmoire VMM, page 7-14).
2-8
Algorithme de contrle de la charge mmoire

Le mcanisme de contrle de charge mmoire value, toutes les secondes, si la mmoire
disponible est suffisante pour le jeu de processus actifs. Lorsquune surcharge mmoire est
dtecte, certains processus sont interrompus, ce qui rduit le nombre de processus actifs
et le taux de surcharge de la mmoire : ds que leur tat le permet, lexcution de leurs
routines est suspendue. Les pages des processus interrompus deviennent rapidement
obsoltes et sont dcharges par lalgorithme de repositionnement de page. Cette
opration libre suffisamment de trames de page pour permettre aux processus actifs
restants de continuer. Dans lintervalle de suspension des processus, les nouveaux
processus crs sont galement interrompus, empchant toute nouvelle arrive de travaux
sur le systme. Les processus interrompus ne sont ractivs quau bout dun certain laps de
temps - o aucun risque demballement ne sest manifest. Une fois cet intervalle de
scurit coul, les routines des processus interrompus sont progressivement ractives.
Les paramtres de contrle de la charge mmoire spcifient : le seuil de surcharge de la
mmoire systme, la dure (en secondes) de lintervalle de scurit, le seuil de surcharge
dun processus au-del duquel son interruption est juge possible, le nombre minimum de
processus actifs lors de linterruption de processus et le dlai minimum (en secondes) entre
la suspension dun processus et sa ractivation.
Ces paramtres et leur valeur par dfaut (entre parenthses) sont les suivants :
h
Seuil haut de surcharge mmoire (6)
Attente avant la ractivation des processus suspendus (1 seconde)
Seuil de surcharge de la mmoire pour un processus (4)
Degr minimum de multiprogrammation (2)
Dlai coul sans interruption (2 secondes)
Les valeurs de tous ces paramtres sont des entiers positifs.

Paramtre h
Le paramtre h dfinit le seuil de surcharge de la mmoire. Le systme de contrle de
charge mmoire tente dinterrompre les processus lorsque ce seuil est dpass pendant
une seconde. Ce seuil est issu de deux mesures directes : le nombre de pages inscrites
dans lespace de pagination pendant la dernire seconde, et le nombre de vols de pages
ayant eu lieu durant cette mme dernire seconde. Le nombre dcritures de pages est
gnralement nettement infrieur au nombre de vols de page. La mmoire est considre
surcharge lorsque :
nombre de pages crites lors de la dernire seconde
nombre de pages voles lors de la dernire seconde
>
1
h
Plus ce rapport augmente, plus le risque demballement est grand. La valeur par dfaut de
h est 6, ce qui signifie quil y a risque demballement du systme lorsque le rapport entre le
nombre de pages crites et le nombre de pages voles est suprieur 17 %. Une valeur de
h infrieure (pouvant aller jusqu 0, le test tant effectu sans effectuer une division relle)
augmente le seuil de dtection du phnomne demballement. Autrement dit, le systme est
autoris sapprocher davantage des conditions demballement avant que ne se dclenche
linterruption des processus. Le rapport ci-dessus a t choisi car il est relativement peu
dpendant de la configuration. Quels que soient la capacit de pagination du disque et le
nombre de mgaoctets de mmoire installe sur le systme, un rapport faible diminue les
risques demballement. Un rapport avoisinnant la valeur 1 signifie un emballement certain.
Tout laps de temps pendant lequel la mmoire nest pas surcharge peut tre dfini comme
priode sre.
Paramtre w
Le paramtre w contrle le nombre dintervalles de 1 seconde durant lesquels le rapport
ci-dessus doit tre infrieur 1/h avant ractivation des processus interrompus. La valeur
2-9
par dfaut, 1 seconde, est proche de la valeur minimale admise (zro). Une valeur de
1 seconde tente de ractiver les processus ds expiration du dlai de scurit de
1 seconde. Si une valeur plus leve est attribue w, les temps de rponse pour les
processus interrompus risquent dtre inutilement longs, le processeur tant inactif faute de
processus.
Paramtre p
Le paramtre p dtermine si un processus peut tre interrompu. Analogue au paramtre h,
le paramtre p permet de dfinir un seuil applicable au rapport entre deux mesures
concernant tous les processus : le nombre de pages dj rfrences (dfini la section
relative lalgorithme de repositionnement de page) et le nombre de dfauts de page
cumuls par le processus durant la dernire seconde. Un rapport lev indique que le
processus semballe. Un processus est candidat la suspension (soit parce quil semballe
soit parce quil contribue lemballement de lensemble) si :
nombre de pages rfrences au cours de la dernire seconde
nombre de dfauts de page au cours de la dernire seconde
>
1
p
Par dfaut, p prend la valeur 4, ce qui signifie quun processus est considr comme
semballant (et donc candidat la suspension) ds lors que le rapport entre les pages
rfrences et les dfauts de page cumuls au cours de la dernire seconde est suprieur
25 %. Une valeur faible de p (pouvant atteindre zro, le test neffectuant pas rellement la
division) autorise le systme sapprocher davantage des conditions demballement avant
que ne se dclenche linterruption des processus. La valeur zro signifie quaucun
processus ne peut tre interrompu par le systme de contrle de charge mmoire.
Paramtre m
Le paramtre m dtermine la limite infrieure du degr de multiprogrammation. Le degr de
multiprogrammation est dfini comme le nombre de processus actifs (non suspendus).
(Chaque processus compte pour un, quel que soit le nombre de routines quil excute.) Ne
sont pas comptabiliss le processus noyau et les processus priorit fixe infrieure
60 (1), mmoire fixe (2) ainsi que les vnements en attente (3), aucun processus de
cette catgorie ne pouvant tre interrompu. La valeur 2 par dfaut garantit quau moins
deux processus utilisateur sont toujours activables. Une valeur infrieure dem, lorsquelle
est autorise, indique que par moments un seul processus utilisateur peut tre actif. Des
valeurs suprieures de m retirent au systme de contrle de charge la possibilit
dinterrompre des processus. Ce paramtre dpend fortement de la configuration et de la
charge. Une valeur trop faible de m dans une configuration tendue dclenche trop
aisment la suspension des processus, une valeur trop leve de m dans une configuration
rduite ne confre pas au systme de contrle une sensibilit suffisante. La valeur 2
(par dfaut) est le meilleur compromis pour une configuration rduite mais risque dtre trop
faible pour une configuration plus tendue, pouvant et devant prendre en charge des
dizaines de processus pour exploiter les ressources disponibles.
Par exemple, si une configuration et une charge donnes peuvent grer lexcution
simultane denviron 25 processus, mais quau-del, il y a risque demballement, il est
conseill de fixer 25 la valeur de m.
Paramtre e
Chaque fois quun processus interrompu est ractiv, il est exempt de toute interruption
pendant une priode de e secondes. Ce laps de temps est mnag pour assurer que le
cot lev (en E/S disque) que reprsente le chargement des pages dun processus
interrompu est compens par une progression raisonnable des processus. La valeur par
dfaut de e est 2 secondes.
Une fois par seconde, le programmateur (processus 0) examine toutes les grandeurs cites
ci-dessus, collectes pendant lintervalle dune seconde prcdent. Cet examen lui permet
de dterminer si les processus doivent tre suspendus ou activs. Tous les processus
dsigns aptes tre suspendus par les paramtres p et e sont marqus comme tels.
2-10
Lorsquun de ces processus reoit la CPU en mode utilisateur, il est interrompu (sauf si la
suspension rduit moins de m le nombre de processus actifs). Le critre de mode
utilisateur est appliqu pour empcher quun processus soit interrompu alors que des
oprations systme critiques sont excutes sur son compte. Si les conditions
demballement perdurent au cours des intervalles dune seconde suivants, les autres
processus rpondant aux critres de p et e sont marqus pour tre interrompus. Lorsque le
programmateur dtermine que les conditions dintervalle de scurit sont remplies, chaque
seconde, un certain nombre de processus interrompus sont remis dans la file dexcution
(ractivs).
Les processus interrompus sont ractivs : (1) par ordre de priorit, (2) par ordre
dinterruption. Ils ne sont pas tous activs en mme temps. Leur nombre est calcul selon
une formule qui tablit le nombre de processus actifs ce moment-l et en ractive 1/5me
ou augmente selon une progression rgulire croissante le nombre minimum (cest loption
la plus leve qui est choisie). Par cette stratgie prudente, laccroissement du degr de
multiprogrammation est ralis par tranche denviron 20 % par seconde. Ainsi, la
ractivation seffectue un rythme relativement lent pendant la premire seconde qui suit la
priode de scurit, puis un rythme plus soutenu au cours des secondes suivantes. Si la
surcharge mmoire se reproduit pendant la ractivation, lopration sinterrompt et les
processus marqus pour la ractivation sont de nouveau marqus comme tant
interrompus. Les autres processus sont interrompus conformment aux rgles prcdentes.
Les six paramtres de lutilitaire de contrle de charge mmoire peuvent tre dfinis par
ladministrateur systme via la commande schedtune. Les techniques doptimisation de
lutilitaire sont dcrites au chapitre 7 : Contrle et optimisation de la mmoire.
Affectation et rclamation demplacements dans lespace de pagination

AIX prend en charge deux schmas daffectation des emplacements dans lespace de
pagination. Avec lalgorithme normal, de post-affectation, un emplacement de pagination
nest affect une page de mmoire virtuelle que lorsque cette page a t lue ou quune
criture y a t effectue. Cest la premire fois que le contenu de la page a un rle pour le
programme en cours.
Un grand nombre de programmes exploite ce type daffectation en attribuant des intervalles
dadresses de mmoire virtuelle aux plus grandes structures, celles-ci tant par la suite
utilises en fonction des besoins. Les pages des intervalles dadresses de mmoire virtuelle
qui ne sont jamais sollicites ne requirent ni trames de mmoire relle ni emplacements
dans lespace de pagination.
Cette technique nest cependant pas sans risque. Si tous les programmes excuts sur une
machine se trouvent simultanment dans une situation de taille maximale, lespace de
pagination peut tre satur. Certains programmes riquent de ne pas tre mens terme.
Le second schma utilis par AIX a t spcialement conu pour ce type de situation ou
pour les installations sur lesquelles le non-aboutissement dun programme reprsente un
cot prohibitif. Cet algorithme dit daffectation anticipe permet daffecter le nombre
appropri demplacements dans lespace de pagination en mme temps que lintervalle
dadresse de mmoire virtuelle, par exemple laide de malloc. Si le nombre
demplacements est insuffisant pour le malloc, un code derreur est gnr. La ligne
dappel de cet algorithme est :
export PSALLOC=early
Ds lors, tous les programmes exec dans lenvironnement utiliseront lalgorithme
daffectation anticipe. Cette ligne na aucune incidence sur le shell courant.
Laffectation anticipe est particulirement intressante pour lanalyse des performances, du
fait de ses implications sur la taille de lespace de pagination. Nombreux sont les
programmes qui utilisent frquemment malloc pour une utilisation de lespace la carte.
Activer lalgorithme daffectation anticipe pour ces programmes entrane une multiplication
des besoins en espace de pagination. Sil est normalement conseill dutiliser un espace de
pagination de taille double de celle de la mmoire relle du systme, dans le cas de
2-11
systmes utilisant PSALLOC=early, la taille prconise doit tre au moins quadruple de

celle de la mmoire relle. Et ceci nest quune base de dpart. Il vous faut en fait analyser
les besoins en mmoire virtuelle de la charge de travail et affecter les espaces de
pagination correspondants. Par exemple, le serveur AIX windows peut requrir, avec
laffectation anticipe, 250 Mo despace de pagination.
Rappelons galement que ces emplacements ne sont librs qu la fin du processus (et
non des routines) ou par lappel systme disclaim. Ils ne peuvent pas tre librs via free.
Pour en savoir plus sur le contrle et laffectation de lespace de pagination, reportez-vous
Position et taille des espaces de pagination, page 4-26.
2-12
Gestion AIX du stockage sur disque fixe

La figure Organisation des donnes sur disque fixe (sans option miroir) illustre la
hirarchie des structures utilises par AIX pour grer le stockage sur disque fixe. Chaque
unit de disque, appele volume physique (PV), porte un nom du type /dev/hdisk0. Si le
volume est en cours dutilisation, il appartient un groupe de volumes (VG). Tous les
volumes physiques membres dun groupe de volumes sont diviss en partitions physiques
(PP) de mme taille (par dfaut, 2 Mo pour des groupes comportant des volumes physiques
infrieurs 300 Mo et 4 Mo dans les autres cas). Pour faciliter laffectation despace,
chaque volume physique est divis en cinq rgions (outer_edge, outer_middle, center,
inner_middle et inner_edge). Le nombre de partitions physiques implantes dans chaque
rgion varie en fonction de la capacit totale de lunit de disque.
...
...
/op/nomfichier
Fichier
/op
... p
...
hd11
...
om m im
FS
hd2 LV
LP
PP
o
om m im
om m im
PV
/dev/hdisk0
/dev/hdisk2
/dev/hdisk1
autre VG
VG
root vg
Organisation des donnes sur disque fixe (sans option miroir)

Dans chaque groupe de volumes sont dfinis un ou plusieurs volumes logiques (LV).
Chaque volume logique est constitu dune ou de plusieurs partitions logiques. Chaque
partition logique correspond au moins une partition physique. Si le volume logique est mis
en miroir, des partitions physiques supplmentaires sont affectes pour stocker les copies
supplmentaires de chaque partition logique. Les partitions logiques sont numrotes
squentiellement, mais les partitions physiques sous-jacentes ne sont pas ncessairement
conscutives ou contigus.
2-13
Les volumes logiques peuvent assurer certaines fonctions systme, telle la pagination. Sils
renferment des donnes systme ou utilisateur ou des programmes, ils disposent chacun
dun systme de fichiers journaliss (JFS) unique. Ce dernier est compos dun pool de
blocs de la taille dune page (4 096 octets). Lorsque des donnes sont inscrites dans un
fichier, un ou plusieurs blocs lui sont affects. Les blocs peuvent tre contigus ou non (et
contigus ou non ceux dj affects au fichier).
Sous AIX version 4.1, un systme de fichiers donn peut tre dfini avec une taille de
fragment infrieure 4 096 octets. La taille de fragment est de 512, 1 024 ou 2 048 octets.
Ce qui permet de stocker plus efficacement les fichiers peu volumineux.
La figure Organisation des donnes sur disque fixe (sans option miroir) illustre ce qui peut
se produire lorsquun systme de fichiers na pas t rorganis depuis longtemps. Le
fichier /op/filename est rparti sur un grand nombre de blocs physiquement distants les uns
des autres : la lecture squentielle de ce fichier exige plusieurs oprations de recherche,
coteuses en temps.
Au niveau conceptuel, un fichier AIX est une chane contigu et squentielle doctets, mais
la ralit physique est parfois bien diffrente : le fichier peut avoir t fragment la suite
de multiples extensions des volumes logiques ou doprations daffectation/ libration/
raffectation au sein du systme de fichiers. Un systme de fichiers est dit fragment
lorsque son espace disponible est compos de multiples parcelles qui rendent impossible
lcriture dun nouveau fichier sur des blocs contigus.
Laccs aux fichiers implants sur un systme de fichiers trs fragment exige de multiples
oprations de recherche et induit des temps de rponse en E/S bien suprieurs, du fait des
dlais de recherche. Par exemple, laccs squentiel demande plus doprations de
recherche si le fichier est dispers sur des parcelles physiquement loignes que sil est
concentr sur une ou quelques parcelles contigus. Il en va de mme pour laccs alatoire
un fichier.
Limpact de la dispersion dun fichier sur les performances dE/S est moindre si le fichier est
en mmoire tampon. Lorsquun fichier est ouvert sous AIX, il est mapp un segment de
donne persistant en mmoire virtuelle. Ce segment joue le rle de tampon virtuel, les blocs
du fichier renvoient directement aux pages du segment. VMM gre les pages de segment
en lisant la demande les blocs du fichier qui y sont contenus (au fur et mesure de leur
ouverture). Il arrive que VMM rcrive une page sur le bloc correspondant du fichier sur
disque ; mais, en gnral, il conserve en mmoire les pages rcemment appeles. Ces
pages restent donc plus longtemps en mmoire et laccs des fichiers logiques aux blocs
correspondants seffectue sans passer par le disque physique.
A un certain stade, lutilisateur ou ladministrateur systme peut dcider de rorganiser la
position des fichiers dans les volumes logiques et la position des volumes logiques dans les
volumes physiques, de faon rduire la fragmentation et rpartir plus uniformment la
charge totale des E/S. Pour en savoir plus sur la dtection et la correction des problmes
lis la rpartition sur disque et la fragmentation, reportezvous Contrle et
optimisation des E/S disque, page 8-1.
Lecture squentielle anticipe

Le gestionnaire VMM tente danticiper les besoins en pages dun fichier squentiel en
observant le mcanisme daccs des programmes ce fichier. Si le programme accde
deux pages successives, VMM en dduit que laccs au fichier est squentiel et anticipe les
lectures suivantes. Ces lectures seffectuent paralllement lexcution du programme, de
sorte que celui-ci dispose des donnes plus rapidement, VMM nayant pas attendre quil
accde la page suivante pour lancer une opration dE/S. Le nombre de pages lues par
anticipation dpend de deux seuils VMM :
2-14
minpgahead
Nombre de pages lues par anticipation ds que VMM suppose que

laccs est squentiel. Si le programme continue daccder au fichier
squentiellement, la lecture suivante portera sur le double de pages
dfini minpgahead, puis la suivante sur quatre fois le nombre de
pages dfini minpgahead, etc., jusqu atteindre le nombre de pages
dfini maxpgahead.
maxpgahead
Nombre maximum de pages du fichier squentiel que VMM lit par

anticipation.
Si le programme scarte du mcanisme daccs squentiel et accde une page du fichier

dans un autre ordre, la lecture anticipe sinterrompt. Elle reprend, avec le nombre de
pages dfini minpgahead, si VMM constate que le programme revient un accs
squentiel. Les valeurs de minpgahead et maxpgahead sont dfinies via la commande
vmtune. Pour en savoir plus, reportez-vous Optimisation des lectures squentielles
anticipes, page 8-11.
Ecriture diffre
Pour accrotre les performances dcriture, limiter le nombre en mmoire de pages de
fichier modifies, rduire la charge du systme et minimiser la fragmentation du disque, le
systme de fichiers divise chaque fichier en partitions de 16 ko. Les pages dune partition
donne ne sont inscrites sur le disque que lorsque le programme a crit le premier octet de
la partition suivante. Ce nest qu ce stade que le systme de fichiers force lcriture des
quatre pages modifies de la premire partition sur le disque. Les pages de donnes
restent en mmoire jusqu ce que leur trame soit rutilise, stade partir duquel aucune
autre opration dE/S nest requise. Si un programme accde lune des pages avant que
les trames ne soient rutilises, aucune E/S nest ncessaire.
Sil reste beaucoup de page modifies non rutilises en mmoire, le dmon sync les crit
sur le disque, ce qui peut entraner une utilisation anormale du disque. Pour rpartir plus
efficacement les activits dE/S par rapport la charge de travail, vous pouvez activer
lcriture diffre alatoire pour indiquer au systme le nombre de pages conserver en
mmoire avant de les crire sur disque. Le seuil dcriture diffre alatoire est dfini sur la
base des fichiers. Cette action entrane lcriture des pages sur disque avant lexcution du
dmon sync ; les E/S sont ainsi rparties plus uniformment.
Vous pouvez modifier la taille des partitions dcriture diffres et le seuil dcriture diffre
alatoire via la commande vmtune.
Fichiers mapps et criture diffre

Les fichiers AIX normaux sont automatiquement mapps des segments. Ainsi, laccs
normal un fichier ne ncessite plus de transiter par les tampons du noyau et les routines
dE/S de bloc, ce qui permet aux fichiers dutiliser davantage de mmoire lorsquun
supplment de mmoire est disponible (la mise en mmoire cache des fichiers nest pas
limite la zone tampon dclare du noyau).
Les fichiers peuvent tre mapps explicitement par la commande shmat ou mmap, mais
cette opration ne fournit pas despace mmoire supplmentaire pour la mise en mmoire
cache. Les applications qui utilisent shmat ou mmap et accdent au fichier mapp par une
adresse au lieu de recourir read et write vitent les longueurs de parcours inhrentes aux
oprations dappel systme, mais perdent le bnfice de la fonction dcriture diffre.
Lorsque les applications nutilisent pas la sous-routine write, les pages modifies ont
tendance saccumuler en mmoire et sont crites de faon alatoire quand lalgorithme de
repositionnement de page VMM ou le dmon sync les purge. Dans ces conditions, lcriture
sur disque se fait par petits bouts, au dtriment de toute efficacit dexploitation du disque et
de la CPU, et la fragmentation qui en dcoule risque de ralentir les lectures ultrieures du
fichier.
2-15
Rgulation des E/S

Les utilisateurs des versions AIX antrieures la version 3.2 subissaient parfois des temps
de rponse trs longs sur des applications interactives, lorsquune autre application
excutait une importante opration dcriture sur le disque. La plupart des critures tant
asynchrones, il peut se crer des files dattente dE/S FIFO de plusieurs mgaoctets, dont
lexcution demande plusieurs secondes. Si chaque lecture sur disque monopolise
plusieurs secondes pour parcourir les files dattente, les performances dun processus
interactif sont srieusement amoindries. Pour rsoudre ce problme, VMM propose une
option de contrle des critures appele rgulation des E/S.
La rgulation des E/S ne modifie ni linterface ni la logique de traitement des E/S. Elle se
borne limiter le nombre des E/S en attente sur un fichier. Lorsquun processus tente de
dpasser cette limite, il est interrompu jusqu ce quun nombre sufffisant de requtes en
attente ait t trait pour atteindre le seuil minimal. Pour en savoir plus, reportez-vous
Rgulation des E/S disque, page 8-13.
Pile de disques
Une pile de disques est un ensemble de disques grs comme un tout. Plusieurs
algorithmes de gestion engendrent divers degrs de performances et/ou dintgrit des
donnes. Ces algorithmes de gestion sont identifis par diffrents niveaux RAID.
(RAID signifie redundant array of independent disks.) Les niveaux RAID sous les
versions 3.2.5 et 4 dfinis dans larchitecture sont les suivants :
RAID0
Les donnes sont inscrites sur des units physiques conscutives, avec un
nombre fixe de blocs de 512 octets par criture. Cette technique est comparable
la technique de rpartition en bandes des donnes sur disque : elle offre les
mmes caractristiques au niveau de lintgrit des donnes que des units de
disque indpendantes classiques. Autrement dit, lintegrit des donnes dpend
entirement de la frquence et de la validit des sauvegardes. Ce niveau est
analogue la fonction de rpartition en bande dcrite Performances et
rpartition des volumes logiques, page 8-15.
RAID1
Les donnes sont rparties en bandes sur les units, comme pour le niveau
RAID0, mais la moiti des units sont utilises comme units miroir. RAID1
rpond certains problmes dintgrit et de disponibilit pouvant survenir
avec RAID0 en cas de dfaillance dune unit unique, mais noffre pas plus de
solutions que RAID0 en cas de dfaillance dune ou plusieurs units. Des
sauvegardes consciencieuses sont indispensables. Ce niveau est analogue
la fonction miroir des volumes logiques propose par le gestionnaire de
volumes logiques.
RAID3
Les donnes sont rparties en bandes octet par octet sur un ensemble dunits
de donnes, une unit de parit distincte contenant un octet de parit pour
chaque position doctet dans les units de donnes. En cas de dfaillance
dune unit unique, son contenu est reconstitu sur la base de loctet de parit
et des octets de donnes restants. Dans cette technique, lunit de parit
devient un goulot dtranglement en terme de performances : une criture doit
y tre effectue chaque criture sur un des autres disques.
RAID5
Les donnes sont rparties bloc par bloc (de 512 octets), mais des portions dun
certain nombre dunits (pas forcment toutes) sont rserves aux informations
de parit. Ce qui alourdit encore lcriture des informations de parit.
Les units RAID doivent tre considres comme une solution en terme dintgrit et de
disponibilit, mais non de performances. Les configurations RAID tendues sont
gnralement limites par le fait que chaque RAID est raccord une carte SCSI unique.
Du point de vue des performances, la prise en charge dun nombre donn dunits de
disque est plus efficace avec des units RAID raccordes plusieurs cartes SCSI quavec
une seule unit RAID de grande taille.
2-16
Chapitre 3. Introduction au multitraitement
Rpartir la charge pour allger le travail, tel est le postulat qui a conduit au dveloppement
des systmes multiprocesseur. A un moment donn, la vitesse de traitement dun
processeur se heurte une limite technologique. Si un seul processeur ne parvient pas
grer correctement la charge du systme, une solution possible est de multiplier les
processeurs.
Le succs de cette solution dpend bien entendu de lingniosit de ses concepteurs, et
encore faut-il que la charge de travail sy prte : sil est vident que multiplier les employs
rpondant un numro vert accrot lefficacit du service, multiplier les conducteurs dune
automobile ne prsente aucun intrt.
Pour que la migration dun systme monoprocesseur en systme multiprocesseur se
traduise par lamlioration de ses performances, les conditions suivantes doivent tre
runies :
La charge de travail est limite par la vitesse de traitement et sature lunique processeur
du systme.
La charge de travail contient plusieurs lments gourmands en temps processeur
(transactions, calculs complexes, etc.) qui peuvent tre traits simultanment et de
manire indpendante.
Le processeur existant ne peut pas tre mis niveau et aucun processeur seul noffre la
vitesse de traitement ncessaire.
Plusieurs lments (base de donnes centralise, etc.) incitent rpartir la charge de
travail entre plusieurs systmes monoprocesseur.
Dune manire gnrale, il est prfrable dopter pour une solution mettant en oeuvre un
seul processeur lorsque cela est possible car lassociation de plusieurs processeurs pose
des problmes de performances, ngligeables, voire inexistants, dans les systmes
monoprocesseur. En particulier, si la condition 2 nest pas remplie, les performances dun
systme multiprocesseur peuvent tre moindres que celles dun systme monoprocesseur.
Bien que les applications unifilaires inchanges fonctionnent en gnral correctement dans
un environnement multiprocesseur, leurs performances sen trouvent souvent modifies de
manire imprvue. La mise en place dun systme multiprocesseur peut amliorer le dbit
dun systme et parfois raccourcir le temps dexcution dapplications multifiles complexes,
mais il rduit rarement le temps de rponse de chaque commande unifilaire.
Pour optimiser les performances dun systme multiprocesseur, il convient de connatre la
dynamique du systme dexploitation et du fonctionnement du matriel, spcifique des
environnements multiprocesseurs.
Introduction au multitraitement
3-1
Multitraitement symtrique (SMP) concepts et architecture

Comme toute modification qui accrot la complexit dun systme, lutilisation de plusieurs
processeurs ncessite de modifier la conception pour assurer un fonctionnement et des
performances satisfaisants. Du fait de sa plus grande complexit, le systme
multiprocesseur ncessite davantage dchanges matriel/logiciel et davantage de
coordination dans la conception matrielle et logicielle quun systme processeur unique.
Les diverses combinaisons de conception et dchanges augmentent dautant le nombre
darchitectures possibles.
Ce chapitre dcrit les principaux problmes poss par les systmes multiprocesseurs et les
solutions proposes par le systme AIX et le ESCALA.
Lors de la conception dun systme multiprocesseur, la dcision la plus importante est sans
doute le choix entre un systme symtrique ou asymtrique.
Les aspects importants de la conception sont les suivants :
Multiprocesseurs symtriques et asymtriques
Srialisation des donnes
Granularit du verrouillage
Charge lie au verrouillage
Cohrence des mmoires cache
Affinit avec un processeur
Conflits dutilisation de mmoire et de bus
Multiprocesseurs symtriques et asymtriques

Dans un systme multiprocesseur asymtrique, chaque processeur joue un rle particulier :
gestion des entres-sorties, excution de programmes, etc. Ce type de systme prsente
des avantages et des inconvnients :
Laffectation de tches particulires un seul processeur permet de limiter, voire de
supprimer, les incidents lis la srialisation des donnes et la cohrence des
mmoires cache (voir plus loin). Elle permet galement certains lments logiciels de
fonctionner comme dans un systme monoprocesseur.
Dans certains cas, le traitement des oprations dentres-sorties et des programmes est
acclr car il nest pas en concurrence avec dautres lments du systme
dexploitation ou de la charge de travail pour laccs au processeur.
Dans dautres cas, le traitement des oprations dentres-sorties et des programmes est
ralenti car les processeurs ne sont pas tous disponibles pour grer les pointes de charge.
Laffectation de tches particulires chaque processeur permet de limiter les
consquences dun incident une partie restreinte du systme.
Dans un systme multiprocesseur symtrique, tous les processeurs sont pratiquement
identiques et excutent des fonctions similaires :
Ils disposent tous despaces dadresses virtuelles et relles identiques.
Ils peuvent tous excuter toutes les routines du systme.
Ils peuvent tous grer une interruption externe. (Les interruptions internes sont gres
par le processeur qui excute le flot dinstructions qui les a gnres.)
Tous les processeurs peuvent lancer une opration dentre-sortie.
Du fait de cette interchangeabilit, nimporte quel processeur peut excuter nimporte quelle
fonction. Cest principalement aux concepteurs de matriel et de logiciels quil incombe de
3-2
garantir cette flexibilit. Un systme symtrique fait cependant apparatre les limites du
multitraitement dune charge de travail.
La famille ESCALA ne contient que des systmes multiprocesseur symtriques, dont la
figure Systme multiprocesseur symtrique donne un exemple. AIX version 4.1 ne prend
en charge que ce type de systme. Dautres types de systme peuvent prsenter une
configuration diffrente de leur mmoire cache.
Cache L1
Processeur 1 sur processeur
Cache L2 1
Cache L1
Cache L2 2
Cache L1
Cache L2 3
Cache L1
Cache L2 4
Mmoire
relle
Units
E/S
Systme multiprocesseur symtrique
Bien que les systmes multiprocesseur ESCALA soient techniquement symtriques, les
logiciels y introduisent un peu dasymtrie. Au dpart, pendant lamorage, un seul
processeur a le contrle. Le premier processeur dmarr est appel processeur matre.
Afin que les logiciels crits par lutilisateur continuent de fonctionner correctement lors de la
transformation de lenvironnement monoprocesseur en environnement multiprocesseur, les
pilotes dunit et les extensions de noyau qui ne sont pas explicitement conus pour un
systme multiprocesseur sont contraints de sexcuter uniquement sur le processeur
matre. Cette contrainte sappelle canalisation.
Srialisation des donnes

Tout lment de mmoire qui peut tre lu ou crit par plusieurs routines peut tre modifi
pendant lexcution du programme. Ce phnomne se produit gnralement dans les
environnements de multiprogrammation et les environnements multitraitement. Lapparition
de systmes multiprocesseur accrot la porte et limportance de ce phnomne :
La prise en charge de plusieurs processeurs et des routines incitent la cration
dapplications partageant les donnes entre plusieurs routines.
Le noyau ne peut plus rsoudre les incidents lis la srialisation des donnes en
dsactivant simplement les interruptions.
Pour viter une catastrophe, les programmes qui partagent des donnes doivent y accder
de manire squentielle et non plus en parallle. Avant daccder une donne partage,
chaque programme doit vrifier quaucun autre programme (y compris une copie de
lui-mme sexcutant au sein dune autre routine) ne modifie la donne.
Le principal mcanisme utilis pour viter les interfrences entre programmes est le
verrouillage. Un verrou est une abstraction qui reprsente lautorisation daccs un ou
plusieurs lments de donnes. Les demandes de verrouillage ou de dverrouillage sont
atomiques : elles seffectuent de telle sorte que ni les interruptions, ni laccs
multiprocesseur naffectent le rsultat. Pour accder une donne partage, un programme
doit obtenir son dverrouillage. Si un autre programme (ou une autre routine excutant le
mme programme) a dj obtenu ce dverrouillage et laccs la donne, le programme
demandeur doit attendre que laccs lui soit accord.
Outre les temps dattente daccs aux donnes, la srialisation accrot le nombre de
priodes pendant lesquelles une routine nest pas diffusable. Pendant ces priodes, les
3-3
autres routines sont susceptibles de modifier les lignes de la mmoire cache de cette
routine, ce qui augmente le dlai de latence de la mmoire lorsque la routine obtient
finalement le dverrouillage de la donne et redevient diffusable.
Le noyau AIX contient un grand nombre de donnes partages et doit donc procder la
srialisation des donnes en interne. Cela peut provoquer des retards de srialisation, y
compris dans les applications qui ne partagent pas de donnes avec dautres programmes,
car les fonctions du noyau utilises par lapplication doivent srialiser les donnes
partages du noyau.
Granularit du verrouillage
Un programmeur qui travaille dans un environnement multiprocesseur doit dcider du
nombre de verrous distincts crer pour les donnes partages. Si un seul verrou doit
srialiser lensemble des donnes partages, le risque de conflit daccs est relativement
lev. Si chaque donne dispose dun verrou, le risque de conflit est relativement faible.
Cependant, toute demande supplmentaire de verrouillage ou de dverrouillage utilise du
temps processeur et lexistence de plusieurs verrous peut provoquer un blocage. La figure
Blocage prsente le cas le plus simple de blocage : la routine 1 a obtenu le dverrouillage
de la donne A et attend le dverrouillage de la donne B et la routine 2 a obtenu le
dverrouillage de la donne B et attend le dverrouillage de la donne A. Aucun des deux
programmes ne peut obtenir le dverrouillage qui mettrait fin au blocage. Pour viter les
blocages, on tablit gnralement un protocole par lequel tous les programmes qui utilisent
un ensemble de verrous doivent toujours obtenir le dverrouillage dans le mme ordre.
Routine 1
Noyau
verrou A
verrou
accord
.
.
.
verrou B
dverr. A
verrou
accord
verrou
attente
verrou
attente
Routine 2
verrou B
.
.
.
verrou A
dverr. B
Blocage
Charge lie au verrouillage

Les demandes, dlais et librations de verrous augmentent la charge du systme :
Un programme qui prend en charge le multitraitement effectue en permanence les
mmes oprations de verrouillage et de dverrouillage, mme sil sexcute dans un
environnement monoprocesseur ou quil est le seul utiliser un verrou donn dans un
systme multiprocesseur.
Si une routine demande le dverrouillage dune donne dj obtenu par une autre
routine, il se peut que la routine demandeuse tourne un moment, soit mise en veille et, si
cest possible, quune autre routine soit diffuse. Cela consomme du temps systme.
La prsence de verrous trs utiliss fixe une limite maximale au dbit du systme. Par
exemple, si un programme donn consacre 20 % de son temps dexcution lutilisation
dun verrou exclusion mutuelle, 5 exemplaires au plus de ce programme peuvent
sexcuter simultanment, quel que soit le nombre de processeurs du systme.
En ralit, mme 5 exemplaires seulement dun programme ne seront jamais
suffisamment synchroniss pour viter les temps dattente (chelle de dbit dans un
systme multiprocesseur, page 3-8).
3-4
Cohrence des mmoires cache

Les concepteurs de systmes multiprocesseur veillent tout particulirement assurer la
cohrence des mmoires cache. Mais cette cohrence ne peut tre garantie quau
dtriment des performances. Pour comprendre pourquoi, il convient de connatre les
difficults rencontres :
Si chaque processeur possde une mmoire cache (voir figure Systme multiprocesseur
symtrique, page 3-3), qui indique ltat des diffrentes parties de la mmoire, il se peut
que plusieurs mmoires cache contiennent des copies dune mme ligne. Il se peut
galement quune ligne contienne plusieurs donnes dotes dun verrou. Si deux routines
apportent des modifications ces donnes dans lordre correct, deux versions diffrentes et
incorrectes de la ligne de mmoire risquent dtre enregistres dans les mmoires cache.
Le systme nest plus cohrent car il contient deux versions diffrentes du contenu dune
zone de mmoire spcifique.
Pour rtablir la cohrence des mmoires cache, on conserve gnralement une des lignes
et on invalide les autres. Bien que linvalidation soit effectue par le matriel, sans
intervention logicielle, tout processeur dont une ligne de mmoire cache a t invalide
indiquera une absence en mmoire cache, avec le dlai correspondant, la prochaine fois
quil recevra une demande concernant cette ligne.
Pour une tude dtaille de larchitecture dadressage et des oprations sur la mmoire
cache ESCALA, reportez-vous lannexe C, Mmoire cache et adressage.

Si une routine est interrompue, puis rediffuse sur le mme processeur, il se peut que la
mmoire cache de ce processeur contienne encore des lignes appartenant cette routine.
Si la routine est diffuse sur un autre processeur, elle rencontrera probablement une srie
dabsences en mmoire cache avant que la partie active de sa mmoire cache soit
rcupre de la RAM. Cependant, si une routine diffusable doit attendre que le processeur
sur lequel elle sexcutait auparavant soit de nouveau disponible, elle risque dattendre
encore plus longtemps.
Laffinit avec un processeur est la diffusion dune routine sur le processeur sur lequel elle
sexcutait auparavant. Le degr daffinit avec un processeur doit varier
proportionnellement la taille de la partie active de la mmoire cache et de manire
inversement proportionnelle au temps coul depuis la dernire diffusion.
Sous AIX version 4.1, laffinit avec un processeur peut tre effectue via une liaison entre
une routine et un processeur. Une routine lie un processeur ne peut sexcuter que sur
ce processeur, quel que soit ltat des autres processeurs du systme.
Conflits dutilisation de mmoire et de bus

Dans un systme monoprocesseur, les conflits dutilisation de ressources internes (blocs de
mmoire, bus de mmoire ou dentres-sorties, etc.) sont gnralement insignifiants en
terme de temps systme. Dans un systme multiprocesseur, ils peuvent prendre davantage
dimportance, notamment si les algorithmes de cohrence des mmoires cache augmentent
le nombre daccs la mmoire vive.
3-5
Performances des systmes SMS

Rpartition de la charge de travail
Le premier problme de performances spcifique des systmes SMS est la rpartition de la
charge de travail, cest--dire, lexploitation efficace des n processeurs disponibles. En effet,
si seul un processeur dun systme quadriprocesseur est actif un instant donn, le
systme nest pas plus performant quun systme monoprocesseur. Il risque mme de ltre
moins, du fait de lexistence du code destin viter les interfrences entre processeurs.
La rpartition de la charge de travail est le pendant de la srialisation des donnes. Si les
logiciels de base ou la charge de travail, ou leur interaction, requirent la srialisation des
donnes, la rpartition de la charge de travail en ptit.
Mieux vaut une rpartition de la charge de travail moins quilibre du fait dune plus grande
affinit avec un processeur. Celle-ci amliorant lefficacit de la mmoire cache, lexcution
du programme sen trouve acclre. La rpartition de la charge de travail est moindre
(sauf sil y a plus de routines diffusables disponibles), mais le temps de rponse est rduit.
La rpartition des processus, lesquels font partie de la charge de travail, est la proportion de
routines diffusables en permanence sur un processus multiroutines.
Dbit
Le dbit dun systme SMS dpend principalement des lments suivants :
Une rpartition constamment trs bonne de la charge de travail. Davantage de routines
diffusables que de processeurs certains instants ne compense pas linactivit des
processeurs dautres.
Le nombre de conflits daccs.
Le degr daffinit avec un processeur.
Temps de rponse
Le temps de rponse dun programme dans un systme SMS est fonction des lments
suivants :
Le niveau de rpartition des processus du programme. Si celui-ci a en permanence
plusieurs routines diffusables, son temps de rponse samliorera probablement dans un
environnement SMS. Sil est constitu dune seule routine, son temps de rponse sera
au mieux comparable celui dun systme monoprocesseur quivalent.
Le nombre de conflits daccs entre plusieurs instances dun programme ou entre
plusieurs programmes diffrents utilisant les mmes verrous.
Le degr daffinit avec un processeur. Si chaque diffusion dun programme a lieu vers
des processeurs diffrents qui ne disposent pas des lignes de mmoire cache du
programme, celui-ci risque de sexcuter plus lentement que dans un systme
monoprocesseur comparable.
3-6
Adaptation des programmes un environnement SMS

Les termes qui suivent permettent dindiquer dans quelle mesure un programme a t
modifi ou cr pour fonctionner dans un environnement SMS :
Adaptation
minimale au
SMS
Suppression dans un programme de toute action (accs non srialis

aux donnes partages, par exemple) susceptible de provoquer des
incidents dans un environnement SMS. Utilis seul, ce terme dsigne
gnralement un programme qui a subi les modifications minimales
pour fonctionner correctement dans un systme SMS.
Adaptation
correcte au
SMS
Suppression dans un programme de toute action susceptible de

provoquer des incidents lis son fonctionnement ou ses
performances dans un systme multiprocesseur symtrique. Un
programme qui a subi une adaptation correcte a gnralement subi
galement une adaptation minimale. Il a subi des modifications
supplmentaires pour rduire au minimum les goulets dtranglement
en formation.
Adaptation
totale au SMS
Ajout dans un programme de fonctions destines permettre son

fonctionnement correct dans un systme SMS. Un programme qui a
subi cette adaptation a gnralement subi aussi les deux autres
adaptations.
3-7
Charge de travail dun SMS

Lajout de processeurs supplmentaires affecte les performances principalement en fonction
des caractristiques de la charge de travail. Les sections suivantes dcrivent ces
caractristiques et leurs effets sur les performances.
Multitraitement de la charge de travail
chelle de dbit dans un systme multiprocesseur
Temps de rponse dun systme multiprocesseur
Multitraitement de la charge de travail

Les systmes dexploitation multiprogrammation comme AIX qui traitent dnormes
charges de travail sur des ordinateurs rapides tels que le ESCALA donnent limpression que
plusieurs oprations ont lieu simultanment. En ralit, nombre de charges de travail ne
contiennent jamais un grand nombre de routines diffusables, mme lorsquelles sont traites
sur un systme monoprocesseur, sur lequel la srialisation des donnes pose moins de
problmes. Si le nombre de routines diffusables nest pas en permanence au moins gal au
nombre de processeurs, un ou plusieurs dentre eux seront inactifs une partie du temps.
Le nombre de routines diffusables est :
Le nombre
moins le
moins le
moins le
moins le
total
nombre
nombre
nombre
nombre
de
de
de
de
de
routines
routines
routines
routines
routines
dans le systme,
qui attendent une entre-sortie,
qui attendent une ressource partage,
qui attendent les rsultats dune autre routine,
en veille leur demande.
Une charge de travail peut faire lobjet dun multitraitement si elle prsente en permanence
autant de routines diffusables quil y a de processeurs dans le systme. Notez quil ne sagit
pas du nombre moyen de routines diffusables. Si le nombre de routines diffusables est gal
zro la moiti du temps, et double de celui de processeurs le reste du temps, le nombre
moyen de routines diffusables est effectivement gal au nombre de processeurs, mais tous
les processeurs ne sont actifs que la moiti du temps.
Augmenter le multitraitement de la charge de travail implique :
lidentification et la suppression des goulets dtranglement qui obligent les routines
attendre
laugmentation du nombre total de routines dans le systme.
Ces deux solutions ne sont pas indpendantes. Si un grand goulet dtranglement se forme
sur le systme, laugmentation du nombre de routines de la charge de travail existante qui
passent dans le goulet dtranglement va accrotre la proportion de routines en attente. Sil
ny a pas de goulet dtranglement, laugmentation du nombre de routines peut en crer un.
chelle de dbit dans un systme multiprocesseur

Tous ces facteurs contribuent ce que lon appelle lchelle dune charge de travail. Cette
chelle est le degr dont bnficie le dbit de la charge de travail du fait de la disponibilit
de processeurs supplmentaires. Elle est gnralement exprime comme le quotient de la
charge de travail dans un systme multiprocesseur par le dbit dans un systme
monoprocesseur comparable. Par exemple, si un systme monoprocesseur traite
20 demandes par seconde et quun systme quadriprocesseur traite 58 demandes par
seconde, pour une charge de travail donne, lchelle est 2,9. Cette charge de travail a
donc une chelle de dbit leve. Il sagit par exemple dune charge de travail constitue
exclusivement de programmes longs intgrant de nombreux calculs complexes, comportant
peu doprations dentre-sortie ou dautre activit du noyau, et nutilisant pas de donnes
partages. Dans la ralit, la plupart des charges de travail ne correspondent pas ce
modle. Lchelle de dbit est trs difficile mesurer. Lorsque cest possible, il convient de
fonder les estimations sur des mesures de charges de travail relles.
3-8
La figure chelle dans un systme multiprocesseur illustre les difficults de cette

opration. La charge de travail est constitue dune srie de commandes. Chaque
commande comporte un tiers de traitement normal, un tiers dattente dentre-sortie et un
tiers de traitement avec un verrou ferm. Dans le systme monoprocesseur, une seule
commande peut tre traite la fois, que le verrou soit ouvert ou ferm. Dans lintervalle de
temps indiqu sur la figure (gal cinq fois le temps dexcution de la commande), le
systme monoprocesseur traite 7,67 commandes.

Monoprocesseur
Multiprocesseur
2 voies
Traitement

Attente E/S
(ou verrou sur SM)
Verrou ferm
Mise lchelle dans un systme multiprocesseur
Dans le systme multiprocesseur, deux processeurs se partagent lexcution des

programmes, mais il ny a quun seul verrou. Par souci de simplicit, les conflits daccs
naffectent que le processeur B. Au cours de la priode indique, le systme
multiprocesseur traite 14 commandes. Le facteur dchelle est ainsi de 1,83. On obtient le
mme rsultat avec un systme comprenant un nombre suprieur de processeurs, cest
pourquoi nous avons opt pour un systme deux processeurs. Le verrou est utilis en
permanence. Dans un systme quadriprocesseur, lchelle serait de 1,83 ou moins.
Dans la ralit, les programmes sont rarement aussi symtriques que les commandes de
notre exemple. Rappelons galement que nous navons pris en compte quun seul type de
conflit : les conflits daccs. Si nous avions tenu compte de la cohrence des mmoires
cache et de laffinit avec un processeur, lchelle serait certainement encore infrieure.
Cet exemple dmontre, sil en tait besoin, quil ne suffit pas dajouter des processeurs pour
augmenter la vitesse de traitement dune charge de travail. Il est galement indispensable
didentifier et de minimiser les sources de conflits au sein des routines.
Selon certaines tudes, lobtention dchelles leves ne pose de difficults. Cependant,
ces tudes se fondent sur des programmes courts et gourmands en temps processeur qui
nutilisent quasiment pas de fonctions noyau. Les rsultats obtenus reprsentent en fait une
limite suprieure de lchelle, non la ralit.
3-9
Temps de rponse dun systme multiprocesseur

Un systme multiprocesseur ne peut amliorer le temps de traitement dun programme que
dans la mesure o celui-ci peut tre excut en plusieurs routines. Plusieurs moyens
permettent dexcuter en parallle diffrentes parties dun programme :
Appels explicites de sous-routines libpthreads (ou de fork() dans les programmes plus
anciens) pour crer plusieurs routines excutables simultanment.
Traitement du programme laide dun compilateur ou dun prprocesseur de
paralllisation qui dtecte les squences de code excutables simultanment et gnre
les routines requises pour lexcution en parallle.
Utilisation dun module logiciel multiroutines.
Sans recours une ou plusieurs de ces techniques, la dure dexcution dun programme
dans un systme multiprocesseur est la mme que dans un systme monoprocesseur
comparable. En fait, elle peut mme tre suprieure du fait de la mobilisation du temps
systme par les oprations lies aux verrous et des retards lis la rpartition du
programme entre plusieurs processeurs des instants diffrents.
Mme si les trois techniques sont exploites, la rduction du temps de traitement est limite
par une rgle dite Loi dAmdahl :
Si une fraction x du temps de traitement t dun programme dans un systme
monoprocesseur ne peut tre traite que de manire squentielle, la rduction du temps
dexcution dans un systme n processeurs par rapport au temps dexcution dans un
systme monoprocesseur comparable (augmentation de la vitesse) est donne par
lquation :
Aug. vit
temps syst. monopr

tps sq + tps multipr
lim aug. vit

n!1
t
xt + (x1)t
n
1
x+x
n
1
x
Par exemple, si un programme doit tre excut pour 50 % squentiellement et pour 50 %

en parallle, le facteur maximal damlioration du temps de rponse est infrieur 2
(dans un systme quadriprocesseur libre, ce facteur nexcde pas 1,6).
3-10
Programmation dans un systme SMS

La prise en charge des routines, nouveaut dAIX version 4.1, divise lexcution des
programmes en deux lments :
Un processus est lensemble des ressources physiques ncessaires lexcution du
programme. Exemple : mmoire, accs aux fichiers, etc.
Une routine est ltat dexcution dune instance de programme (contenu actuel du
registre dadresses dinstructions et des registres gnraux). Une routine sexcute
toujours dans le cadre dun processus et en exploite les ressources. Plusieurs routines
peuvent sexcuter au sein dun mme processus et partager ses ressources.
Dans les versions prcdentes dAIX, le programmateur de lunit centrale diffusait les
processus. Dans la version 4.1, il diffuse les routines.
Dans un environnement SMS, la prise en charge des routines facilite la mise en oeuvre
moindre cot dapplications ayant subi une adaptation totale SMS. Le traitement parallle
de plusieurs processus pour crer diffrents ordres dexcution est fastidieux et onreux car
chaque processus possde ses propres ressources mmoire et requiert normment de
traitement systme pour sa mise en place. La cration de plusieurs routines dans un seul
processus demande moins de traitement et occupe moins de mmoire.
La prise en charge des routines existe deux niveaux :
libpthreads.a dans lenvironnement du programme et
au niveau du noyau.
Traitement programm de charges de travail migres

La nouvelle distinction entre processus et routine est transparente pour les programmes
existants. En fait, les charges de travail qui ont subi une migration directement partir de
versions prcdentes dAIX crent des processus comme auparavant. Chaque nouveau
processus est cr avec une seule routine (routine initiale) qui est en concurrence avec les
routines des autres processus pour laccs aux ressources CPU. Les attributs par dfaut de
la routine initiale, associs aux nouveaux algorithmes de programmation, rduisent au
minimum les modifications de la dynamique du systme pour les charges de travail
inchanges.
Les priorits sont manipules laide des commandes nice et renice et des commandes
dappel systme setpri et setpriority , comme auparavant. Le programmateur permet
lexcution dune routine donne pendant une tranche de temps (10 ms gnralement) au
maximum avant de forcer le passage la prochaine routine diffusable de priorit gale ou
suprieure.
Variables de lalgorithme de programmation

Plusieurs variables affectent la programmation des routines. Certaines sont spcifiques de
la prise en charge des routines et les autres rsultent de considrations sur la
programmation des processus :
Priorit
Indicateur fondamental de son degr de priorit pour

laccs au processeur.
Position dans la file dattente La position dune routine dans la file dattente des routines
du programmateur
diffusables reflte un certain nombre de conditions de
priorit.
Politique de planification
Attribut qui dtermine le devenir dune routine en cours

dexcution lexpiration de la tranche de temps qui lui est
affecte.
3-11
Porte concurrentielle
Dtermine si la routine est en concurrence uniquement

avec les autres routines du processus ou avec lensemble
des routines du systme. Une routine pthread cre avec
une porte concurrentielle au niveau du processus est
planifie par la bibliothque alors que celles cres avec
une porte globale sont planifies par le noyau. Le
programmateur de la bibliothque utilise un pool de
routines du noyau pour planifier les routines pthreads avec
une porte concurrentielle. En rgle gnrale, les routines
pthreads doivent tre cres avec une porte
concurrentielle globale si elles traitent des E/S. La porte
concurrentielle est utile si les synchronisations
intraprocessus sont nombreuses. Il sagit dun concept
libpthreads.a.
Effet de laffinit avec un processeur sur les performances.
Lensemble de ces considrations peut sembler complexe, mais il existe essentiellement

trois dmarches de gestion dun processus donn :
Par dfaut
Le processus a une routine dont le degr de priorit varie

selon la consommation de lunit centrale et dont la
politique de programmation, SCHED_OTHER, est
semblable lalgorithme dAIX version 3.
Contrle au niveau du
processus
Le processus peut avoir une ou plusieurs routines, mais

leur politique de programmation est celle par dfaut
(SCHED_OTHER), ce qui permet lutilisation des
techniques dAIX version 3 pour contrler les valeurs nice
et les priorits fixes. Toutes ces techniques affectent
lensemble des routines du processus de la mme faon. Si
la commande setpri() est utilise, la politique de
programmation SCHED_RR est adopte pour toutes les
routines du processus.
Contrle au niveau des

routines
Une ou plusieurs routines peuvent tre associes au

processus. La politique de planification de ces routines est
dfinie, selon le cas, SCHED_RR ou SCHED_FIFO. La
priorit de chaque routine, fixe, est manipule laide de
sous-routines.
Planification des variables denvironnement

Au sein de la structure libpthreads.a, une srie de rglages permettent dinfluer sur les
performances de lapplication. Ces variables denvironnement sont les suivantes :
SPINLOOPTIME=n, o n est le nombre de tentatives effectues face un verrou
occup avant de passer un autre processeur. n doit tre une valeur positive.
YIELDLOOPTIME=n, o n est le nombre de tentatives de libration du processeur avant
le blocage sur un verrou occup. n doit tre une valeur positive. Le processeur est
allou une autre routine du noyau, sous rserve quil y en ait une excutable et dote
du niveau de priorit suffisant.
AIXTHREAD_SCOPE={P|S}, o P indique une porte concurrentielle locale et S une
porte concurrentielle globale. Vous devez indiquer P ou S. Les accolades ne sont
motives que par la syntaxe. Lutilisation de cette variable denvironnement affecte
uniquement les routines cres avec lattribut par dfaut. Lattribut par dfaut est
employ lorsque le paramtre attr de pthread_create a la valeur NULL.
Les variables denvironnement suivantes affectent la planification des routines pthreads
cres avec une porte concurrentielle locale.
3-12
AIXTHREAD_MNRATIO=p:k, o k est le nombre de routines du noyau qui doivent tre

employes pour grer p routines pthreads excutables. Cette variable denvironnement
dtermine le facteur dchelle de la bibliothque. Ce rapport est utilis pour crer et
terminer les routines pthreads.
AIXTHREAD_SLPRATIO=k:p, o k est le nombre de routines du noyau devant tre
rserves pour p routines pthreads en veille. En rgle gnrale, le nombre de routines du
noyau ncessaires pour la prise en charge des routines pthreads en veille est limit,
puisque ces routines sont en principe rveilles une une mesure du traitement des
verrous et/ou des vnements. Ceci permet dconomiser les ressources du noyau.
AIXTHREAD_MINKTHREADS=n, o n est le nombre minimum de routines du noyau
devant tre utilises. Le nombre de routines du noyau demandes par le planificateur de
la bibliothque ne descendra jamais en de de ce seuil. Il est possible de rclamer une
routine du noyau en nimporte quel point. En gnral, une routine du noyau est
demande en raison de la fin dune routine pthread.
3-13
Affinit avec un processeur et liaisons

Toutes choses gales par ailleurs, il est souhaitable de diffuser une routine sur le dernier
processeur sur lequel elle a t utilise. Ce critre de diffusion est appel affinit avec un
processeur. Le niveau daffinit avec un processeur peut varier.
Le degr daffinit le plus lev est la liaison entre une routine et un processeur. Dans ce
cas, la routine est diffuse uniquement sur ce processeur, mme si dautres processeurs
sont disponibles. La commande et sous-routine bindprocessor lient la ou les routine(s) du
processus spcifi un processeur particulier.
Cette technique peut tre utile pour les programmes gourmands en temps CPU qui
subissent peu dinterruptions. Cependant, elle peut entraver lexcution de programmes
ordinaires car elle risque de retarder la diffusion dune routine aprs une E/S jusqu
libration du processeur auquel elle est lie. Si la routine est bloque pendant toute la
dure dune E/S, il est peu probable que son contexte de traitement demeure dans les
mmoires cache du processeur auquel elle est lie. Il est prfrable de la diffuser sur le
prochain processeur disponible.
3-14
Chapitre 4. Planification, conception et implantation
Pour tre fonctionnel, un programme doit tre performant.

Chaque programme doit satisfaire un ensemble dutilisateurs, souvent htrogne. Si les
performances dun programme se rvlent inacceptables pour un groupe significatif de ces
utilisateurs, il ne sera pas utilis. Un programme non utilis ne remplit pas sa fonction
premire.
Le mme critre vaut pour les logiciels sous licence et les applications crites par les
utilisateurs. Cest pourquoi la plupart des dveloppeurs accordent une attention particulire
aux performances de leurs programmes. Malheureusement, ils ne peuvent prvoir
lenvironnement et les conditions dans lesquelles ils seront exploits. La responsabilit
finale des performances incombe ceux qui slectionnent (ou crivent), planifient et
installent les logiciels.
Ce chapitre dcrit les tapes doptimisation des performances dun programme (achet ou
dvelopp en interne). Le terme programmeur dsigne, dans ce chapitre, ladministrateur
systme ou toute personne responsable de lefficacit finale du programme.
Pour parvenir des performances acceptables, il faut en dfinir et en quantifier le niveau
ds le lancement du projet, et ne pas perdre de vue ces objectifs ni les moyens ncessaires
leur ralisation. Ces conseils semblent vidents, mais certains projets nen tiennent
dlibrment pas compte. Ils pratiquent la formule concevoir, coder, mettre au point,
ventuellement documenter et, si le temps le permet, optimiser les performances.
Le seul moyen de garantir lavance des programmes efficaces et non pas seulement
oprationnels, est dintgrer dans la planification et le processus de dveloppement des
critres de performances. En effet, il est souvent plus difficile de faire une planification fiable
sur des logiciels prexistants, linstallateur ne bnficiant pas de la mme marge de
manuvre que le dveloppeur.
Le processus propos peut sembler trs lourd pour un petit programme, mais il ne faut pas
oublier que lobjectif est double : le programme doit non seulement tre performant, mais
son intgration dans le systme ne doit pas nuire aux performances des programmes
installs.
Cette section traite des points suivants :
Identification des composants de la charge de travail
Dfinition des objectifs de performance
valuation des ressources requises par la charge de travail
valuation des ressources requises par le programme
valuation de la charge de travail partir de celle du programme
Autres points :
Conception et implantation de programmes performants
Conseils pour une installation performante
Planification, conception et implantation
4-1
Identification des composants de la charge de travail

Que le programme soit cr en interne ou achet tel quel, quil soit petit ou volumineux, le
dveloppeur, linstallateur et les utilisateurs potentiels doivent tre capables de rpondre
un certain nombre de questions :
Qui est appel utiliser le programme ?
Quelles seront les conditions dexploitation du programme ?
Selon quelle frquence et quel moment (heure, jour, mois, anne) le programme
sera-t-il utilis ?
Le programme devra-t-il cohabiter avec dautres programmes ?
Sur quel systme sera-t-il exploit ?
Quel est le volume et lorigine des donnes traiter ?
Les donnes cres par ou pour le programme seront-elles exploites par dautres
moyens ?
Faute dtre lucides lors de la conception du programme, ces questions risquent de
rester sans rponse prcise les valuations des programmeurs et des utilisateurs
potentiels ayant de fortes chances dtre divergentes. Mme dans le cas de figure
apparemment fort simple o le programmeur et lutilisateur sont une seule et mme
personne, il est ncessaire dtablir ces objectifs au pralable pour pouvoir confronter de
faon rigoureuse rsultats et objectifs. En outre, il est impossible destimer les
performances requises sans une analyse dtaille du travail effectuer.
Dfinition des objectifs

La dfinition et la quantification des objectifs de performances passent par la
comprhension des besoins : utilisateurs et programmeurs ne fonderont sans doute pas
leurs exigences sur les mmes critres. Dans tous les cas, il faut dfinir, au minimum :
Le temps de rponse maximum acceptable dans la plupart des cas pour chaque
interaction utilisateur-machine, avec une dfinition de ce quest la plupart des cas.
Rappelons que le temps de rponse est calcul partir du moment o lutilisateur donne
son feu vert pour lancer laction jusquau moment o il reoit de la machine
suffisamment dinformations pour poursuivre sa tche. Il sagit dun dlai dattente
subjectif, fonction de lutilisateur. Ce nest pas le dlai coul entre lentre dans la
sous-routine et la premire instruction dcriture.
Si un utilisateur prtend naccorder aucune importance au temps de rponse et ne
sintresser quau rsultat, demandez-lui si un temps dexcution en autonome dix fois
suprieur aux temps actuels est acceptable. Sil rpond oui, passez aux problmes de
dbit. Sinon, poursuivez avec lutilisateur la discussion sur les temps de rponse.
Le temps de rponse la limite de lacceptable le reste du temps. Autrement dit, le
temps de rponse au-del duquel lutilisateur commence penser que le systme est
hors service (ou du moins se plaint de la lenteur de la machine au point dtre rticent
lutiliser). Il vous faut galement prciser ce quest le reste du temps, la minute de
pointe de la journe, 1 % des interactions, etc. Ces termes sont galement soumis la
subjectivit de lutilisateur : par exemple, la dgradation du temps de rponse peut tre
plus coteuse et prjudiciable un certain moment de la journe.
Le dbit gnralement requis et les heures o il se produit. Encore une fois, ce critre ne
peut pas tre ignor. Par exemple : Supposons quun programme doit tre excut deux
fois par jour, 10 h 00 et 15 h 15. Sil est limit en CPU, requiert 15 minutes et est
appel fonctionner sur un systme multiutilisateur, son excution doit faire lobjet dune
ngociation pralable.
La dure et les heures des priodes de dbits maximaux.
La varit des requtes formules et son volution dans le temps.
4-2
Le nombre dutilisateurs par machine et le nombre total dutilisateurs dans le cas dune
application multiutilisateur. Cette description doit indiquer les heures de connexion de ces
utilisateurs, ainsi quune valuation du temps de saisie au clavier, dattente de lexcution
des requtes et des temps de rflexion. Vous pouvez tenter de savoir si les temps de
rflexion varient systmatiquement en fonction de la requte suivante ou prcdente.
Les hypothses de lutilisateur sur les machines prvues. Sil pense une machine en
particulier, il vous faut le savoir ds prsent. De mme, sil a des exigences en terme
de type, de taille, de cot, demplacement, dinterconnexion ou dautres variables
susceptibles de limiter votre marge de manuvre, vous devez intgrer ces exigences
vos objectifs. Lestimation des rsultats ne sera sans doute pas ralise sur le systme
o le programme a t dvelopp, test ou install initialement.
valuation des ressources requises par la charge de travail

A moins que vous nayez achet un logiciel avec une documentation complte sur les
ressources requises, cette tche est souvent la plus dlicate dans le processus de
planification des performances. Il y a plusieurs raisons cela :
AIX propose toujours plusieurs moyens deffectuer une tche : Vous pouvez crire un
programme C (ou autre HLL), un script shell, un script awk ou sed , un dialogue
AIXwindows, etc. Certaines techniques, qui apparaissent particulirement adaptes au
niveau de lalgorithme et de la productivit du programmeur, peuvent se rvler
extrmement coteuses en termes de performances.
Une des rgles dor est que plus le niveau dabstraction est lev, plus il faut, pour viter
toute surprise dsagrable, tre attentif au niveau des performances. Il convient
notamment dvaluer soigneusement les volumes de donnes et les itrations induites
par des constructions apparemment anodines.
Il est difficile de dfinir dans AIX le cot exact dun processus pris individuellement.
Le problme nest pas seulement dordre technique, il est aussi dordre philosophique :
si plusieurs instances dun programme excutes par plusieurs utilisateurs partagent les
pages dun texte de programme, quel processus doivent tre imputes ces pages de
mmoire ? Le systme dexploitation conserve en mmoire les pages de fichiers
rcemment utilises (simulant une mise en mmoire cache), les laissant disposition
des programmes qui les requirent. Lespace monopolis pour conserver ces donnes
doit-il tre imput aux programmes qui vont de nouveau accder ces donnes ?
La granularit de certaines mesures, telles que lhorloge systme, peut entraner des
variations du temps CPU attribu aux instances successives dun programme.
Il existe deux approches pour traiter le problme des variations et des ambiguts
relatives aux ressources. La premire consiste ignorer lambigut et liminer
progressivement les sources de variation jusqu ce que les mesures atteignent un
degr de cohrence acceptable. La seconde consiste tenter de raliser les mesures
les plus ralistes possibles et dcrire statistiquement le rsultat. Cette dernire
approche est prfrable car elle induit des rsultats en corrlation avec diverses
situations dexploitation.
Les systmes AIX sont rarement ddis lexcution dune seule instance dun
programme unique. Le plus souvent, dmons, activits de communication, charges de
travail de multiples utilisateurs cohabitent. Ces activits sont rarement cumulatives.
Par exemple, augmenter le nombre dinstances dun programme nentrane parfois le
chargement que de quelques pages de texte de programme, lessentiel du programme
tant dj en mmoire. Cependant, le processus supplmentaire peut gnrer une
concurrence plus importante au niveau des mmoires cache du processeur, si bien que
non seulement les autres processus sont contraints de partager le temps processeur
avec le nouveau venu, mais ils doivent tous subir davantage de cycles par instruction
(le processeur tant ralenti par un nombre suprieur dabsences en mmoire cache).
Il est recommand deffectuer une valuation la plus raliste possible :
4-3
Si le programme existe, effectuez vos mesures sur linstallation en place la plus

proche de vos objectifs.
Si aucune installation ne concide, mettez en place une installation-test et valuez la
charge globalement.
Sil est difficile de simuler une charge globale, mesurez chaque interaction et utilisez
les rsultats pour la simulation.
Si le programme nest pas encore cr, effectuez vos mesures sur un programme
comparable qui utilise le mme langage et prsente une structure gnrale analogue.
Rappelons que plus le langage est abstrait, plus la comparaison doit tre effectue
minutieusement.
Si aucun programme existant nest suffisamment proche, laborez un prototype des
principaux algorithmes dans le langage prvu, mesurez-le et modlisez la charge de
travail.
Si, et seulement si, toute mesure se rvle impossible, il vous faut travailler par
ttonnements. Si les besoins en ressources doivent tre valus lors de la
planification, le programme rel doit plus que jamais tre mesur ds que possible
pendant la phase de dveloppement.
Lestimation des ressources passe par la dfinition de quatre grandeurs principales
(lordre important peu) :
Temps CPU
Cot processeur de la charge de travail
Accs disque
Taux de lectures/critures gnres par la charge
Mmoire relle
Quantit de RAM requise par la charge de travail
Trafic rseau
(LAN)
Nombre de paquets gnrs par la charge et nombre doctets de

donnes changs
Les sections suivantes indiquent comment dterminer ces valeurs dans les divers cas de
figure exposs prcdemment.
Mesure des ressources requises

Si le programme rel, un programme analogue ou un prototype est disponible, le choix de la
mthode dpend des facteurs suivants :
Le systme traite-t-il dautres travaux que la charge de travail mesurer ?
Est-il possible dutiliser des outils susceptibles de nuire aux performances (le systme
est-il en service ou actif uniquement pour effectuer les mesures) ?
Jusqu quel point la charge relle peut-elle tre simule ou observe ?
Mesure de la charge totale sur un systme ddi
Ce cas de figure est idal car il permet dinclure le temps systme et le cot de chaque
processus.
Pour mesurer lactivit disque et CPU, lancez la commande iostat. La commande
$ iostat 5 >iostat.output
indique ltat du systme toutes les 5 secondes au cours des oprations de mesure. Le
premier rsultat fourni par iostat communique les donnes cumules depuis le dernier
amorage jusquau lancement de la commande iostat. Les rsultats suivants concernent
lintervalle prcdent (dans ce cas, les 5 dernires secondes). Voici un exemple de sortie de
iostat excute sur un grand systme :
4-4
tty:
tin
1.2
Disks:
hdisk1
hdisk2
hdisk3
hdisk4
hdisk11
hdisk5
hdisk6
hdisk7
hdisk8
hdisk9
hdisk0
hdisk10
tout
cpu:
1.6
% tm_act
Kbps
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
3.0
11.2
1.8
4.8
0.0
0.0
2.0
4.8
0.0
0.0
% user
% sys
% idle
60.2
10.8
23.4
tps
Kb_read
Kb_wrtn
0.0
0
0
0.0
0
0
0.0
0
0
0.0
0
0
0.0
0
0
0.0
0
0
0.0
0
0
0.8
8
48
1.2
0
24
0.0
0
0
1.2
24
0
0.0
0
0
% iowait
5.6
Pour mesurer la mmoire, utilisez svmon. La commande svmon G fait le point sur
lutilisation globale de la mmoire. Le rsultat statistique est exprim en pages de 4 ko :
$ svmon G
m e m o r y
size inuse free pin
24576 24366
210 2209
i n u s e
work pers clnt
15659 6863 1844
p i n
work pers
2209
0
p g s p a c e
clnt
size inuse
0
40960 26270
Dans cet exemple, les 96 Mo de mmoire de la machine sont entirement utiliss. 64 % de

mmoire RAM environ sont ddis aux segments de travail (lecture/criture des
programmes excuts). Sil existe des processus longs qui vous intressent, examinez en
dtail leurs besoins en mmoire. Lexemple suivant dtermine la mmoire utilise par lun
des processus de lutilisateur xxxxxx.
$ ps fu
USER
xxxxxx
xxxxxx
xxxxxx
xxxxxx
PID PPID
28031 51445
51445 54772
54772 6864
$ svmon P 51445
Pid
51445
C
STIME
15 14:01:56
1 07:57:47
0 07:57:47
TTY
pts/9
pts/9
TIME CMD
0:00
ps fu xxxxxx
0:00
ksh
0:02
rlogind
Command
ksh
Inuse
1668
Pin
2
Pgspace
4077
Pid: 51445
Command: ksh
Segid
8270
4809
9213
8a1
Type
pers
work
work
pers
Description
Inuse
/dev/fslv00:86079
1
shared library
1558
private
37
code,/dev/hd2:14400
72
Pin
0
0
2
0
Pgspace
0
4039
38
0
Address Range
0..0
0..4673 :60123..65535
0..31 : 65406..65535
0..91
Le cot de cette instance de ksh est imputable au segment de travail (9213) dont 37 pages
sont en cours dutilisation. Le cot des 1558 pages de la bibliothque partage et celui des
72 pages de lexcutable ksh est rparti respectivement sur lensemble des programmes et
des instances de ksh.
Si vous estimez que la taille du systme de 96 Mo est excessive, utilisez la commande
rmss pour rduire la taille effective de la machine et reprenez les mesures de la charge.
Si les oprations de pages augmentent sensiblement ou que le temps de rponse sallonge,
cela signifie que vous avez trop rduit la mmoire. Appliquez cette mthode jusqu ce que
vous trouviez la taille la plus approprie lexcution de la charge dans les meilleures
conditions. Pour en savoir plus sur cette mthode, reportez-vous Estimation de la
mmoire requise via rmss, page 7-6.
4-5
La principale commande pour mesurer lutilisation du rseau est netstat. Lexemple

ci-dessous illustre lactivit dune interface de rseau en anneau jeton :
$ netstat I tr0 5
input
(tr0)
output
packets errs packets errs colls
35552822 213488 30283693
0
0
300
0
426
0
0
272
2
190
0
0
231
0
192
0
0
143
0
113
0
0
408
1
176
0
0
input
(Total)
output
35608011 213488 30338882
0
0
300
0
426
0
0
272
2
190
0
0
231
0
192
0
0
143
0
113
0
0
408
1
176
0
0
La premire ligne indique le trafic cumul sur le rseau depuis le dernier amorage. Chaque
ligne qui suit fournit lactivit enregistre lors des 5 secondes prcdentes.
Mesure de la charge totale sur un systme actif
La mthode utiliser est analogue celle applique aux systmes ddis, mais vous
devez, dans ce cas, veiller prserver les performances du systme. Il faut savoir, par
exemple, que le cot dexcution de la commande svmon G est trs lev. Lannexe E,
Outils de performance, donne une estimation des cots, en termes de ressources, des
outils de performances les plus couramment utiliss.
Loutil le moins coteux est probablement vmstat, qui fournit des informations sur la
mmoire, les oprations dE/S et lutilisation du processeur, en un seul rapport. Si les
intervalles entre deux rapports vmstat restent raisonnablement longs (10 secondes), le cot
moyen dutilisation de cette commande est faible. Pour plus de dtails sur lutilisation de
vmstat, reportez-vous Identification des ressources limitatives, page 12-23.
Mesure dune charge partielle sur un systme actif
Une telle mesure est intressante lorsque vous souhaitez transfrer ou dupliquer une partie
de la charge pour lexcuter sur un autre systme. Le systme tant en service, votre
intervention doit laffecter le moins possible. Il vous faut analyser la charge en dtail pour
distinguer la partie qui vous intresse et dterminer les lments communs. Il peut sagir :
du programme ou de quelques programmes associs,
du travail effectu par certains utilisateurs du systme,
du travail provenant de certains terminaux.
Selon le critre choisi, utilisez lune des commandes :
ps ef | grep pgmname
ps fuusername, . . .
ps ftttyname, . . .
pour identifier les processus qui vous intressent et de faire le point sur leur consommation
en temps CPU. Pour valuer loccupation mmoire de ces processus, vous pouvez utiliser
la commande svmon (judicieusement !).
4-6
Mesure dun programme particulier

Plusieurs outils sont disponibles pour mesurer la consommation en ressources de
programmes particuliers. Certains offrent une mesure de la charge plus complte que
dautres, mais ils ont trop dincidence sur le systme pour tre appliqus un systme en
service. La plupart de ces outils sont dcrits dans les chapitres relatifs loptimisation de la
consommation de ressources spcifiques. Les principaux sont :
time
mesure le dlai dexcution coul et la consommation CPU dun

programme individuel. Reportez-vous Mesure de la CPU via time,
page 6-3.
tprof
mesure la consommation relative de CPU par les programmes, les

bibliothques de sous-routines et le noyau AIX. Reportez-vous
Analyse des programmes via tprof, page 6-10.
svmon
mesure la mmoire relle utilise par un processus. Reportez-vous

Quantit de mmoire utilise, page 7-2.
vmstat s
permet de mesurer la charge des E/S gnre par un programme.

Reportez-vous Mesure des E/S disque globales via vmstat,
page 8-7.
Estimation des ressources requises par un nouveau programme

Il est impossible dvaluer prcisment des programmes qui nont pas encore t crits :
les adaptations et nouveauts apportes un programme pendant la phase de codage sont
imprvisibles. Toutefois, quelques rgles de base peuvent vous aider faire une valuation
approximative. Au minimum, un programme requiert au dpart :
Temps CPU
environ 50 millisecondes, en gnral de temps systme,
Mmoire relle
une page par texte de programme,
une quinzaine de pages (dont 2 fixes) pour le segment (de donnes) de travail,
un accs libc.a (gnralement partag entre tous les programmes et englob dans
le cot de base du systme dexploitation),
E/S disque
environ 12 oprations de chargement de pages si le programme na pas t compil,
copi ou rcemment utilis, sinon 0.
Ajoutez les cots reprsents par les demandes lies la conception (les temps CPU
indiqus concernent le modle 660) :
Temps CPU
La consommation CPU dun programme ordinaire, contenant peu de niveaux
ditrations ou dappels de sous-routines coteuses, est ngligeable et
quasi-impossible mesurer.
Si le programme fait appel des algorithmes de calcul lourds, chaque algorithme doit
tre mesur partir dun prototype.
Si le programme fait appel des sous-routines de bibliothques coteuses en calculs
(lments de X ou de Motif ou printf, par exemple), mesurez la consommation CPU
en vous basant sur dautres programmes ordinaires.
4-7
Mmoire relle
Comptez (trs approximativement) 350 lignes de code par page de texte programme.
Cest--dire environ 12 octets par ligne. Noubliez pas que le style de code et les
options du compilateur peuvent multiplier ou diviser le rsultat par deux.
Cette variation concerne les pages impliques dans le scnario type.
Si, occasionnellement, des sous-routines excutes sont insres la fin de
lexcutable, les pages concernes ne sollicitent gnralement pas la mmoire relle.
Les rfrences des bibliothques partages autres que libc.a naugmentent la
consommation mmoire que dans la mesure o ces bibliothques ne sont pas
partages par dautres programmes ou instances du programme considr. Pour
mesurer la taille des bibliothques, crivez un programme simple, dexcution longue
qui y fait rfrence, et appliquez svmon P au processus.
valuez la capacit de stockage requise par les structures de donnes identifies
dans le programme. Arrondissez le rsultat la page la plus proche.
Dans une excution courte, chaque opration dE/S disque utilisera une page de
mmoire. Supposons que la page doit dj tre disponible. Ne supposez pas que le
programme va attendre la libration dune autre page du programme.
E/S disque
Pour les E/S squentielles, chaque lot de 4 096 octets lus ou crits gnre une
opration dE/S, sauf si certaines pages du fichier sont encore en mmoire du fait
dune utilisation rcente.
Pour les E/S alatoires, chaque accs, mme limit, une page diffrente de
4 096 octets gnre une opration dE/S, sauf si certaines pages du fichier sont
encore en mmoire du fait dune utilisation rcente.
Dans des conditions de laboratoire, chaque lecture ou criture squentielle dune page
de 4 ko dans un fichier volumineux mobilise environ 140+/20 microsecondes de
temps CPU. Chaque lecture ou criture alatoire dune page de 4 ko mobilise environ
350+/40 microsecondes de temps CPU. Rappelons quen pratique les fichiers ne
sont pas ncessairement stocks squentiellement sur disque, mme sils sont crits
et lus squentiellement dans le programme. Par consquent, un accs disque
reprsente en ralit un cot CPU gnralement plus proche de celui dun accs
alatoire que dun accs squentiel thorique.
E/S de communication
Les E/S disque sur des systmes de fichiers monts distance, de type NFS ou AFS,
sont excutes sur le serveur. Dans ce cas, il y a davantage de demandes mmoire et
CPU ct client.
Les appels de procdure distance (RPC) de tous types constituent une bonne part
de la charge CPU. Cest pourquoi il est conseill de les rduire au minimum, de
diffrer leur traitement, den faire un prototype et de les mesurer lavance.
Dans des conditions de laboratoire, chaque lecture ou criture NFS dune page de
4 ko mobilise environ 670+/30 microsecondes de temps CPU client.
Chaque lecture ou criture alatoire NFS dune page de 4 ko mobilise environ
1000+/200 microsecondes de temps CPU client.
4-8
valuation de la charge de travail partir de celle du programme

Pour valuer les besoins en ressources moyens et maximaux, le mieux est dutiliser un
modle de mise en file dattente du type BEST/1. Si vous optez pour un modle statique,
vous risquez de sous ou surestimer la limite maximale. Dans les deux cas, vous devez bien
apprhender les interactions entre programmes, en termes de ressources.
Si vous laborez un modle statique, utilisez lintervalle de temps correspondant au pire
temps de rponse acceptable pour le programme le plus sollicit. Dterminez, en fonction
du nombre dutilisateurs prvu, leur temps de rflexion, la frquence des saisies au clavier,
les diverses oprations par anticipation et les programmes gnralement excuts pendant
chaque intervalle.
Temps CPU
Faites la somme des besoins CPU requis par tous les programmes excuts durant
cet intervalle. Noubliez pas dy inclure les temps requis par les E/S de communication
et les E/S disque effectues par les programmes.
Si ce nombre est suprieur 75 % du temps CPU disponible durant cet intervalle,
envisagez de rduire le nombre dutilisateurs ou daugmenter la capacit CPU.
Mmoire relle
Commencez avec 6 8 Mo pour le systme dexploitation lui-mme. Le chiffre
infrieur concerne un systme autonome. Le dernier est applicable un systme
connect au LAN et exploitant TCP/IP et NFS.
Faites la somme des besoins des segments de travail pour toutes les instances de
programmes qui doivent tre excutes durant cet intervalle, en incluant lespace
estim pour les structures de donnes du programme.
Ajoutez la capacit mmoire requise du segment de texte pour chaque programme
distinct devant tre excut (une copie dun texte de programme dessert toutes les
instances de ce programme). Rappelons que toutes les sous-routines (et seulement
les sous-routines) provenant de bibliothques non partages sont partie intgrante de
lexcutable, mais que les bibliothques ne sont pas en mmoire.
Ajoutez la quantit despace consomm par chacune des bibliothques partages
utilises par les programmes. Ici aussi, une copie dessert tous les programmes.
Pour rserver suffisamment despace la mise en mmoire cache de certains fichiers
et la liste ouverte, vos prvisions en mmoire totale ne doivent pas excder 80 % de
la mmoire de la machine prvue.
E/S disque
Faites la somme des E/S impliques par chaque instance de chaque programme.
Distinguez entre les E/S sur les petits fichiers et les E/S alatoires sur les grands
fichiers, dune part, et les E/S purement squentielles sur les gros fichiers (de plus
de 32 ko), dautre part.
Retranchez les E/S qui, selon vous, seront satisfaites partir de la mmoire.
Tout enregistrement lu ou crit dans lintervalle prcdent est probablement toujours
disponible dans lintervalle courant. Par ailleurs, comparez la taille de la machine
considre avec la capacit RAM totale requise pour la charge de travail. Lespace
restant, une fois satisfaits les besoins du systme dexploitation et de la charge de
travail, contient probablement les pages de fichiers rcemment lues ou crites.
Si votre application est conue de sorte que la probabilit de rutiliser les donnes
rcemment exploites est trs leve, vous pouvez revoir la baisse les prvisions
dutilisation de la mmoire cache. Notez que la rutilisation des donnes se fait au
niveau de la page et non de lenregistrement. Sil est peu probable quun
enregistrement soit rutilis, mais quune page contienne de nombreux
enregistrements, certains des enregistrements requis pendant un intervalle donn ont
des chances de se trouver sur la mme page que dautres enregistrements
rcemment utiliss.
4-9
Comparez le niveau net dE/S requis la capacit approximative des units de

disques courantes (voir le tableau). Si la capacit requise en pages alatoires et
squentielles est suprieure 75 % de la capacit totale des disques porteurs des
donnes de lapplication, il vous faudra certainement optimiser, voire tendre ces
capacits lors de lexcution de lapplication.
E/S de communication
Calculez lutilisation de la largeur de bande de la charge. Lutilisation totale de la
largeur de bande de tous les nuds du rseau LAN ne doit pas excder 70 % de la
largeur de bande nominale (50 % pour Ethernet).
Il est conseill deffectuer la mme analyse sur les besoins CPU, mmoire et E/S de la
charge supplmentaire que le serveur devra prendre en charge.
Rappelons que ces mesures ne fournissent quune estimation trs approximative et quil est
prconis de remplacer ds que possible les rsultats estims par une mesure relle :
lestimation globale nen sera que plus prcise.
4-10
Conception et implantation de programmes performants

Si vous avez dj localis la ressource qui ralentit votre programme, passez directement
la section traitant des moyens de minimiser son utilisation. Sinon, vous devez envisager
dquilibrer votre programme, en vous aidant des recommandations de ce chapitre. Une fois
le programme install, passez Identification des ressources limitatives, page 1-1.
Programmes CPU limite
Conception et codage pour lexploitation optimale des mmoires cache
Prprocesseurs et des compilateurs XL

La vitesse maximale dun programme rellement limit en temps processeur est fonction :
de lalgorithme utilis,
du code source et des structures de donnes cres par le programmeur,
de la squence dinstructions en langage machine gnre par le compilateur,
de la taille et des structures des mmoires cache du processeur,
de larchitecture et de la vitesse dhorloge du processeur.
Si le programme est limit en CPU simplement parce quil est constitu quasi-exclusivement
dinstructions de calcul numrique, lalgorithme choisi sera videmment dterminant pour
les performances du programme. Le dbat sur le choix des algorithmes dpasse le cadre
de ce manuel. On suppose que les performances de calcul ont t prises en compte dans
le choix de lalgorithme.
Lalgorithme tant donn, les seuls lments de la liste sur lesquels le programmeur peut
intervenir sont le code source, les options de compilation et ventuellement les structures
de donnes. Les sections qui suivent prsentent les techniques damlioration de
programmes partir du code source. Si lutilisateur ne dispose pas du code source, il doit
recourir aux techniques doptimisation ou de gestion de la charge.
Conception et codage pour lexploitation optimale des mmoires cache

Comme indiqu Performances, les processeurs du ESCALA disposent dune mmoire
hirarchique multiniveau :
1. Pipeline dinstructions et registres CPU
2. Mmoires cache dinstructions et de donnes avec tampons TLB correspondants
3. RAM
4. Disque
Au fur et mesure de leur progression dans la hirarchie, les instructions et les donnes
transitent par des mmoires de plus en plus rapides, mais aussi de plus en plus rduites et
consommatrices. Pour tirer le meilleur parti dune machine, le programmeur doit sattacher
exploiter au mieux la mmoire disponible chaque niveau de la hirarchie.
Pour cela, la rgle de base consiste maintenir en mmoire les instructions et donnes
susceptibles dtre utilises. Mais une difficult doit tre surmonte : la mmoire est
affecte en blocs de longueur fixe (en lignes de cache ou pages de mmoire relle, par
exemple) qui ne correspondent gnralement pas aux structures des programmes ou des
donnes. Cette inadquation diminue lefficacit des mmoires affectes, et par voie de
consquence, les performances des systmes, notamment de petite taille ou
particulirement chargs.
4-11
Prendre en compte la hirarchie des mmoires ne signifie pas programmer en fonction

dune page ou dune taille de ligne de cache. Il sagit simplement de comprendre et
dadapter les rgles gnrales de programmation un environnement de mmoire virtuelle
ou cache. Des techniques de redcoupage des modules permettent dobtenir des rsultats
satisfaisants sans modifier le code existant. Naturellement, si du code doit tre ajout, il faut
tenir compte des impratifs defficacit de mmoire.
En terme doptimisation des mmoires hirarchiques, deux notions sont incontournables : le
regroupement rfrentiel et la partie active. Le regroupement rfrentiel dun programme
est le degr de regroupement de ses adresses dexcution dinstruction et des rfrences
de donnes dans une zone restreinte de la mmoire pendant un intervalle donn.
La partie active dun programme, au cours du mme intervalle, est lensemble des blocs
mmoire utiliss, ou, plus prcisment, le code ou les donnes qui occupent ces blocs. Un
programme prsentant un bon regroupement rfrentiel aura une partie active minimale, les
blocs utiliss tant troitement associs aux codes et aux donnes. Inversement, la partie
active dun programme quivalent au niveau fonctionnel mais prsentant un regroupement
rfrentiel mdiocre sera plus tendue, davantage de blocs tant ncessaires pour accder
un ventail dadresses plus tendu.
Le chargement de chaque bloc un niveau donn de la hirarchie demandant un temps
non ngligeable, une programmation efficace sur un systme mmoire hirarchique doit
viser limiter au minimum la partie active du programme par un codage appropri.
La figure Regroupement rfrentiel, prsente deux schmas. Le premier, dconseill,
illustre un programme vraisemblablement structur dans lordre dans lequel il a t crit, en
quelque sorte en suivant le fil de la pense : La premire sous-routine, PriSub1, contient
le point dentre du programme. Il utilise toujours les sous-routines principales PriSub2 et
PriSub3. Certaines fonctions peu utilises du programme demandent des sous-routines
secondaires SecSub1 et 2. Trs rarement, les sous-routines derreur ErrSub1 et 2 sont
requises. Cette structuration offre un regroupement rfrentiel mdiocre, sollicitant trois
pages de mmoire en excution normale. Les sous-routines secondaires et les
sous-routines derreur divisent le chemin principal du programme en trois sections
physiquement distantes.
Faible regroupement rfrentiel et partie active tendue
Page 1
PriSub1
SecSub1
Page 2
ErrSub1
PriSub2
SecSub2
Page 3
ErrSub2
PriSub3
Fort regroupement rfrentiel et partie active rduite

Page 1
PriSub1
PriSub2
Page 2
PriSub3
SecSub1
SecSub2
Page 3
ErrSub1
ErrSub2
Regroupement rfrentiel
Le second schma propose une version amliore du programme o les sous-routines
principales sont regroupes, les fonctions peu sollicites places ensuite et les
sous-routines derreur, ncessaires mais peu utilises, places en fin de programme. Les
fonctions les plus courantes peuvent prsent tre traites en une seule lecture disque et
une seule page de mmoire au lieu des trois du schma prcdent.
Rappelons que le regroupement rfrentiel et la partie active sont dfinis par rapport au
temps. Si un programme fonctionne par tape prenant chacune un certain temps et utilisant
diffrentes sous-routines, il est conseill de limiter au minimum la partie active chaque
tape.
4-12
Registres et pipeline
En gnral, laffectation et loptimisation de lespace de registre, ainsi que le maintien des
donnes dans le pipeline sont la charge des compilateurs. En revanche, il incombe au
programmeur dviter toute structure en contradiction avec les mcanismes doptimisation
du compilateur. Par exemple, si vous insrez une sous-routine dans lune des boucles
critiques, le compilateur prfrera sans doute lincorporer dans la partie principale du
programme pour limiter le temps dexcution. Or, si cette sous-routine a t place dans un
module .c diffrent, le compilateur ne pourra la dplacer.
Cache et tampon TLB

En fonction de larchitecture (POWER, POWER 2 ou PowerPC) et du modle, les
processeurs du ESCALA ont un ou plusieurs caches prendre en charge :
Parties de programmes dexcution,
Donnes utilises par ces programmes,
Tampons TLB (Translation Lookaside Buffer) contenant les informations de mappage
entre les adresses virtuelles et les adresses relles des pages de texte dinstructions ou
de donnes rcemment utilises.
Si une absence en cache se produit, le chargement dune ligne complte de cache peut
demander plus dune douzaine de cycles processeur. En cas dabsence en TLB, le calcul du
mappage virtuel-rel dune page peut demander plusieurs douzaines de cycles. Le cot
exact de ces oprations dpend de limplantation. Pour en savoir plus sur les architectures
des mmoires cache, reportez-vous lannexe C.
Mme si un programme et ses donnes tiennent dans les mmoires cache, plus il y a de
lignes ou dentres TLB utilises (cestdire, plus mdiocre est le regroupement
rfrentiel), plus le nombre de cycles CPU augmente pour mener bien le chargement.
Sauf si les instructions et les donnes sont frquemment rutilises, la surcharge lie au
chargement constitue une part importante du temps dexcution du programme, entranant
des performances moindres du systme.
Sur les machines quipes de mmoires cache, il est conseill de maintenir la partie
principale du programme contenant les oprations courantes la plus compacte possible.
De plus, la procdure principale et lensemble des sous-routines quelle appelle doivent tre
contigus. Les oprations plus exceptionnelles, telles que les erreurs inexpliques, doivent
seulement tre testes dans la partie principale. Si cette condition intervient rellement, elle
doit tre traite dans une sous-routine distincte. Toutes les sous-routines de ce type doivent
tre regroupes la fin du module. Cette structure permet dviter que des codes peu
utiliss monopolisent de lespace dans les lignes cache trs sollicites. On peut mme
imaginer dans le cas de modules importants que certaines, voire la totalit, des
sous-routines peu usites occupent une page qui nest pratiquement jamais lue en
mmoire.
Le mme principe est applicable aux structures de donnes, mme sil est parfois
ncessaire de modifier le code source du fait des rgles dorganisation de donnes par les
compilateurs. Ce type de difficult a t rencontr durant le dveloppement dAIX version 3.
Certaines oprations matricielles, telle la multiplication, impliquent des algorithmes qui, sils
ont t cods de faon trop simpliste, prsentent un regroupement rfrentiel mdiocre.
Ces oprations supposent gnralement un accs squentiel aux donnes de la matrice
(lments de ranges agissant sur des lments de colonnes, par exemple). Chaque
compilateur a ses propres rgles de stockage des matrices. Par exemple, le compilateur
XL FORTRAN les organise par colonnes (lments de la colonne 1 suivis des lments de
la colonne 2, etc.), mais le compilateur XL C les organise par ranges. Si les matrices sont
de petite taille, les lments des ranges et des colonnes peuvent tre placs dans la
mmoire cache de donnes, et le processeur et lunit virgule flottante sexcuter la
vitesse maximale. Mais, plus la taille des matrices augmente, plus le regroupement
rfrentiel de ces oprations de ranges/colonnes se dtriore, jusquau point o les
donnes ne peuvent plus tre stockes dans la mmoire cache.
4-13
En fait, le modle naturel daccs des oprations sur les ranges/colonnes gnre un
mcanisme demballement de la mmoire : il y a accs une chane dlments de taille
suprieure au cache, si bien que les lments utiliss initialement sont expulss et la mme
mthode daccs de nouveau applique pour les mmes donnes. La solution
gnralement prconise est de partitionner lopration en blocs, de sorte que les diverses
oprations portant sur les mmes lments puissent tre excutes quand les lments
sont encore en mmoire cache. Cette technique gnrale est appele exploitation par
blocs. Un groupe de chercheurs comptents en analyse numrique a t sollicit pour
coder des versions des algorithmes de manipulation de matrices, en utilisant lexploitation
par blocs et dautres techniques doptimisation. Rsultat : des performances 30 fois
meilleures pour la multiplication des matrices. Cette version optimise des routines a t
installe dans la bibliothque BLAS (Basic Linear Algebra Subroutines) dAIX,
/usr/lib/libblas.a. Un jeu plus tendu de sous-routines optimises est galement disponible
dans le programme sous licence ESSL (Engineering and Scientific Subroutine Library),
document dans le manuel IBM Engineering and Scientific Subroutine Library Guide and
Reference.
Les fonctions et les interfaces des sous-routines BLAS (Basic Linear Algebra Subroutines)
sont dcrites dans AIX Technical Reference, Volume 2: Base Operating System and
Extensions. Cette bibliothque nest accessible que si lenvironnement dexcution
FORTRAN est install. Elle est destine particulirement aux utilisateurs qui doivent
effectuer leurs propres oprations vectorielles et matricielles :les sous-routines proposes
offrent un degr doptimisation tel quun non spcialiste danalyse numrique ne risque pas
de faire mieux.
Si le programmeur contrle les structures des donnes, dautres amliorations peuvent tre
envisages. En gnral, il est prconis de regrouper au maximum les donnes souvent
utilises. Si une structure contient la fois des informations de contrle trs sollicites et
des donnes dtailles peu sollicites, assurez-vous que les informations de contrle sont
affectes sur des octets conscutifs. Cette prcaution permettra de charger la totalit des
informations de contrle en mmoire cache en limitant les cas dabsences en cache
( quelques-uns, voire un seul).
Prprocesseurs et compilateurs XL
Pour exploiter au mieux un programme sur une machine donne, il faut savoir que :
Certains prprocesseurs permettent de rorganiser la structure de certains codes source
de faon obtenir un module source, quivalent au niveau fonctionnel, mais compilable
en code excutable plus performant.
Plusieurs options de compilation sont disponibles en fonction de la ou des variantes
darchitecture POWER utilises.
La fonction #pragma permet de signaler certains aspects du programme au
compilateur XL C pour quil gnre un code plus efficace en allgeant certaines
hypothses concernant les cas les moins favorables.
Plusieurs niveaux doptimisation confrent au compilateur une marge de libert plus ou
moins tendue pour rorganiser les instructions.
Pour les programmeurs presss, une seule rgle est prconise : loptimisation
systmatique. Le gain de performances induit par une optimisation du code, aussi simple
soit-elle, est tel quil serait aberrant den faire lconomie (ne serait-ce quen appliquant
loption O de la commande cc, xlc ou xlf). Les seules exceptions cette rgle sont les
conditions de test qui exigent de gnrer le code tel quel (par exemple, pour analyser les
performances au niveau des instructions par la fonction tprof).
Les autres techniques doptimisation confrent certains programmes des performances
suprieures mais il faut procder nombre de recompilations et mesures pour dterminer la
combinaison technique la mieux approprie un programme particulier.
4-14
Les diffrentes techniques dexploitation optimales des compilateurs sont prsentes dans
les sections qui suivent. Pour une description plus dtaille, reportez-vous au manuel
Optimization and Tuning Guide for XL Fortran, XL C and XL C++.
Prprocesseurs de code source

Il existe plusieurs prprocesseurs de code source disponibles pour le ESCALA. Trois nous
intressent pour le moment :
KAP/C (de Kuck and Associates)
KAP/FORTRAN (de Kuck and Associates)
VAST (de PSR)
Une des techniques utilises par ces prprocesseurs est la reconnaissance des codes,
technique mathmatiquement quivalente celle applique par les sous-routines des
bibliothques ESSL ou BLAS cites prcdemment : le prprocesseur remplace le code de
calcul initial par un appel une sous-routine optimise. Les prprocesseurs tentent
galement de modifier les structures de donnes pour les adapter au mieux aux machines
ESCALA.
Compilation propre une architecture

Loption de compilation qarch permet dindiquer larchitecture POWER (POWER,
POWER 2 ou PowerPC) sur laquelle lexcutable sera exploit. Les valeurs possibles sont :
qarch=COM
Compilation du sous-ensemble commun des trois jeux dinstructions.

Les programmes compils avec cette option fonctionnent correctement
sur les trois architectures. Valeur par dfaut.
qarch=PWR
Compilation pour larchitecture POWER du ESCALA dorigine.

Les programmes compils avec cette option fonctionnent correctement
sur les trois architectures, mais certaines instructions seront simules
sur les systmes PowerPC, au dtriment des performances.
qarch=PWRX
Compilation pour POWER2. Les programmes qui utilisent largement la

racine carre virgule flottante simple ou double prcision offriront des
performances suprieures. Les excutables ne doivent tre exploits
que sur des systmes POWER2.
qarch=PPC
Compilation pour PowerPC. Les programmes qui font souvent appel

lextraction de racines carres virgule flottante simple offriront des
performances suprieures. Lexcutable ne doit tre exploit que sur
des systmes PowerPC.
Loption de compilation qtune oriente le compilateur sur larchitecture favoriser. A la

diffrence de qarch, qtune ne gnre pas dinstructions propres une architecture.
Loption indique seulement au compilateur, dans le cas dune alternative, la technique la
plus approprie une architecture. Les valeurs possibles de qtune sont :
qtune=PWR
Le programme fonctionne essentiellement sur des systmes POWER.
qtune=PWRX
Le programme fonctionne essentiellement sur des systmes POWER2.
qtune=601
Le programme fonctionne essentiellement sur des systmes

PowerPC 601.
La figure Combinaisons des valeurs de qarch et qtune indique les combinaisons de

valeurs possibles et par dfaut de loption qtune pour les valeurs spcifies de qarch.
Si aucune option nest spcifie, qarch=COM qtune=PWR est appliqu par dfaut.
4-15
qtune=PWR
qtune=PWRX
qtune=601
par dfaut
qarch=COM
OK
OK
OK
PWR
qarch=PWR
OK
OK
OK
PWR
qarch=PWRX
OK
OK
non valide
PWRX
qarch=PPC
OK
non valide
OK
601
Combinaisons des valeurs de qarch et qtune
Directive #pragma
Dans certains cas, loptimiseur peut tre inhib par la ncessit de gnrer un code qui
tienne compte des conditions les moins favorables. Pour signaler au compilateur que
certaines contraintes peuvent tre assouplies et autoriser ainsi la gnration dun code plus
efficace, vous disposez de la directive #pragma.
Un pragma est une instruction dfinie limplantation. Les pragmas sont de la forme :
#pragma character_sequence ...
Les pragmas en XL C ci-dessous peuvent sensiblement amliorer les performances dun
programme sans modifier le reste du code source :
disjoint
isolated_call
Directive #pragma disjoint
La directive #pragma disjoint rpertorie les identificateurs qui, dans le cadre de leur
utilisation, ne jouent pas le rle dalias entre eux :
#pragma disjoint ( { identifier | *identifier }
[,{ identifier | *identifier } ] ... )
La directive informe le compilateur quaucun des identificateurs de la liste ne partage la
mme mmoire physique, ce qui donne plus de latitude pour les optimisations. Si lun des
identificateurs de la liste partage en ralit de la mmoire physique, les rsultats du
programme risquent dtre incorrects.
Cette directive peut apparatre nimporte quel point du programme source.
Un identificateur doit tre cit dans le programme l o la directive apparat. Les
identificateurs ne peuvent renvoyer :
un membre dune structure ou dune union,
un lien une structure ou une union,
une constante dnumration,
une tiquette.
Les identificateurs doivent tre dclars avant dtre cits dans une pragma. Aucun
pointeur de la liste des identificateurs ne doit avoir servi dargument une fonction avant
dapparatre dans la directive.
Lutilisation de la directive #pragma disjoint est illustre dans lexemple ci-dessous. Le
pointeur externe ptr_a ne partage pas de mmoire avec la variable externe b pas plus
quil ne pointe vers elle, le compilateur peut donc en dduire que la proposition 7 pour
lobjet sur lequel ptr_a pointe ne modifiera pas la valeur b. De mme, le pointeur externe
ptr_b ne partage pas de mmoire avec la variable externe a, pas plus quil ne pointe vers
elle. Par consquent, le compilateur peut en dduire que largument de
another_function prend la valeur 6.
4-16
int a, b, *ptr_a, *ptr_b;

#pragma disjoint(*ptr_a, b)
/* ptr_a ne pointe jamais sur b */
#pragma disjoint(*ptr_b, a)
/* ptr_b ne pointe jamais sur a
*/
one_function()
{
b = 6;
*ptr_a = 7; /* La proposition ne changera pas la valeur b */
another_function(b);
/* Largument b a pour valeur 6 */
}
#pragma isolated_call
La directive #pragma isolated_call rpertorie les fonctions qui ne modifient pas les objets
de donnes visibles lors de lappel de la fonction.
#pragma isolated_call ( identifier [ , identifier ] ... )
Le pragma doit tre plac avant tout appel aux fonctions de la liste didentificateurs.
Les identificateurs de la liste doivent tre dclars avant dtre cits dans une pragma.
Toute fonction rpertorie dans la liste et appele avant que la directive ne soit utilise nest
pas traite comme un appel isol. Les identificateurs doivent tre de type fonction ou de
type dfinition de fonction.
La directive indique au compilateur quaucune fonction cite ninduit deffets secondaires.
Par exemple, laccs un objet volatile, la modification dun objet externe, la modification
dun fichier ou lappel dune fonction excutant lune de ces oprations peut tre considr
comme exempt deffet secondaire. Toute modification dtat de lenvironnement dexcution
peut tre considre comme un effet secondaire. Le passage darguments de fonction par
rfrence est lun des effets secondaires autoriss, mais il faut savoir que les effets
secondaires peuvent gnrer des rsultats errons lorsquils apparaissent dans les
directives #pragma isolated_call.
Dclarer une fonction comme isole indique loptimiseur que les variables externes et
statiques ne peuvent pas tre modifies par la fonction appele et que, le cas chant, les
rfrences mmoire peuvent tre supprimes partir de la fonction appele. Il est possible
dagencer les instructions plus librement de faon limiter les dlais de pipelines et
acclrer lexcution. Il faut savoir que ragencer les instructions peut gnrer un code qui
requiert davantage de valeurs de porte gnrale et/ou de registres virgule flottante pour
tre maintenu dans lappel isol. Lorsque lappel isol nest pas intgr une boucle, le
temps systme utilis pour la sauvegarde et la restauration des registres supplmentaires
peut neutraliser le gain acquis par la suppression des rfrences mmoire.
Les fonctions spcifies dans la liste des identificateurs sont autorises pour examiner des
objets externes et renvoyer des rsultats dpendant de ltat de lenvironnement
dexcution. Ces fonctions peuvent galement modifier la mmoire pointe par un argument
pass la fonction, autrement dit, des appels par rfrence. Ne spcifiez aucune fonction
qui sauto-appelle ou repose sur une mmoire statique locale. Intgrer une telle fonction
dans la directive #pragma isolated_call peut entraner des rsultats imprvisibles.
Lexemple suivant illustre lutilisation de la directive #pragma isolated_call. Le compilateur
suppose que lappel de la fonction this_function ne changera pas la valeur de la
variable externe a car cette fonction na pas deffet secondaire. Ds lors, le compilateur peut
supposer que largument de other_function a pour valeur 6.
int a, this_function(int); /* Suppos sans effets secondaires */
#pragma isolated_call(this_function)
that_function()
{
a = 6;
this_function(7); /* Lappel ne modifie pas la valeur de a */
other_function(a);
/* Largument a a la valeur 6 */
}
4-17
Niveaux doptimisation
Les niveaux doptimisation offerts par les compilateurs XL ont t modifis par rapport aux
versions antrieures. Les nouvelles options proposes sont :
Pas doptimisation
En labsence de toute forme dindicateur O, le compilateur gnre un code brut sans
restructuration des instructions ni autre forme damlioration.
O ou O2
Ces indicateurs (quivalents) demandent au compilateur deffectuer une optimisation en se
fondant sur une restructuration minimale du code. Seules sont appliques les directives
explicites de type #pragma. Ce niveau neffectue plus de mise en pipeline logicielle, de
droulement de boucles ou de simple mise en commun prvisionnelle. Il dfinit galement
une contrainte sur la quantit de mmoire utilisable par le compilateur.
Il en rsulte, par rapport aux versions antrieures, une possible dgradation des
performances des routines tendues ou complexes compiles avec loption O.
O3
Cette option impose au compilateur dappliquer les techniques doptimisation et dutiliser le
volume de mmoire ncessaire pour une optimisation maximale.
Ce niveau peut modifier les programmes au niveau fonctionnel si ces derniers tiennent
compte :
des exceptions virgule flottante,
du signe de zro,
des effets dun ragencement des calculs.
Ces effets secondaires peuvent cependant tre vits, au prix dune diminution des
performances, en combinant loption qstrict avec O3.
Loption qhot combine O3 permet deffectuer des mises en commun prvisionnelles et
quelques droulements de boucle.
Par rapport loption O des versions antrieures, ces modifications procurent le mme
niveau, voire un niveau plus lev de performances des routines tendues ou complexes
compiles avec loption O3 (ventuellement combine qstrict ou qhot).
Options XL C pour loptimisation de la sous-routine string.h

AIX permet dimbriquer les sous-routines string dans le programme dapplication au lieu de
les utiliser partir de libc.a. Cette opration conomise le temps de la liaison appel/retour.
Pour ce faire, le code source de lapplication doit comporter linstruction :
#include <string.h>
avant dutiliser la (les) sous-routine(s). Sous la version 3.1, les seules sous-routines
insrables par cette technique sont :
strcpy()
strcmp()
Sy ajoutent dsormais les sous-routines :
strlen()
strchr()
strrchr()
strcat()
strncat()
4-18
strncpy()
strncmp()
index()
rindex()
memchr()
memcpy()
memccpy()
memmove()
memcmp()
memset()
Pour revenir au niveau dimbrication de la version 3.1, faites prcder linstruction
#include <string.h> de :
#define __STR31__
Style de codage optimis C et C++

Dans un grand nombre de cas, le cot en termes de performances dun module C nest pas
vident, voire contraire ce qui tait attendu. Voici quelques conseils cet gard.
Chaque fois que possible, utilisez le type int au lieu de char ou short.
La plupart du temps, les types de donnes char et short requirent davantage
dinstructions. Le cot supplmentaire induit (en terme de temps) et, exception faite des
grands tableaux, lconomie despace ainsi ralise sont plus que neutraliss par
laccroissement de la taille de lexcutable.
Si vous devez utiliser le type char, dclarez-le unsigned, si possible.
signed char exige deux instructions de plus que unsigned char chaque
chargement de la variable dans un registre.
Optez de prfrence pour des variables locales (automatiques) plutt que des variables
globales.
Laccs aux variables globales demande plus dinstructions que laccs aux variables
locales. De plus, en labsence dinformations, le compilateur suppose que toute variable
globale a t modifie par un appel de sous-routine. Ce phnomne a un effet inverse
sur loptimisation car la valeur dune variable globale utilise aprs un appel de
sous-routine doit tre recharge.
Chaque fois que vous devez accder une variable globale (non partage par dautres
routines), copiez sa valeur dans une variable locale et utilisez cette copie.
Sauf si la variable globale nest utilise quune fois, il est plus efficace dutiliser la copie
locale.
Prfrez les codes binaires aux chanes pour les enregistrements et les tests.
Les chanes utilisent la fois lespace de donnes et lespace dinstructions. Par
exemple, la squence :
#define situation_1 1
int situation_val;
situation_val = situation_2;
. . .
if (situation_val == situation_1)
. . .
4-19
est plus efficace que :

char situation_val[20];
strcpy(situation_val,situation_2);
. . .
if ((strcmp(situation_val,situation_1))==0)
. . .
Lorsque les chanes sont vraiment ncessaires, prfrez les chanes de longueur fixe
aux chanes de longueur variable termine par zro.
Les routines de type mem*(), telles que memcpy(), sont plus rapides que les routines
str*() correspondantes, telles que strcpy(), car les routines str*() doivent vrifier chaque
octet la recherche dune valeur nulle, alors que les routines mem*() nont pas le faire.
Temps dexcution des compilateurs

Sous AIX, deux commandes permettent dappeler le compilateur C : cc et xlc.
La commande cc, historiquement utilise pour appeler le compilateur C du systme lance le
compilateur XL C en mode langlevel=extended. Ce mode permet de compiler des
programmes C non conformes aux normes ANSI. Mais il consomme galement du temps
processeur.
Si le programme compiler est conforme ANSI, il est prfrable dappeler le
compilateur XL C via la commande xlc.
Spcifier lindicateur O3 englobe implicitement loption qmaxmem. Ainsi, le compilateur
peut utiliser autant de mmoire que loptimisation maximum lexige. Il en rsulte deux
effets :
Sur un systme multi-utilisateur, une compilation O3 lourde peut utiliser une quantit de
mmoire telle que les autres utilisateurs subiront une baisse des performances.
Sur un systme pauvre en mmoire relle, une compilation O3 lourde peut utiliser une
quantit de mmoire telle que le taux de pagination sera lev et la compilation
srieusement ralentie.

Pour un programmeur sans cesse confront aux limitations dadressage imposes par
certains environnements (tels que DOS), lenvironnement du ESCALA avec ses segments
de mmoire virtuelle de 256 Mo semble offrir des possibilits infinies. Il est alors tent
dignorer les contraintes de mmoire et de coder avec des longueurs de chemin minimales
et une simplicit extrme. Cette ngligence nest pas sans consquences. La mmoire
virtuelle est vaste, mais sa vitesse est variable. Plus la mmoire est utilise, plus elle est
ralentie selon une progression non linaire. Tant que le volume total de mmoire virtuelle
sollicite par lensemble des programmes (cest--dire le cumul des parties actives) est
lgrement infrieur au volume de mmoire relle non fixe, la mmoire virtuelle sexcute
peu prs la mme vitesse que la mmoire relle. Ds que le volume sollicit dpasse le
nombre de trames de page disponibles, les performances de la mmoire se dgradent (si la
fonction de contrle de charge est dsactive) selon une progression pouvant atteindre un
facteur 2. On dit alors que le systme semballe : il consacre presque tout son temps la
pagination, au dtriment de tout travail productif, chaque processus tentant de reprendre
aux autres la mmoire ncessaire pour alimenter sa partie active. Si la fonction de contrle
de charge mmoire VMM est active, cet auto-emballement perptuel peut tre vit, mais
au prix dun allongement considrable des temps de rponse.
Il est plus grave dexploiter inefficacement la mmoire que les caches. En effet, lcart de
vitesse entre la mmoire et le disque est bien suprieur celui entre la mmoire et le
cache. Et si une absence en mmoire cache consomme quelques dizaines de cycles CPU,
un dfaut de page requiert plus de 20 millisecondes, soit au moins 400 000 cycles CPU.
4-20
Mme si la prsence de la fonction de contrle de charge mmoire VMM sous AIX garantit
quaucune condition demballement naissante ne dgnre en auto-emballement perptuel,
les temps de rponse et/ou le dbit subissent leffet des dfauts de page inutiles.
Structuration du code paginable

Pour limiter la partie de code active dun programme, regroupez le code frquemment
excut dans une zone rduite, spare du code rarement excut. En particulier :
Ne placez pas sur une ligne de longs blocs de code de traitement des erreurs.
Insrez-les dans diffrentes sous-routines, de prfrence dans des modules de code
source distincts. Cette consigne sapplique non seulement aux chemins derreur, mais
aussi toute option fonctionnelle peu utilise.
Ne structurez pas les modules chargeables arbitrairement. Faites en sorte que les
modules objet frquemment appels soient implants le plus prs possible des
demandeurs. Il est prfrable de concentrer en fin de module chargeable les modules
objet composs (idalement) de sous-routines peu appeles. Les page quils renferment
sont rarement lues.
Structuration des donnes paginables

Pour limiter la partie de donnes active, tentez de regrouper les donnes trs sollicites et
vitez les rfrences inutiles aux pages de mmoire virtuelle. En particulier :
Naffectez via malloc ou calloc que lespace ncessaire. Aprs malloc, ninitialisez
jamais un tableau de taille maximale si, en ralit, seule une fraction de celui-ci est
utilise. Lorsque vous modifiez une nouvelle page pour initialiser les lments du
tableau, vous forcez VMM voler une page de mmoire relle. Cette opration
entranera un dfaut de page lorsque le processus propritaire de la page vole tentera
dy accder. Pensez que la diffrence entre malloc et calloc ne se situe pas seulement
au niveau de linterface. Dans la mesure o calloc met zro lespace mmoire affect,
il touche toutes les pages affectes, alors que malloc ne touche que la premire page.
Si vous affectez un espace tendu via calloc et nutilisez au dbut quune petite portion
de cet espace, vous chargez inutilement le systme. Non seulement les pages doivent
tre initialises, mais aussi, si leurs trames en mmoire relle sont demandes, ces
pages (qui ne seront jamais utilises) doivent tre crites dans lespace de pagination.
Vous gaspillez ainsi des E/S et des emplacements de lespace de pagination.
Les mmes problmes peuvent se produire avec des listes lies de vastes structures
(telles que des tampons). Si votre programme doit effectuer une srie de chanages la
recherche dune cl, sparez liens et cls, dune part, et donnes, dautre part, ou optez
pour un systme de style table de hachage.
Le regroupement rfrentiel doit tre autant spatial que temporel : les structures de
donnes doivent tre initialises juste avant leur utilisation (si tant est quelles le soient).
Sur un systme trs charg, si une longue priode spare linitialisation de lutilisation
des structures de donnes, ces dernires risquent de se voir voler leurs trames.
Le programme se heurte alors un dfaut de page ds quil tente dutiliser la structure de
donnes concerne.
De mme, si, une fois utilise, une grande structure nest plus sollicite jusqu la fin du
programme, elle doit tre libre. Mais, utiliser free pour librer de lespace affect par
malloc ou calloc ne suffit pas, car la commande free ne libre que les intervalles
dadresses occups par la structure. Pour librer de la mmoire relle et de lespace de
pagination, vous devez renoncer cet espace via la commande disclaim.
Mmoire fixe optimise

Pour viter les phnomnes de boucles et de temps dattente, une petite fraction du
systme doit tre fixe en mmoire relle. La notion de partie active na alors plus de sens
pour le code et les donnes impliques puisque toutes les informations fixes se trouvent
en permanence en mmoire relle, quelles soient utilises ou non. Les programmes
(pilotes dunit crits par un utilisateur, par exemple) qui fixent un code ou une donne
4-21
doivent tre soigneusement labors (ou examins, sils sont ports) pour sassurer que les
fractions de mmoire fixe sont utilises avec parcimonie. Voici quelques conseils ce sujet :
Le code est fix sur la base de module chargeable (fichier excutable). Si certains
modules objets dun composant doivent tre fixs et dautres simplement pagins, veillez
placer les modules fixer dans un module chargeable distinct.
Il nest pas souhaitable de fixer prventivement un module ou une structure de donnes :
le concepteur doit savoir dans quelles conditions linformation peut tre demande et si,
dans ce cas, un dfaut de page peut ou non tre tolr.
Les structures fixes dont la taille dpend de la charge (telles que les pools de mmoire
tampon) doivent tre optimisables par ladministrateur systme.
4-22
Conseils pour une installation performante

Cette section vous conseille sur les actions excuter avant et pendant linstallation.
Prinstallation dAIX
Prinstallation de la CPU
Prinstallation de la mmoire
Prinstallation du disque
Prinstallation des cartes de communication : dcrit Rcapitulatif des paramtres
doptimisation dUDP, de TCP/IP et de mbuf.
Prinstallation dAIX
Installation dAIX sur un nouveau systme
Avant de commencer linstallation, vous devez avoir dtermin la taille et lemplacement des
systmes de fichiers disque et des espaces de pagination, et le moyen de les communiquer
AIX.
Mise niveau dAIX sur un systme existant

Pour installer une mise niveau dAIX :
Identifiez, dans votre environnement actuel, toutes les utilisations des outils
doptimisation schedtune et vmtune, propres cette version. Ces outils tant rservs
lutilisateur racine, vous ne devriez pas avoir trop de mal collecter ces informations.
Si ces outils sont utiliss au cours de lamorage du systme ( partir de /etc/inittab, par
exemple), vous devez les dsinstaller temporairement ou les dsactiver jusqu tre
certain quils fonctionnent correctement sur la nouvelle version.
Prinstallation de la CPU
Il est dconseill de modifier a priori les paramtres de planification par dfaut de la CPU
(tels que la dure des tranches horaires). A moins que vous nayez une grande exprience
en contrle et optimisation dune charge de travail similaire sur une configuration analogue,
ne modifiez pas ces paramtres pendant linstallation.
Pour des indications sur la post-installation, reportez-vous Contrle et optimisation de la
CPU.
Prinstallation de la mmoire
Si vous installez un systme de plus de 32 Mo, appel grer plus de cinq utilisateurs
simultanment, vous devez envisager daugmenter le niveau minimum de
multiprogrammation associ au mcanisme de contrle de charge mmoire VMM. Par
exemple, si vous estimez que, au bas mot, quatre des applications les plus gourmandes en
mmoire doivent pouvoir sexcuter simultanment, tout en laissant au moins 16 Mo pour le
systme dexploitation et 25 % de mmoire relle aux pages de fichiers, vous pouvez
augmenter le niveau minimum de multiprogrammation de 2 (par dfaut) 4, par la
commande :
# schedtune m 4
Ne procdez aucune autre modification de seuil de mmoire tant que vous navez pas
confront le systme la charge de travail relle.
Pour des indications sur la post-installation, reportez-vous Contrle et optimisation de la
mmoire.
4-23
Prinstallation du disque
Recommandations gnrales
Bien que les mcanismes de dfinition et dextension des volumes logiques adoptent les
valeurs par dfaut les plus satisfaisantes possibles, seul linstallateur du systme est
mme de dterminer la taille et lemplacement des volumes logiques, en fonction du volume
de donnes escompt et des contraintes de la charge de travail, pour des E/S optimises.
Dans cette optique, voici quelques recommandations utiles :
Si possible, le groupe de volumes par dfaut, rootvg, ne doit tre constitu que du
volume physique sur lequel le systme a t initialement install. Un ou plusieurs autres
groupes de volumes doivent tre dfinis pour contrler les autres volumes physiques du
systme. Ces mesures sont utiles tant au niveau de la gestion que des performances.
Pour amliorer les performances dun groupe de volumes comportant plusieurs volumes
physiques, vous pouvez :
Dfinir initialement le groupe de volumes avec un seul volume physique.
Dfinir un volume logique au sein du nouveau groupe de volume. Le volume logique
journal du groupe de volumes est alors affect sur le premier volume physique.
Ajouter les volumes physiques restants au groupe de volumes.
Dfinir les systmes de fichiers trs sollicits sur les nouveaux volumes physiques.
Dfinir exclusivement les systmes de fichiers de trs faible activit, sil en existe, sur
le volume physique contenant le volume logique du journal.
Cette solution spare les E/S de journalisation des E/S trs importantes de donnes,
augmentant la probabilit de chevauchement. Cette technique peut avoir un effet
particulirement marqu sur les performances du serveur NFS car lcriture des
donnes et du journal doit tre acheve avant que NFS ne dclare les E/S termines
pour une opration dcriture.
Attribuez ds que possible aux volumes logiques leur taille maximale escompte.
Par prcaution, traitez en premier les volumes logiques les plus importants en terme de
performances pour tre sr quils seront contigus et affects lemplacement souhait.
Les volumes logiques trs sollicits doivent occuper des portions de plusieurs units de
disque. Si loption Gamme de volumes physiques du menu smit Ajout volume logique
(raccourci smit mklv) est positionn sur maximum, le nouveau volume logique sera
rparti sur les divers volumes physiques du groupe de volumes (ou du moins, le lot de
volumes physiques explicitement spcifi).
Si le systme est quip dunits de diffrents types (ou que vous devez dterminer
lunit commander), les remarques suivantes vous seront utiles :
Les gros fichiers normalement accessibles squentiellement doivent tre installs sur
lunit de disque la plus rapidement disponible. Les niveaux de performances en
accs alatoires et squentiels mesurs sont, du plus lent au plus rapide :
4-24
Drive
Capacity
200MB
400MB
857MB
2.4GB
1.37GB
540MB
1.0GB**
2.0GB
SCSI
Adapter
Model 250 Integrated

SCSI II
SCSI II
SCSI II
SCSI II
SCSI II
SCSI II
SCSI II
Random Pages
per Second
approx. 40
approx. 50
approx. 60
approx. 65*
approx. 70
approx. 85
approx. 85
approx. 85
Sequential Pages
per Second
approx. 250
approx. 375
approx. 550
approx. 525
approx. 800
approx. 975
approx. 1075
approx. 950
* par accs (deux en tout)

** Cette unit de 1 Go (rfrence 45G9464) remplace lancienne
unit de 1 Go (rfrence 55F5206) depuis fin 1993.
Remarque : Ces chiffres rsultent de mesures effectues en laboratoire dans des
conditions idales. Ils constituent la synthse de diffrentes mesures, et non les rsultat
dun seul essai comparatif. Nous vous les indiquons pour vous donner une ide gnrale
des vitesses relatives des units de disque. Ils sont appel voluer avec les
amliorations apportes aux units, aux cartes et au logiciel.
Si des accs squentiels frquents sont prvoir sur les gros fichiers installs sur les
units de disques les plus rapides, il est conseill de limiter le nombre de pilotes de
disque par carte disque. Nous prconisons pour les units de 540 Mo, 1 Go et 2 Go :
Disk Adapter
Original ESCALA SCSI adapter

SCSI2 High Performance Controller
SCSI2 Fast Adapter (8bit)
SCSI2 Fast/Wide Adapter (16bit)
Disk Drives
per Adapter
1
2
2
3
Chaque fois que possible, raccordez les units exigeant des performances trs
leves une carte SCSI-2. Ce type de carte offre des fonctionnalits, telles que
lcriture dos dos, que les autres cartes disque du ESCALA ne proposent pas.
Sur les units de disque 200 Mo, 540 Mo et 1 Go, les volumes logiques appels
recevoir des fichiers squentiels frquemment sollicits doivent tre affects sur le
bord externe du volume physique. Ces disques ont davantage de blocs par piste dans
leur section externe, ce qui amliore les performances des oprations squentielles.
Sur un bus SCSI, les units dotes des adresses SCSI les plus leves (telles que
dfinies sur les units physiques) sont prioritaires. Le plus souvent, cet effet est
ngligeable, mais les oprations squentielles portant sur des fichiers volumineux sont
connues pour exclure de laccs au bus les units dotes dun petit numro. Vous
devrez probablement configurer les units de disque contenant les donnes les plus
critiques en matire de temps de rponse aux adresses les plus leves de chaque
bus SCSI. La commande lsdev Cs scsi porte sur les affectations dadresses
actuelles sur chaque bus SCSI. Pour la carte SCSI dorigine, ladresse SCSI est le
premier nombre de la quadruple paire de nombres de la sortie. Dans lexemple
ci-dessus, le disque de 400 Mo rside ladresse SCSI 0, le disque de 320 Mo,
ladresse 1, et lunit de bande 8 mm, ladresse 5.
hdisk0
hdisk1
rmt0
Available 00010000 400 MB SCSI Disk Drive

Available 00010010 320 MB SCSI Disk Drive
Defined
00010050 2.3 GB 8mm Tape Drive
Les gros fichiers trs utiliss et gnralement ouverts en mode alatoire (tels que les
bases de donnes) doivent tre rpartis sur plusieurs volumes physiques.
4-25
Pour des indications sur la post-installation, reportez-vous Contrle et optimisation des

E/S disque, page 8-1.
Position et taille des espaces de pagination

En rgle gnrale, la taille cumule des espaces de pagination doit tre au moins double de
celle de la mmoire relle (256 Mo maximum, soit 512 Mo despace de pagination). Pour
les mmoires suprieures 256 Mo, la taille recommande est :
espace de pagination total
= 512 Mo + (taille mmoire 256 Mo) * 1,25
Lidal est de disposer de plusieurs espaces de pagination de taille grosso modo
quivalentes, implants sur des units de disque physiques distinctes. Si vous souhaitez
ajouter des espaces de pagination, crez-les sur des volumes physiques moins chargs
que le volume physique du groupe rootvg. VMM affecte alors quatre blocs de pagination en
mode RR (rpartition par permutation circulaire), issus des espaces de pagination actifs
disposant despace. Lors de lamorage du systme, seul lespace de pagination principal
(hd6) est actif. En consquence, tous les blocs despace de pagination affects pendant
lamorage se trouvent sur lespace de pagination principal. Ce qui signifie que lespace de
pagination principal doit tre quelque peu plus vaste que les espaces de pagination
secondaires. Pour un bon fonctionnement de lalgorithme de rpartition par permutation
circulaire, les espaces de pagination secondaires doivent tre de mme taille.
La commande lsps a donne un instantan du niveau dutilisation courant de tous les
espaces de pagination dun systme. La sous-routine psdanger() peut galement tre
utilise pour dterminer les niveaux critiques dutilisation de lespace de pagination. Dans
lexemple ci-dessous, le programme utilise psdanger() pour afficher un message
davertissement au-del dune certaine limite :
/* psmonitor.c
Monitors system for paging space low conditions. When the condition is
detected, writes a message to stderr.
Usage:
psmonitor [Interval [Count]]
Default: psmonitor 1 1000000
*/
#include <stdio.h>
#include <signal.h>
main(int argc,char **argv)
{
int interval = 1;
/* seconds */
int count = 1000000;
/* intervals */
int current;
/* interval */
int last;
/* check */
int kill_offset;
/* returned by psdanger() */
int danger_offset;
/* returned by psdanger() */
4-26
/* are there any parameters at all? */

if (argc > 1) {
if ( (interval = atoi(argv[1])) < 1 ) {
fprintf(stderr,Usage: psmonitor [ interval [ count ] ]\n);
exit(1);
}
if (argc > 2) {
if ( (count = atoi( argv[2])) < 1 ) {
fprintf(stderr,Usage: psmonitor [ interval [ count ] ]\n);
exit(1);
}
}
}
last = count 1;
for(current = 0; current < count; current++) {
kill_offset = psdanger(SIGKILL); /* check for out of paging space */
if (kill_offset < 0)
fprintf(stderr,
OUT OF PAGING SPACE! %d blocks beyond SIGKILL threshold.\n,
kill_offset*(1));
else {
danger_offset = psdanger(SIGDANGER); /* check for paging space low
*/
if (danger_offset < 0) {
fprintf(stderr,
WARNING: paging space low. %d blocks beyond SIGDANGER
threshold.\n,
danger_offset*(1));
fprintf(stderr,
%d blocks below SIGKILL

threshold.\n,
kill_offset);
}
}
if (current < last)
sleep(interval);
}
}
Mise en miroir et performances

Si la fonction miroir est utilise avec loption Mirror Write Consistency active (par dfaut),
vous devrez certainement installer les copies dans la rgion externe du disque, les
informations de Mirror Write Consistency tant toujours inscrites sur le cylindre 0. La mise
en miroir simple est coteuse en terme de performances, elle lest davantage encore
assortie de loption Write Verify (une rotation disque supplmentaire par criture) et plus
encore assortie des deux options Write Verify et Mirror Write Consistency (une rotation
disque plus une recherche sur le cylindre 0). Pour viter toute confusion, rappelons que
bien quune commande lslv signale que loption Mirror Write Consistency est active pour
les volumes logiques non miroir, aucun traitement nest effectu si la valeur de COPIES
nest pas suprieure 1. Loption Write Verify est, quant elle, dsactive par dfaut car
elle na pas de signification (donc dincidence) sur les volumes logiques non miroir.
Prinstallation des cartes de communication

Consultez le Rcapitulatif des paramtres doptimisation dUDP, TCP/IP et mbuf,
page 9-31.
4-27
4-28
Chapitre 5. Contrle systme et diagnostics des

performances
Ce chapitre dcrit les outils et techniques de contrle des performances du systme.

Les sections traites sont les suivantes :
Contrle continu des performances
Commandes de contrle iostat, netstat et vmstat
Utilitaire de diagnostic des performances
Diagnostics en fonction dun symptme particulier
Diagnostics laide de PerfPMR
Identification des ressources limitatives
Gestion de la charge de travail.
Contrle systme et diagnostics des performances
5-1
Contrle continu des performances

Sur certaines installations, le contrle des performances seffectue la demande :
lorsquune anomalie de performances est releve, lanalyste lance une ou plusieurs
commandes pour dterminer lorigine de lincident. Dans dautres cas, il est ncessaire de
recrer explicitement le problme pour collecter des donnes danalyse. Le rsultat est que
les utilisateurs se heurtent deux fois au mme problme de performance.
Il est souvent plus efficace dexercer un contrle en continu, de prfrence avec relev
automatique de donnes supplmentaires en cas de dgradation des performances. Les
avantages du contrle continu en compensent largement le cot.
En effet, un tel contrle permet de : Dtecter les anomalies naissantes avant quelles ne
fassent sentir leurs effets.
Dtecter les incidents non signals par les utilisateurs (rticents effectuer cette
dmarche ou jugeant lincident suffisamment mineur), mais qui affectent leur productivit
et leur moral.
Collecter les donnes gnres ds la premire apparition de lincident.
Un contrle efficace suppose les cinq oprations suivantes :
Relev priodique des informations de performances fournies par le systme
dexploitation.
Stockage des informations pour les diagnostics futurs.
Communication des informations ladministrateur systme.
Analyse plus approfondie des situations juges critiques ou la demande de
ladministrateur systme.
Collecte et stockage des donnes dtailles utiles.
Les sections qui suivent prsentent plusieurs mthodes de contrle continu. Ces diffrentes
approches ne sont pas incompatibles, mais les utiliser conjointement serait redondant.
Utilitaire de diagnostic des performances
5-2

Certaines caractristiques fonctionnelles des commandes iostat, netstat et vmstat
peuvent tre avantageusement exploites pour le contrle continu des performances :
Comptes rendus un intervalle fixe sans limitation de dure.
Rapports dactivit lors des variations lies diffrents types de charge.
Comptes rendus dactivit depuis le dernier rapport, facilitant la dtection des
changements intervenus.
Voici des extraits de comptes rendus priodiques gnrs par ces commandes :
$ iostat 5 2
tty:
tin
0.0
Disks:
hdisk0
cd0
tty:
Disks:
hdisk0
cd0
tout
0.0
% tm_act
0.1
0.0
tin
0.0
tout
0.0
% tm_act
2.4
0.0
cpu:
% user
0.0
% sys
0.2
% idle
99.6
tps
0.0
0.0
Kb_read
18129
0
Kb_wrtn
56842
0
% user
23.1
% sys
9.0
% idle
65.9
Kb_read
0
0
Kb_wrtn
32
0
Kbps
0.3
0.0
cpu:
Kbps
6.4
0.0
tps
1.6
0.0
% iowait
0.1
% iowait
2.0
$ vmstat 5 2
procs
memory
page
faults
cpu

r b
avm
fre re pi po fr
sr cy in
sy cs us sy id wa
0 0 2610 1128
0
0
0
0
0
0 112
1 19 0 0 99 0
0 0 2505 1247
0
0
0
0
0
0 125 1056 37 22 9 67 2
$ netstat I tr0 5
input
(tr0)
output
532099 1664
985
0
0
45
0
6
0
0
44
1
5
0
0
input
packets
532111
45
44
(Total)
output
errs packets errs colls
1664
997
0
0
0
6
0
0
1
5
0
0
Le premier compte rendu gnr par chacune de ces commandes concerne lactivit
cumule depuis le dernier amorage du systme. Le second compte rendu montre lactivit
enregistre durant le premier intervalle de 5 secondes. De ce simple extrait, il ressort que
lactivit enregistre au cours du premier intervalle a t sensiblement suprieure la
moyenne.
Ces commandes sont la base du mcanisme de contrle. Les scripts shell peuvent tre
crits pour rduire les donnes gnres par la commande *stat, signaler les problmes de
performances ou enregistrer les donnes concernant ltat du systme au moment de
lincident. Par exemple, un script shell peut tester le pourcentage de CPU disponible, et
lorsquil dtecte un pourcentage gal 0 signifiant que la CPU est sature, excuter un
autre script shell. Par exemple :
$ ps ef | egrep v STIME|$LOGNAME | sort +3 r | head n 15
Ce script enregistre les 15 processus actifs (autres que les processus de lutilisateur du
script) qui ont rcemment consomm le plus de temps CPU.
Selon le niveau de sophistication requis, laborer un ensemble de scripts shell peut savrer
difficile. Fort heureusement, il existe des modules moins exigeants en dveloppement et
configuration qui offrent bien plus de fonctions que la plupart des installations nen
requirent localement.
Contrle systme et diagnostics des performances
5-3
5-4
Chapitre 6. Contrle et optimisation de la CPU
Lunit centrale dun ESCALA est lun des composants les plus rapides du systme : il est
rarissime quun programme monopolise 100 % de la CPU au-del de quelques secondes.
Mme sur des systmes multiutilisateurs trs chargs, il arrive quau bout dune priode de
10 ms tous les travaux soient en attente. Si un message indique que la CPU est occupe
100 % (0 % disponible et 0 % dattente) depuis un certain temps, il est fort probable quun
programme se trouve engag dans une boucle infinie. Dans ce cas, si le programme en
cause est simplement coteux, mais tout fait exploitable, il convient de lidentifier et de lui
appliquer un traitement ad hoc.
Ce chapitre indique comment dtecter les programmes incontrls, ou faisant un usage
intensif de CPU, et rduire leur impact sur les performances.
Si vous tes peu familiaris avec la programmation de la CPU sous AIX, reportez-vous
Performances du programmateur CPU sous AIX, page 2-2, avant de poursuivre.
Contrle de la CPU via vmstat
Mesure de la CPU via time
Identification des grands consommateurs de CPU via ps
Analyse des programmes via tprof
Analyse du flux de commande via stem
Restructuration des excutables via fdpr
Contrle des conflits pour la CPU
Modification de la tranche horaire du programmateur
Administration de lID utilisateur par rapport la CPU
Loutil xmperf est galement trs utile pour contrler lutilisation de la CPU.
6-1
Contrle de la CPU via vmstat

Comme contrleur de CPU, vmstat est plus pratique utiliser que iostat. Chaque relev
est prsent sur une ligne distincte, ce qui en facilite la lecture. vmstat propose galement
des informations dordre gnral sur lutilisation de la mmoire, la pagination et les E/S
disque ordinaires. Lexemple qui suit indique comment interprter la sortie, et notamment
identifier les conditions demballement dun programme ou de carence en CPU en
environnement multiutilisateur.
$ vmstat 2
procs
memory
page
faults

r b
avm
fre re pi po fr
sr cy in
sy cs
1 0 22478 1677
0
0
0
0
0
0 188 1380 157
1 0 22506 1609
0
0
0
0
0
0 214 1476 186
0 0 22498 1582
0
0
0
0
0
0 248 1470 226
cpu
us sy id wa
57 32 0 10
48 37 0 16
55 36 0 9
2
2
2
3
2
0
0
0
0
1
22534
22534
22534
22534
22557
1465
1445
1426
1410
1365
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
238 903 239 77 23

209 1142 205 72 28
189 1220 212 74 26
255 1704 268 70 30
383 977 216 72 28
2
1
1
0 22541
0 22524
0 22546
1356
1350
1293
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 237 1418 209 63 33

0 241 1348 179 52 32
0 217 1473 180 51 35
0
0
0
0
0
0
0
0
0
0
0 4
0 16
0 14
Cette sortie met en vidence limpact dun programme en boucle dans un environnement
multiutilisateur. Il ressort des trois premiers relevs (le rsum ayant t supprim) que
lquilibre du systme pour lutilisation de la CPU se situe 5055 % ct utilisateur,
3035 % ct systme et 1015 % en attente dE/S. Ds le lancement du programme en
boucle, tous les cycles CPU disponibles sont utiliss. Aucune E/S ntant effectue dans
une boucle, tous les cycles non utiliss du fait de lattente des E/S sont alors exploits par le
programme. En fait, ce processus est capable de sapproprier la CPU de tout processus
utile qui sen dferait. Bnficiant du mme niveau de priorit que les autres processus
davant-plan, le processus nest pas contraint dabandonner de la CPU au profit dun autre
processus devenu diffusable. Son excution dure environ 10 secondes (5 relevs). Au-del,
lactivit du systme suit un cours plus normal.
6-2
Mesure de la CPU via time

La commande time est un outil simple mais efficace qui permet de mieux comprendre les
caractristiques de performances dun programme. time indique le temps coul entre le
dbut et la fin du programme (rubrique real). Elle indique galement le temps CPU utilis
par le programme. Le temps CPU est divis entre temps user et temps sys. La valeur
user correspond au temps utilis par le programme lui-mme et, le cas chant, par les
sous-routines de bibliothque quil appelle. La valeur sys correspond au temps utilis par
les appels systme effectus par le programme (directement ou indirectement).
La somme des valeurs user + sys correspond au cot CPU direct total de lexcution du
programme. Ce cot ninclut pas les cots CPU imputables aux portions du noyau
excutes pour le programme en dehors de sa routine. Par exemple, au lancement du
programme, les trames de page retires de la liste des disponibilits doivent tre
remplaces. La rcupration de trames de page cet effet reprsente un cot qui nest pas
englob dans la consommation CPU du programme.
La diffrence entre le temps CPU real et le temps CPU total :
real (user + sys)
correspond la somme de tous les facteurs susceptibles de retarder le programme, plus les
cots indtermins propres au programme. Ces facteurs sont, par ordre dimportance
dcroissante :
les E/S requises pour charger le texte et les donnes du programme,
les E/S requises pour acqurir la mmoire relle ncessaire lexploitation du
programme,
le temps CPU consomm par dautres programmes,
le temps CPU consomm par le systme dexploitation.
Dans lexemple qui suit, le programme prsent dans la section prcdente a t compil
avec loption O3 pour le rendre plus rapide. Lcart entre le temps rel dexcution du
programme et le temps CPU total (utilisateur et systme) est minime. Le programme
bnficie de tout le temps ncessaire, probablement au dtriment dautres programmes.
$ time looper
real
0m3.58s
user
0m3.16s
sys
0m0.04s
Dans lexemple suivant, le programme est excut avec une priorit moindre (valeur nice
augmente de 10). La dure de son excution est multiplie par 2, mais les autres
programmes ont lopportunit deffectuer leurs travaux :
$ time nice 10 looper
real
0m6.54s
user
0m3.17s
sys
0m0.03s
Notez que la commande nice a t insre dans la commande time, et non linverse. Si
vous entrez :
$ nice 10 time looper
cest la version /usr/bin/time de la commande time qui est utilise et non la nouvelle
version intgre ksh qui gnre un relev plus dtaill. Il en est de mme si vous
appelez time via une autre commande. Si la commande time est excute en premier,
vous obtenez la version intgre, sauf si vous spcifiez le nom qualifi complet de
/usr/bin/time. Si time est appel partir dune autre commande, vous obtenez
/usr/bin/time.
6-3
Conseils relatifs time et timex

Vous devez tenir compte de certaines contraintes lorsque vous utilisez time ou sa variante
timex :
Lutilisation des commandes /usr/bin/time et /usr/bin/timex est dconseille. Chaque
fois que possible, optez pour la sous-commande time du shell Korn ou C. Sous la
version 3.2.5, le temps CPU comptabilis par /usr/bin/time est incorrect lorsquil est li
lexploitation dun script shell renfermant des squences de commandes chanes par
des tubes : seule la dernire commande de la squence est comptabilise dans le temps
CPU, le reste est perdu. Cette erreur sexplique par le fait que /usr/bin/time utilise le
shell par dfaut du systme. Or le shell par dfaut de la version 3.2.5 est le shell Bourne,
lequel excute (commande exec) les squences de commandes de telle sorte que seule
la consommation CPU de la dernire commande peut tre mesure. En revanche, le
shell Korn (shell par dfaut dAIX version 4.1) ne prsente pas le mme inconvnient.
La commande timex s passe par sar pour obtenir des statistiques supplmentaires. sar
tant intrusive, timex s lest galement. Les donnes reportes par timex s,
notamment dans le cas dexcutions brves, risquent de ne pas reflter fidlement le
comportement dun programme excut sur un systme non contrl.
La dure dune impulsion dhorloge (10 millisecondes) et les rgles suivies par le
programmateur pour attribuer du temps CPU aux routines faussent lgrement le rsultat
de la commande time. Des variations se produisent immanquablement entre les
excutions successives. Ces variations sont dfinies en termes dimplulsions dhorloge.
Naturellement, ces variations sembleront dautant plus importante que le temps
dexcution du programme est court.
Il est dconseill dutiliser la commande time ou timex ( partir de /usr/bin ou par le
biais de la fonction time du shell intgr) pour mesurer le temps systme ou utilisateur
consomm par une squence de commandes chanes par des tubes et entres sur la
ligne de commande. En effet, si la commande time nest pas spcifie correctement, elle
peut ne mesurer quune seule commande de la squence. Il faut savoir par ailleurs que
lerreur nest pas signale, la syntaxe tant techniquement correcte.
6-4
Contrle de la CPU via xmperf

Le recours xmperf pour afficher lutilisation de la CPU dans le systme est encore plus
flagrant. Si vous affichez la CPU sous la forme dun graphique reprsentant une ligne
dhorizon en mouvement, et la CPU de lutilisateur en rouge vif, vous pourrez
immdiatement constater depuis lautre bout de la pice lemballement dun programme. La
commande xmperf est dcrite en dtail dans le manuel Performance Toolbox 1.2 and 2.1
for AIX: Users Guide.
6-5
Identification des gros consommateurs de CPU via ps

Le compte rendu fourni par la commande ps peut tre prsent dans trois colonnes
diffrentes :
Colonne
Valeur
Temps CPU rcemment utilis pour le processus.
TIME
Temps CPU total utilis par le processus depuis son lancement.
%CPU
Temps CPU total utilis par le processus depuis son lancement divis
par le temps coul depuis le lancement du processus. Mesure la
dpendance du programme vis--vis de la CPU.
Le script shell :
$ps ef | egrep v STIME|$LOGNAME | sort +3 r | head n 15
sert mettre en vidence les processus utilisateur du systme les plus gourmands en CPU.
Appliqu lexemple de la section Contrle de la CPU via vmstat, ce script gnrerait la
sortie suivante (la ligne den-tte a t ajoute pour faciliter la lecture) :
USER
waters
root
root
root
root
root
bick
bick
luc
PID
45742
52121
4250
38812
27036
47418
37651
43538
60061
PPID
C
STIME
TTY TIME CMD
54701 120 15:19:05 pts/29 0:02 ./looper
1 11 15:32:33 pts/31 58:39 xhogger
1
3 15:32:33 pts/31 26:03 xmconsole allcon
4250
1 15:32:34 pts/31 8:58 xmconstats 0 3 30
6864
1 15:18:35
0:00 rlogind
25925
0 17:04:26
0:00 coelogin <d29dbms:0>
43538
0 16:58:40 pts/4 0:00 /bin/ksh
1
0 16:58:38
0:07 aixterm
27036
0 15:18:35 pts/18 0:00 ksh
Lutilisation rcente de la CPU est donne la quatrime colonne (C). Le processus du

programme en boucle est en tte de la liste. Notez que la valeur fournie est probablement
sous-estime car au-del de 120 le programmateur sarrte de compter.
ps est un outil trs souple qui permet didentifier les programmes en cours sur le systme et
les ressources quils mobilisent. Les options et colonnes associes sont dcrites dans la
documentation de rfrence de ps, le manuel AIX Commands Reference.
Les indicateurs de ps relvent pour la plupart dune des catgories suivantes :
1. Indicateurs spcifiant les processus inclure dans la sortie.
2. Indicateurs spcifiant les informations afficher pour chaque processus.
Les tableaux ci-aprs rcapitulent les diffrents indicateurs de la commande ps et leurs
effets. Dans les deux tableaux, les indicateurs spcifis avec un signe moins sont situs
gauche et les autres, droite. Les deux groupes dindicateur sexcluent mutuellement : si le
premier est spcifi avec un signe moins, tous les autres indicateurs de la commande ps
doivent obligatoirement appartenir au groupe des indicateurs dots du signe moins.
6-6
Indicateurs de spcification de
processus :
G
Les processus
rpertoris sont :
Tous les processus
Non leaders du
groupe de
processus et non
associs un
terminal
Non leaders du
groupe de
processus
Processus non
noyau
Membres des
groupes de
processus spcifis
Processus noyau
Ceux spcifis
dans la liste des
numros de
processus
Ceux associs
avec les TTY dans
la liste
Y
(nTTYs)
(1 TTY)
Processus
utilisateur spcifis
Processus avec
terminaux
NON associs un
TTY
Spcifie sans indicateur, la commande ps sapplique par dfaut tous les processus de
lmetteur de cette commande ps.
Indicateurs de slection de
colonne
U
Colonne :
Default1 f
Default2 e
PID
TTY
TIME
CMD
USER
6-7
UID
PPID
STIME
S/STAT
PRI
NI/NICE
ADDR
SZ/SIZE
WCHAN
RSS
SSIZ
%CPU
%MEM
PGIN
LIM
TSIZ
TRS
environment
(suivant la
commande ; sans
en-tte de colonne)
Si ps est lance sans indicateurs ou avec un indicateur de spcification de processus

commenant par un signe moins, les colonnes saffichent comme celles illustres pour
Default1. Si la commande est assortie dun indicateur de spcification de processus ne
commenant pas par un signe moins, les colonnes correspondant Default2 sont affiches.
u ou U est la fois un indicateur de processus et de slection de colonne.
Voici une brve description du contenu des colonnes :
6-8
PID
ID processus
TTY
Terminal ou pseudo-terminal associ au processus.
TIME
Cumul du temps CPU consomm, en minutes et secondes.
CMD
Commande excute par la processus.
USER
Nom de connexion du propritaire du processus.
UID
ID utilisateur numrique du propritaire du processus.
PPID
ID du processus parent.
Temps CPU rcemment utilis.
STIME
Heure de dbut du processus (sil a t lanc le jour mme). Sinon,

date de dbut du processus.
Valeur hexadcimale de 8 caractres dcrivant les indicateurs associs

au processus (voir la description dtaille de la commande ps).
S/STAT
Etat du processus (voir la description dtaille de la commande ps).
PRI
Niveau de priorit courant du processus.
NI/NICE
Valeur nice du processus.
ADDR
Numro de segment de pile de processus.
SZ/SIZE
Nombre de pages de segments actifs touches, multipli par 4.
WCHAN
vnement attendu par le processus.
RSS
Cumul du nombre de pages de segments actifs et du nombre de pages

de segments de codes en mmoire, multipli par 4.
SSIZ
Taille de la pile du noyau.
%CPU
Taux dutilisation de la CPU par le processus depuis son lancement.
%MEM
Valeur RSS divise par la taille de la machine en ko, multiplie par 100
et arrondie au pourcentage le plus proche.
PGIN
Nombre de chargements de page conscutifs un dfaut de page.

quivaut approximativement au volume des E/S, toutes les E/S tant
comptabilises sous AIX comme des dfauts de page.
LIM
Limite sur la taille RSS. Affich xx si non dfinie.
TSIZ
Taille de la section de texte du fichier excutable.
TRS
Nombre de pages de segments de code, multipli par 4.
environnement
Valeur de toutes les variables denvironnement du processus.
6-9
Analyse des programmes via tprof

Lexcution dun programme est une combinaison variable de codes dapplication, de
bibliothques, de sous-routines et de services de noyau. Gnralement, un programme non
optimis utilise la plupart des cycles CPU qui lui sont impartis un nombre rduit
dinstructions ou de sous-routines. Ces zones critiques sont souvent inattendues pour la
personne charge de mettre le programme en application et peuvent tre considres
comme des anomalies de performances. Loutil prconis pour localiser les zones critiques
dun programme est le profileur tprof. tprof, fond sur la fonction de suivi, est capable de
profiler un programme (analyser son excution) gnr par un des compilateurs XL
suivants : XL C, XL C++, XL FORTRAN.
Sous AIX version 4.1, le programme tprof est intgr la bote outils PTX (Performance
Toolbox for AIX). Pour savoir si tprof est disponible, entrez :
lslpp lI perfagent.tools
Si ce module est install, tprof est disponible.
Les donnes brutes de tprof sont obtenues par la fonction de suivi (reportez-vous au
chapitre Analyse des performances avec lutilitaire de suivi, page 11-1). Lorsquun
programme est profil, lutilitaire de suivi est activ et charg de recueillir les donnes du
point dancrage du suivi (ID 234) qui enregistre le contenu du registre dadresse
dinstruction (IAR) chaque interruption dhorloge systme (100 fois par seconde).
Plusieurs autres points dancrage sont galement activs pour permettre tprof de suivre
le processus et de diffuser lactivit. Les enregistrements de suivi ne sont pas inscrits dans
un fichier disque mais vers un tube. Un programme lit le contenu du tube et construit une
table avec les adresses de programme uniques rencontres et leur nombre doccurrences.
Cette table est copie sur le disque lorsque toute la charge de travail a t traite. Le
composant charg de la rduction des donnes dans tprof fait la corrlation entre les
adresses dinstruction rencontres et les intervalles dadresses occups par les
programmes. Puis, il diffuse les occurrences dadresses (impulsions dhorloge) parmi les
programmes impliqus dans la charge.
La diffusion des impulsions dhorloge est globalement proportionnelle au temps CPU utilis
sur chaque programme (10 millisecondes par impulsion). Lorsque les programmes
fortement sollicits ont t identifis, le programmeur peut prendre les mesures qui
simposent pour restructurer les zones critiques ou minimiser leur usage.
Exemple thorique
Le programme C suivant initialise 0x01 chaque octet dun grand tableau de nombres
entiers, incrmente chaque entier (int) dune constante alatoire et envoie en sortie un
entier (int) dsign alatoirement. Le programme ne remplit pas de fonction particulire,
mais il est reprsentatif des programmes qui traitent de grands tableaux.
6-10
/* Array Incrementer Version 1 */

#include <stdlib.h>
#define Asize 1024
#define RowDim InnerIndex
#define ColDim OuterIndex
main()
{
int Increment;
int OuterIndex;
int InnerIndex;
int big [Asize][Asize];
/* initialize every byte of the array to 0x01 */
for(OuterIndex=0; OuterIndex<Asize; OuterIndex++)
{
for (InnerIndex=0; InnerIndex<Asize; InnerIndex++)
big[RowDim][ColDim] = 0x01010101;
}
Increment = rand();
/* increment every element in the array */
{
{
big[RowDim][ColDim] += Increment;
if (big[RowDim][ColDim] < 0)
printf(Negative number. %d\n,big[RowDim][ColDim]);
}
}
printf(Version 1 Check Num: %d\n,
big[rand()%Asize][rand()%Asize]);
return(0);
}
Ce programme a t compil par la commande :
$ xlc g version1.c o version1
Le paramtre g commande au compilateur XL C de gnrer le module objet avec des
informations de mise au point symboliques destines tprof. Bien que tprof soit capable
de profiler des modules optimiss, nous avons omis de spcifier le paramtre O pour
prciser les numros de ligne utiliss par tprof. Lors de loptimisation, le compilateur XL C
rorganise gnralement les codes si bien que linterprtation de la sortie de tprof est plus
difficile. Sur le systme test, ce programme mobilise environ 5,97 secondes, dont plus de
5,9 secondes de temps CPU utilisateur. Le programme remplit donc parfaitement son
objectif : tre limit en temps CPU.
Appliquer au programme la commande tprof comme suit :
$ tprof p version1 x version1
gnre un fichier __version1.all (voir ci-dessous) qui indique le nombre dimpulsions
CPU consommes par chaque programme impliqu dans lexcution.
6-11
Process
PID
=======
===
version1 33570480
bsh 33566383
/etc/init
1
/etc/syncd
3059
tprof
5038
rlogind
11345
PID.771
771
tprof
11940
tprof
11951
tprof
13987
bsh
16048
=======
===
Total
Total
=====
793
8
6
5
4
2
1
1
1
1
1
=====
823
Kernel
======
30
8
0
5
2
2
1
1
1
1
1
======
52
User
====
763
0
6
0
2
0
0
0
0
0
0
====
771
Shared
======
0
0
0
0
0
0
0
0
0
0
0
======
0
Other
=====
0
0
0
0
0
0
0
0
0
0
0
=====
0
Process
=======
version1
bsh
/etc/init
/etc/syncd
tprof
rlogind
PID.771
=======
Total
Total
=====
793
9
6
5
7
2
1
=====
823
Kernel
======
30
9
0
5
5
2
1
======
52
User
====
763
0
6
0
2
0
0
====
771
Shared
======
0
0
0
0
0
0
0
======
0
Other
=====
0
0
0
0
0
0
0
=====
0
FREQ
===
1
2
1
1
4
1
1
===
11
Total Ticks For version1(

Subroutine
=============
.main
Ticks
======
763
USER) =
%
======
92.7
763
Source
=======
version1.c
Address
=======
632
Bytes
=====
560
La premire section du relev indique le nombre dimpulsions consommes par chaque

processus (ou qui lui sont imputables). Le programme version1 a utilis 763 impulsions
parmi lesquelles 30 se sont droules dans le noyau mais sont imputes version1.
Deux processus excutant le shell Bourne sont impliqus dans lexcution de version1.
Quatre processus ont excut des codes lis tprof. Le processus init, le dmon sync, un
processus rlogin et un autre processus reprsentent 14 impulsions.
Rappelons que le programme associ un ID processus numrique donn change
chaque appel exec. Si un programme dapplication en excute (exec) un autre, le nom des
deux programmes apparat dans la sortie de tprof associe au mme ID processus.
La seconde section du rapport rcapitule les rsultats par programme, indpendamment de
lID processus. Elle indique le nombre (FREQ) de processus distincts susceptibles
datteindre chaque programme un point donn.
La troisime section analyse les impulsions dhorloge utilisateur associes au programme
excutable profil. Lanalyse indique le nombre dimpulsions utilises par chaque fonction
de lexcutable et le pourcentage que ce nombre reprsente sur le total des impulsions
CPU produites lors de lexcution (823).
Jusque l, aucune opration tprof na fait appel la version compile spciale du
programme : la mme analyse aurait pu tre effectue sur un programme dont le code
source est inaccessible.
Il ressort clairement de ce relev que le programme lui-mme est le plus grand
consommateur de temps CPU (92,7 %), et non le noyau ou les sous-routines de
bibliothques du programme. Etudions-le de plus prs.
La compilation de version1.c ayant t faite avec loption g, le fichier objet comprend
des informations qui associent les dcalages du texte du programme aux lignes du code
source. Par consquent, tprof a cr une version annote du fichier source version1.c,
appele __t.version1.c, base sur les dcalages et les informations relatives aux
numros de ligne dans le module objet. La premire colonne reporte le numro de ligne.
6-12
La seconde comptabilise le nombre de fois o le point dancrage a signal les interruptions

de lhorloge alors que le systme excutait lune des instructions associes cette ligne.
Ticks Profile for main in version1.c
Line
Ticks
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
34
40
261
70
69
50
239
29
30
31
32
33
34
Source
{
big[RowDim][ColDim] = 0x01010101;
}
Increment = rand();
/* increment every element in the array */
{
{
printf(Negative number.%d\n,
big[RowDim][ColDim]);
}
}
return(0);
}
763 Total Ticks for main in version1.c
Ce compte rendu montre clairement que le plus grand nombre dimpulsions est associ
laccs aux lments du tableau big, et nous permet doptimiser les performances en nous
concentrant sur les boucles internes for. La premire boucle for (initialisation) est un
exemple de programmation sauvage : il est totalement inefficace dinitialiser les lments
des tableaux les uns aprs les autres. Sil sagissait de mettre le tableau 0, nous aurions
d utiliser bzero. Dans la mesure o il sagit de donner chaque bit la valeur dun caractre
spcifique, nous allons utiliser memset pour remplacer la premire boucle for.
(les fonctions bzero et memset sont trs efficaces, tout comme les fonctions str : crites en
assembleur, elles exploitent des instructions matrielles qui nont pas dquivalent direct
en C).
Nous devons accder successivement aux lments du tableau pour les incrmenter, mais
en nous assurant que le schma de la rfrence mmoire se rapporte des adresses
conscutives pour optimiser lutilisation du cache. Ici, les dimensions des ranges sont
modifies plus rapidement que celles des colonnes. Les tableaux C tant structurs sur la
base des ranges, nous omettons une range complte chaque rfrence mmoire.
La longueur des ranges tant de 1 024 entiers int (4 096 octets), nous changeons de
page chaque rfrence. La taille du tableau dpassant largement les possibilits du cache
de donnes et du TLB de donnes, nous avons crit un programme qui accepte le
maximum de cache et de TLB. Pour ce faire, nous avons simplement transpos les
instructions #define pour inverser les valeurs de RowDim et ColDim.
La forme non optimise de ce programme (version2.c) consomme environ 2,7 secondes
de temps CPU, comparer aux 7,9 secondes pour version1.
Le fichier suivant, __t.version2.c, rsulte dune commande tprof applique la forme
non optimise du programme :
6-13
Ticks Profile for main in version2.c

Line
Ticks
Source
15
memset(big,0x01,sizeof(big));
16
Increment = rand();
17
18
/* increment in memory order */

19
60
20
{
21

22
{
23
67
24
60
25
43
printf(Negative number.
%d\n,big[RowDim][ColDim]);
26
}
27
}
28

29
30
return(0);
31
}
230 Total Ticks for main in version2.c
En tant attentif au schma dutilisation du temps CPU, nous avons multipli la vitesse CPU
du programme non optimis par trois. Les performances sont multiplies par 7 si
version1.c et version2.c sont optimiss avant compilation.
Lutilisation de la CPU par un programme intervient principalement dans les sous-routines
de bibliothque quil utilise et non dans le programme lui-mme. Si, dans version2.c, le
test conditionnel de la ligne 24 et lentre printf de la ligne 28 sont supprims pour crer
la version3.c suivante :
#include <string.h>
#include <stdlib.h>
#define Asize 256
#define RowDim OuterIndex
#define ColDim InnerIndex
main()
{
int Increment;
int OuterIndex;
int InnerIndex;
int big [Asize][Asize];
/* Initialize every byte to 0x01 */
memset(big,0x01,sizeof(big));
Increment = rand();
/* increment in memory order */
{
{
printf(RowDim=%d, ColDim=%d, Number=%d\n,
RowDim, ColDim, big[RowDim][ColDim]);
}
}
return(0);
}
le temps dexcution est essentiellement imputable linstruction printf. La commande :
$ tprof v s k p version3 x version3 >/dev/null
6-14
gnre une __version3.all qui comprend les donnes de profilage pour le noyau et la
bibliothque de sous-routine partage libc.a (seule bibliothque utilise par ce
programme) :
Process
PID
=======
===
version3 33568373
bsh 33567348
tprof
15987
tprof
7784
tprof
12905
bsh
13941
=======
===
Total
Total
=====
818
5
3
1
1
1
=====
829
Kernel
======
30
5
1
1
1
1
======
39
User
====
19
0
2
0
0
0
====
21
Shared
======
769
0
0
0
0
0
======
769
Other
=====
0
0
0
0
0
0
=====
0
Process
=======
version3
bsh
tprof
=======
Total
Total
=====
818
6
5
=====
829
Kernel
======
30
6
3
======
39
User
====
19
0
2
====
21
Shared
======
769
0
0
======
769
Other
=====
0
0
0
=====
0
FREQ
===
1
2
3
===
6

Subroutine
=============
.main
.printf
USER) =
Ticks
======
11
8

Subroutine
=============
.sc_flih
.i_enable
.vmcopyin
.xix_setattr
.isreadonly
.lockl
.v_pagein
.curtime
.trchook
.vmvcs
.spec_rdwr
.rdwr
.imark
.nodev
.ld_findfp
%
======
1.3
1.0
KERNEL) =
Ticks
======
7
5
3
2
2
2
1
1
1
1
1
1
1
1
1
%
======
0.8
0.6
0.4
0.2
0.2
0.2
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
0.1
Total Ticks For version3( SHLIBs) =

Shared Object
=============
libc.a/shr.o
Ticks
======
769
Profile: /usr/lib/libc.a
%
======
92.0
19
Source
=======
version3.c
glink.s
Bytes
=====
320
36
Address
=======
13832
21760
414280
819368
689016
29300
372288
27656
48168
29744
629596
658460
672024
135864
736084
Bytes
=====
1244
256
668
672
60
208
1044
76
856
2304
240
492
184
32
240
30
Source
=======
low.s
low.s
vmmove.c
xix_sattr.c
disubs.c
lockl.s
v_getsubs1.c
clock.s
noname
vmvcs.s
spec_vnops.c
rdwr.c
isubs.c
devsw_pin.c
ld_libld.c
769
Source
=======
/usr/lib
Address Bytes
======= =====
794624 724772
shr.o
Total Ticks For version3(/usr/lib/libc.a) =

Subroutine
=============
._doprnt
.fwrite
.strchr
.printf
._moveeq
.strlen
.isatty
._xwrite
.__ioctl
Address
=======
632
1112
Ticks
======
476
205
41
18
16
10
1
1
1
%
======
56.9
24.5
4.9
2.2
1.9
1.2
0.1
0.1
0.1
769
Source
=======
doprnt.c
fwrite.c
strchr.s
printf.c
memcmp.s
strerror.c
isatty.c
flsbuf.c
ioctl.c
Address
=======
36616
50748
31896
313796
36192
46800
62932
4240
57576
Bytes
=====
7052
744
196
144
184
124
112
280
240
6-15
Ce qui confirme que les impulsions sont majoritairement imputables aux bibliothques
partages libc.a, ici. Le profil de libc.a indique que la plupart de ces impulsions sont
imputables la sous-routine _doprnt.
_doprnt est le module de traitement de printf, sprintf, etc. Avec une simple modification,
nous avons augment le temps de traitement de 2,7 8,6 secondes, et notre impression
formate consomme prsent environ 60 % du temps CPU. Ceci explique pourquoi le
formatage doit tre employ judicieusement. Les performances de _doprnt sont
galement affectes par lenvironnement local. Reportezvous lannexe I, Support NLS
local et vitesse. Ces tests ont t effectus dans lenvironnement local C, le plus efficace.
6-16
Analyse du flux de commande via stem

Le module dinstrumentation stem peut suivre le flux de commande grce une gamme
varie de logiciels. Sous AIX version 4.1, cet outil fait partie de la bote outils Performance
Toolbox for AIX. Pour savoir si stem est disponible, entrez :
Si ce module est install, stem est disponible.
Les avantages les plus significatifs de stem sont :
stem peut instrumenter des programmes dapplication :
limits,
optimiss,
en multitraitement,
dans des bibliothques partages non limites.
les sousroutines dinstrumentation dentre et de sortie stem peuvent tre :
fournies par stem,
fournies par lutilisateur.
stem cre des versions instrumentes des programmes et des bibliothques requises, et
les stocke dans le rpertoire /tmp/EXE. Lorsque lutilisateur exploite ces programmes
instruments, stem cre un fichier correspondant appel stem_out.
Analyse de stem
Pour analyser le flux de commande dun simple programme dapplication, entrez :
stem p stem_test_pgm
La sortie de cette commande est :
**********************************************************
Make.Stem does not exist, issueing make for stem_samples.o
make stem_samples.o
Target stem_samples.o is up to date.
******************************************************
The instrumented stem_test_pgm is at /tmp/EXE/stem_test_pgm
Assuming version 3.2.5 or later, SVC_string=.sc_flih
Linstrumentation de stem_test_pgm a abouti, bien que le programme ait t limit. La
forme instrumente du programme rside dans le rpertoire /tmp/EXE. Entrez ensuite :
/tmp/EXE/stem_test_pgm
6-17
Vous obtenez un fichier appel stem_out dans le rpertoire de travail courant. Dans ce cas,
stem_out contient :
Seconds.usecs TID Routine Names & Seconds.usecs since
entering routine.
767549539.847704
1 >main
767549539.880523
1
>setPI
767549539.880958
1
<setPI 0.000435
767549539.881244
1
>squareit
767549539.881515
1
<squareit 0.000271
767549539.881793
1
>printf
767549539.883316
1
<printf 0.001523
767549539.883671
1
>setPI
767549539.883944
1
<setPI 0.000273
767549539.884221
1
>squareit
767549539.884494
1
<squareit 0.000273
767549539.884772
1
>printf
767549539.885981
1
<printf 0.001209
767549539.886330
1 <main 0.038626
767549539.886647
1
>exit
Le graphique dappel capture les appels dirigs vers les fonctions du module (setPI et
squareit) et vers la sousroutine printf de libc.a. Les numros droite des noms des
sousroutines reprsentent le temps coul (en secondes et microsecondes) entre lappel
et la rponse.
Si le mme processus est excut sur la commande wc (/usr/bin/wc), le fichier stem_out
contient alors (pour wc dun fichier compos de deux mots) :
Seconds.usecs TID Routine Names & Seconds.usecs since
entering routine.
767548812.962031
1 >main
767548812.993952
1
>setlocale
767548812.995065
1
<setlocale 0.001113
767548812.995337
1
>catopen
767548812.995554
1
<catopen 0.000217
767548812.995762
1
>getopt
767548812.996101
1
<getopt 0.000339
767548812.996345
1
>open
767548812.996709
1
<open 0.000364
767548812.996953
1
>read
767548812.997209
1
<read 0.000256
767548812.997417
1
>read
767548812.997654
1
<read 0.000237
767548812.997859
1
>wcp
767548812.998113
1
>printf
767548812.998586
1
<printf 0.000473
767548812.998834
1
<wcp 0.000975
767548812.999041
1
>printf
767548813.000439
1
<printf 0.001398
767548813.000720
1
>close
767548813.000993
1
<close 0.000273
767548813.001284
1
>exit
Ce graphique dappel, obtenu assez facilement, illustre la structure dune commande AIX.
Les appels destination de setlocale et catopen assurent que la commande se droule
dans le mme environnement local NLS (National Language Support) et avec le mme
catalogue de messages que son processus pre.
Bien que les programmes stem puissent sexcuter dans plusieurs processus, le graphique
dappel indique uniquement lordre dexcution dans le processus principal.
6-18
Restructuration des excutables via fdpr

Le programme fdpr (feedback-directed program restructuring) optimise des modules
excutables pour acclrer leur excution et rendre plus efficace lutilisation de la mmoire
relle. Sous AIX version 4.1, cet outil fait partie de la bote outils Performance Toolbox for
AIX. Pour savoir si fdpr est disponible, entrez :
Si ce module est install, fdpr est disponible.
Le traitement fdpr se fait en trois tapes :
Instrumentation du module excutable optimiser pour permettre la collecte dtaille des
donnes de fonctionnement.
Exploitation de lexcutable instrument, avec une charge de travail fournie par
lutilisateur, et enregistrement des donnes de performance recueillies.
Exploitation des donnes de performances pour piloter le processus doptimisation, qui
se traduit par un module excutable restructur et capable dexcuter plus efficacement
la charge de travail gre par lexcutable instrument. Il est crucial que la charge de
travail utilise pour piloter fdpr corresponde prcisment lutilisation actuelle du
programme. Les performances dun excutable restructur avec des charges de travail
diffrentes de celles utilises pour piloter fdpr sont imprvisibles, mais peuvent tre
moins bonnes que celles de lexcutable dorigine.
Par exemple, la commande :
fdpr p NomProgramme R3 x test.sh
utilise le jeu dessai test.sh pour exploiter le programme instrument NomProgramme. La
sortie de cette commande peut tre utilise pour atteindre le plus haut degr doptimisation
(R3) du programme et former un nouveau module appel, par dfaut,
NomProgramme.fdpr. La diffrence de performance entre lexcutable optimis et celui
non-optimis dpend largement de la prcision de la simulation de la charge de travail par
lessai test.sh.
Attention : Les algorithmes doptimisation avancs intgrs au programme fdpr
entranent parfois une diffrence de fonctionnement entre les excutables optimiss et le
module excutable dorigine. Pour une question de fiabilit, il est essentiel de tester de
faon exhaustive un excutable optimis avant toute exploitation.
En rsum, les utilisateurs de fdpr doivent :
veiller utiliser une charge de travail reprsentative pour piloter fdpr ;
tester de faon exhaustive le fonctionnement de lexcutable restructur ;
exploiter lexcutable restructur uniquement sur les charges de travail pour lesquelles il
est prvu.
6-19
Contrle des conflits pour la CPU

Priorit des processus utilisateur
Les priorits des processus utilisateur peuvent tre fixes via les commandes nice et
renice et la sous-routine setpri, et affiches via ps. Les priorits sont prsentes dans
Priorit des processus et des routines, page 2-3.
Excution dune commande priorit non standard via nice

Tout utilisateur peut exploiter une commande un niveau de priorit infrieur au niveau
normal via nice . En revanche, seul lutilisateur root peut lancer nice pour exploiter des
commandes une priorit plus leve.
Via nice, lutilisateur spcifie une valeur ajouter ou soustraire de la valeur nice standard.
La valeur ainsi obtenue est exploite par le processus qui lance la commande. A ce stade,
la priorit du processus nest toujours pas fixe : sa valeur est recalcule priodiquement en
fonction de lutilisation de la CPU, de la valeur nice ainsi que de la valeur minimum de la
priorit du processus utilisateur.
La valeur nice standard dun processus davant-plan est de 20, celle dun processus
darrire-plan, de 24. Pour obtenir la valeur initiale de la priorit, additionnez la valeur nice
et le niveau minimum de priorit de processus utilisateur (40). Par exemple, la commande :
$ nice 5 vmstat 10 3 >vmstat.out
excute vmstat avec la valeur nice de 25 (au lieu de 20), entranant une priorit de base
de 65 (avant ajout d lutilisation rcente de la CPU).
Un utilisateur root aurait pu lancer vmstat une priorit suprieure :
# nice 5 vmstat 10 3 >vmstat.out
Si un utilisateur non root lance cette commande nice, la commande vmstat fonctionne,
mais avec la valeur nice standard 20, et nice ne gnre aucun message derreur.
Dfinition dune priorit fixe via setpri

Une application qui fonctionne sous lID utilisateur root peut exploiter la sous-routine
setpri pour dfinir sa propre priorit ou celle dun autre processus. Voici quelques conseils :
retcode = setpri(0,59);
affecte au processus en cours une priorit fixe de 59. Si setpri choue, il retourne la
valeur 1.
Le programme suivant accepte une valeur de priorit et une liste dID de processus ; la
priorit de tous les processus est fixe la valeur indique.
6-20
/*
fixprocpri.c
Usage: fixprocpri priority PID . . .
*/
#include <sys/sched.h>
#include <stdio.h>
#include <sys/errno.h>
main(int argc,char **argv)
{
pid_t ProcessID;
int Priority,ReturnP;
if( argc < 3 ) {
printf( usage setpri priority pid(s) \n);
exit(1);
}
argv++;
Priority=atoi(*argv++);
if ( Priority < 50 ) {
printf( Priority must be >= 50 \n);
exit(1);
}
while (*argv) {
ProcessID=atoi(*argv++);
ReturnP = setpri(ProcessID, Priority);
if ( ReturnP > 0 )
printf(pid=%d new pri=%d old pri=%d\n,
(int)ProcessID,Priority,ReturnP);
else {
perror( setpri failed );
exit(1);
}
}
}
Affichage de la priorit des processus via ps

Lindicateur l (L minuscule) de la commande ps permet laffichage des valeurs nice et des
priorits courantes pour les processus spcifis. Par exemple, pour afficher les priorits des
processus dun utilisateur donn, entrez :
# ps lu
F
241801
200801
241801
waters
S UID PID
S 200 7032
S 200 7569
S 200 8544
PPID
7287
7032
6495
C PRI NI ADDR
0 60 20 1b4c
0 65 25 2310
0 60 20 154b
SZ
108
88
108
WCHAN
5910a58
TTY
pts/2
pts/2
pts/0
TIME
0:00
0:00
0:00
CMD
ksh
vmstat
ksh
La sortie montre le rsultat de la commande nice 5 dcrite plus haut. Le processus 7569 a
une priorit effective de 65 (la commande ps a t lance en mode superutilisateur lors
dune autre session, do la prsence de deux TTY).
Si lun des processus a exploit la sous-routine setpri pour sattribuer une priorit fixe, le
format en sortie de ps l est le suivant :
F S UID PID PPID
C PRI NI ADDR
200903 S
0 10759 10500 0 59 3438
40
SZ
WCHAN
TTY TIME CMD
4f91f98 pts/0 0:00 fixpri
Modification de la priorit dun processus en cours via renice

Remarque : Dans cette section, la syntaxe renice pour AIX version 3 est utilise. La
section suivante traite de la syntaxe de nice et renice sous AIX versions 3 et 4.
6-21
renice modifie la valeur nice et, par consquent, la priorit du ou des processus en cours
dexcution. Les processus sont identifis via lID processus, lID groupe de processus ou le
nom de lutilisateur des processus. renice ne peut tre appliqu des processus priorit
fixe.
A partir de lexemple prcdent, modifions la valeur nice (renice) du processus vmstat
lanc via nice :
# renice 5 7569
7569: old priority 5, new
# ps lu waters
F S UID PID PPID
241801 S 200 7032 7287
200801 S 200 7569 7032
241801 S 200 8544 6495
priority 0
C PRI NI ADDR
0 60 20 1b4c
0 55 15 2310
0 60 20 154b
SZ
108
92
108
WCHAN
5910a58
TTY
pts/2
pts/2
pts/0
TIME
0:00
0:00
0:00
CMD
ksh
vmstat
ksh
Le processus est prsent excut une priorit suprieure celles des autres processus
davant-plan. Notez que renice najoute ni ne retranche la valeur spcifie lancienne
valeur nice. Elle remplace lancienne valeur par la nouvelle. Pour annuler le tout, entrez :
# renice 0 7569
7569: old priority 5, new
# ps lu waters
F S UID PID PPID
241801 S 200 7032 7287
200801 S 200 7569 7032
241801 S 200 8544 6495
priority 0
C PRI NI ADDR
0 60 20 1b4c
1 60 20 2310
0 60 20 154b
SZ
108
92
108
WCHAN
5910a58
TTY
pts/2
pts/2
pts/0
TIME
0:00
0:00
0:00
CMD
ksh
vmstat
ksh
Dans ces exemples, renice est lanc par lutilisateur root. Lutilisation de renice par un
utilisateur non root est doublement limite. Il ne peut :
lancer cette commande que sur ses propres processus,
augmenter la priorit dun processus, mme pour restaurer sa priorit par dfaut, aprs
lavoir diminue via renice.
Clarification de la syntaxe nice/renice

AIX version 3
Pour les commandes nice et renice, lajout dune valeur la valeur nice standard (20) nest
pas exprime de la mme faon.
Pour nice, un signe moins plac avant la valeur, suppose positive, est obligatoire pour
lidentifier. Pour spcifier une valeur ngative, un second signe moins (sans espace entre
les deux) est requis.
Pour renice, le paramtre qui suit le nom de la commande est suppos tre la valeur
ajouter. Cette valeur peut comporter un signe ou non (dans ce cas, la valeur est positive).
Les commandes suivantes sont donc quivalentes :
nice 5
nice 5
nice 5
renice 5
renice +5
renice 5
Resulting
nice Value
25
25
15
Resulting
Priority Value
65
65
55
AIX version 4.1

Sous AIX version 4, la syntaxe de renice a t modifie pour complter la syntaxe de nice,
qui utilise lindicateur n pour identifier laugmentation de la valeur nice. Le tableau suivant
est la version AIX version 4.1 du tableau prcdent :
nice n 5
nice n +5
nice n 5
6-22
renice n 5
renice n +5
renice n 5
Resulting
nice Value
25
25
15
Resulting
Priority Value
65
65
55
Optimisation du calcul de la priorit dun processus via schedtune

Une rcente amlioration de schedtune et du programmateur CPU dAIX autorise la
modification des paramtres utiliss pour calculer la priorit dun processus.
Cette nouveaut dAIX version 4.1 est disponible dans le PTF pour la version 3.2.5.
Reportez-vous Priorit des processus et des routines, page 2-3.
La formule de calcul dune priorit est la suivante :
priorit = priorit de base + valeur nice + (pnalit CPU base
sur lutilisation rcente de la CPU)
La valeur de lutilisation rcente de la CPU dun processus donn est incrmente de 1
chaque fois que le processus contrle la CPU lors dune interruption de lhorloge (toutes les
10 millisecondes). Cette valeur est affiche en colonne C de la sortie de la commande ps.
Son maximum est 120.
Lalgorithme calcule la pnalit CPU en divisant lutilisation rcente de la CPU par 2. Le
rapport pnalit CPU/utilisation rcente de la CPU est donc 0,5. Cette valeur est dsigne
par R.
Toutes les secondes, lalgorithme en cours divise la valeur de lutilisation rcente de la CPU
de chaque processus par 2. Le facteur de dcroissance du temps dutilisation de la CPU
rcente est donc de 0,5. Cette valeur est dsigne par D.
Pour certains utilisateurs, lalgorithme existant ntablit pas une distinction assez nette entre
les processus darrire-plan et davant-plan. Par exemple, si un processus davant-plan
(valeur nice = 20) et un processus darrire-plan (valeur nice = 24) lancs en mme temps
sollicitent de faon intensive les fonctions de calcul du systme, on obtient la squence
suivante (sans tenir compte des autres activits) :
Le processus davant-plan est programm le premier. Au bout de 8 tranches horaires
(80 ms), sa pnalit CPU est 4, ce qui rend sa priorit gale celle du processus
darrire-plan. Lalgorithme de rpartition par permutation circulaire engendre la
programmation du processus darrire-plan.
Au bout de 2 autres tranches horaires, la pnalit CPU du processus darrire-plan est 1,
ce qui rend sa priorit suprieure de 1 celle du processus davant-plan. Le processus
davant-plan est programm.
Au bout de 2 autres tranches horaires, les priorits des processus redeviennent gales.
Les processus continuent dalterner toutes les 2 tranches horaires jusqu la fin de la
seconde.
A la fin de la seconde, le processus davant-plan aura dispos de 54 tranches horaires et
celui darrire-plan de 46. Lorsque le facteur de dcroissance est appliqu, les valeurs du
temps dutilisation CPU sont 27 et 23. A la deuxime seconde de leur comptition, les
processus davant-plan nont que 4 tranches horaires de plus que le processus
darrire-plan.
Mme si le processus darrire-plan est lanc avec nice 20, la diffrence entre avant-plan
et arrire-plan est peine plus marque. Bien que le programmateur arrte de compter les
tranches horaire aprs 120, cela permet au niveau de pnalit CPU de sarrter 60, ce qui
suffit largement pour compenser la diffrence maximale de 40 de valeur nice.
Pour assouplir le processus dattribution des priorits, les nouvelles caractristiques
permettent lutilisateur doptimiser le rapport pnalit CPU/utilisation de CPU rcente (R)
et le taux de dcroissance du temps dutilisation de CPU rcente (D). Cette optimisation est
ralise via deux nouvelles options de la commande schedtune : r et d. Chaque option
spcifie un paramtre (entier compris entre 0 et 32) qui multiplie lutilisation de CPU rcente
par la valeur du paramtre puis divise le rsultat par 32 (en dcalant de 5 droite). Les
valeurs r et d par dfaut sont 16, ce qui entrane le mme rsultat que lalgorithme de
dpart (D=R=16/32=0,5). Les nouvelles valeurs autorisent plus de latitude. Par exemple :
# schedtune r 0
6-23
(R=0, D=0,5) signifie que la pnalit CPU est 0, ce qui rend la priorit absolue : aucun
processus darrire-plan ne peut obtenir de temps CPU tant quun processus davant-plan
en rclame. Les priorits des processus sont en effet constantes, mme si, techniquement,
ce ne sont pas des processus priorit fixe.
# schedtune r 5
(R=0,15625, D=0,5) signifie que des processus davant-plan nentreront jamais en
comptition avec un processus darrire-plan lanc via nice 20. La limite de 120 tranches
de temps CPU accumules signifie que la pnalit maximum pour les processus
davant-plan est fixe 18.
# schedtune r 6 d 16
(R=0,1875, D=0,5) signifie quun processus darrire-plan lanc via nice 20, le sera au
moins une seconde avant que le processus darrire-plan ne reoive du temps CPU.
Cependant, les processus davant-plan peuvent toujours tre distingus sur la base de
lutilisation de CPU. Les processus davant-plan longs qui doivent normalement se trouver
en arrire-plan finissent par accumuler suffisamment dutilisation de CPU pour les
empcher dinterfrer avec lavant-plan rel.
# schedtune r 32 d 32
(R=1, D=1) signifie que les processus longs atteignent une valeur C gale 120 et la
conservent, en opposition avec leur valeur nice. Les nouveaux processus ont la priorit
quelle que soit leur valeur nice, jusqu ce quils aient accumul suffisamment de tranches
horaires pour passer dans la gamme de priorits des processus existants.
Si vous estimez quun ou deux paramtres doivent tre modifis pour sadapter la charge
de travail, entrez la commande schedtune, en tant quutilisateur root. Les valeurs
modifies seront conserves jusqu la prochaine commande schedtune ou jusquau
ramorage suivant du systme. Vous pouvez rtablir les valeurs par dfaut via
schedtune D, mais noubliez pas qualors tous les paramtres schedtune sont
rinitialiss par cette commande, y compris les paramtres de contrle de charge
mmoire VMM. Pour faire perdurer une modification au fil des ramorages, ajoutez la ligne
approprie la fin du fichier /etc/inittab.
6-24
Modification de la tranche horaire du programmateur

Vous pouvez modifier la dure de la tranche horaire du programmateur via la commande
schedtune (voir page A-6). La syntaxe de cette fonction est la suivante :
schedtune t increase
increase est le nombre dimpulsions dhorloge de 10 ms ajouter la tranche horaire
standard (un battement de 10 ms). Par exemple, schedtune t 2 fait passer la dure de la
tranche horaire 30 ms. schedtune t 0 lui raffecte sa valeur par dfaut.
Dans un environnement o la tranche horaire a t augmente, certaines applications nont
pas besoin dutiliser la totalit de la tranche horaire. Ces applications peuvent renoncer
explicitement au processeur via lappel systme yield (comme peuvent le faire les
programmes dans un environnement non modifi). Aprs un appel yield, la routine qui met
lappel est dplace la fin de la file dattente de rpartition en fonction de son niveau de
priorit.
6-25
Administration des ID utilisateur

Pour optimiser le temps de rponse de la connexion et conserver du temps CPU dans un
systme multiutilisateur, AIX peut exploiter une version accs direct du fichier
/etc/passwd pour consulter les ID utilisateur. Lorsque cette fonction est utilise, le fichier
/etc/passwd existe toujours mais nest pas employ dans le traitement courant.
Les versions accs direct du fichier (/etc/passwd.dir et /etc/passwd.pag) sont cres via
la commande mkpasswd. Si ces versions accs direct ne sont pas actives, le processus
de connexion revient une recherche squentielle lente, utilisant la CPU de faon intensive
via /etc/passwd.
Lorsque les fichiers de mot de passe accs direct ont t crs, et que les commandes
passwd, mkuser, chuser et rmuser (ou leurs quivalents smit) sont exploites pour
administrer les ID utilisateur, les fichiers accs direct sont mis jour automatiquement.
Si le fichier /etc/passwd est modifi via un diteur ou la commande pwdadm, les fichiers
accs direct doivent tre reconstruits via la commande suivante :
# mkpasswd /etc/passwd
6-26
Chapitre 7. Contrle et optimisation de la mmoire
La mmoire dun ESCALA est presque toujours pleine. Si les programmes en cours ne
loccupent pas intgralement, AIX y conserve les pages de texte de programmes antrieurs
et des fichiers associs. Ceci ne cote rien, puisque la mmoire est de toutes faons
inutilise. Souvent, par contre, les pages de fichier ou de programme sont rutilises, ce qui
rduit les E/S disque.
Cette technique de mise en mmoire cache amliore lefficacit du systme mais rend plus
difficile lvaluation des besoins mmoire rels dune charge de travail.
Ce chapitre dcrit comment mesurer et modifier la quantit de mmoire utilise. Elle
comporte les sections suivantes :
Quantit de mmoire utilise rpertorie les commandes relatives lexploitation de la
mmoire et traite de leurs avantages et inconvnients.
Programme perte de mmoire dcrit lune des causes les plus courantes de
surcharge de mmoire.
Analyse de lexploitation de la mmoire via BigFoot dcrit les caractristiques et le
fonctionnement de loutil BigFoot, qui rend compte des schmas dutilisation de la
mmoire.
Estimation de la mmoire requise via rmss illustre les techniques dutilisation de loutil
Reduced-Memory System Simulator.
Optimisation du contrle de la charge mmoire VMM dcrit les situations dans
lesquelles cette optimisation est ncessaire et les mthodes doptimisation via la
commande schedtune.
Optimisation du remplacement de page VMM dtaille les mthodes et les effets de la
modification des paliers de remplacement de page VMM.
Les lecteurs qui ne seraient pas familiariss avec la gestion de la mmoire virtuelle dAIX
peuvent se reporter Performance du gestionnaire de mmoire virtuelle (VMM), page 2-5
avant de poursuivre.
7-1
Quantit de mmoire utilise

Plusieurs outils rendent compte de lutilisation de la mmoire. Les relevs les plus
intressants sont ceux tablis via vmstat, ps et svmon.
vmstat
vmstat rend compte de la mmoire virtuelle active totale exploite par tous les processus
du systme ainsi que le nombre de trames de page en mmoire relle dans la liste des
disponibilits. La mmoire virtuelle active est dfinie comme le nombre de pages de
segments actifs en mmoire virtuelle qui ont t exploites. Elle est gnralement gale au
nombre demplacements despace de pagination dj affects. Ce nombre peut tre
suprieur au nombre de trames de page relles de la machine, dans la mesure o certaines
pages de la mmoire virtuelle active peuvent avoir t vacues vers lespace de
pagination.
ps
ps fournit des comptes rendus diffrents en fonction de lindicateur spcifi. Le plus complet
est issu de ps v, qui affiche les colonnes suivantes :
SIZE
Taille virtuelle en kilo-octets de la section de donnes du processus. (affich

comme SZ par les autres indicateurs). Ce chiffre est gal la quantit de
pages de segment de travail des processus en cause (le nombre
demplacements despaces de pagination affects) multipli par 4. Si
certaines pages de segment de travail sont vacues, ce chiffre est
suprieur la quantit de mmoire relle utilise.
RSS
Taille de la mmoire relle du processus (jeu rsidant) en kilo-octets. Ce

chiffre est gal la somme de segments de travail et des pages de
segments de code en mmoire multiplie par 4. Les pages de segment de
codes sont partages entre toutes les instances en cours du programme. Si
26 processus ksh sont en cours, une seule copie dune page donne de
lexcutable ksh rside en mmoire, mais ps intgre la taille de ce segment
de code dans le RSS de chaque instance de ksh.
TSIZ
Taille de limage texte (programme partag). Taille de la section de texte du

fichier excutable. Les pages de texte de lexcutable ne sont charges en
mmoire que lorsquelles sont utilises (branchement ou chargement). Ce
chiffre ne reprsente que la limite suprieure de la quantit de texte qui peut
tre charge.
TRS
Taille de lensemble de texte rsidant (en mmoire relle). Elle est gale au
nombre de pages de segment de codes multipli par 4. Comme indiqu plus
haut, ce chiffre surestime lutilisation de la mmoire pour les programmes
dont plusieurs instances sont en cours.
%MEM
Somme du nombre de segments de travail et de pages de segments de

code en mmoire multiplie par 4 (cest--dire la valeur RSS), divise par la
taille de la mmoire relle de la machine en ko, multiplie par 100, et
arrondie. Cette valeur est une estimation du pourcentage de mmoire relle
utilise par le processus. Malheureusement, comme RSS, le cot dun
processus partageant un programme avec dautres y est souvent survalu.
De plus, ce pourcentage tant arrondi, tous les processus du systme ayant
une valeur RSS infrieure 0,005 fois la taille de la mmoire relle ont une
valeur %MEM gale 0.
Il ressort clairement qutablir des statistiques relatives la mmoire dans un format conu
pour des systmes antrieurs, plus simples, aboutit des donnes fausses.
7-2
svmon
svmon fournit des comptes rendus de lutilisation de la mmoire au niveau du processus
global et au niveau du segment. G et P sont les options les plus intressantes pour
loptimisation.
G
Rend compte de lutilisation de la mmoire pour le systme entier.
Rend compte de lutilisation de la mmoire pour un ou plusieurs

processus.
Sous AIX version 4.1, la commande svmon est intgre la bote outils PTX
(Performance Toolbox for AIX). Pour savoir si svmon est disponible, entrez :
Si ce module est install, svmon est disponible.
Exemples de sortie vmstat, ps et svmon

Lexemple suivant illustre la sortie de ces commandes sur un grand systme. vmstat a t
excut dans une fentre spare, et ps et svmon successivement. La (premire) ligne du
relev vmstat a t supprime :
$ vmstat 5
procs
memory
page
faults
cpu

r b
avm
fre re pi po fr
sr cy in
sy cs us sy id wa
0 0 25270 2691
0
0
0
0
0
0 142 2012 41 4 11 86 0
1 0 25244 2722
0
0
0
0
0
0 138 6752 39 20 70 10 0
0 0 25244 2722
0
0
0
0
0
0 128
61 34 0 1 99 0
0 0 25244 2722
0
0
0
0
0
0 137 163 41 1 4 95 0
Le compte rendu global svmon ci-dessous indique les chiffres correspondants. Le nombre
prsent par vmstat comme mmoire virtuelle active( avm) est report par svmon comme
emplacements despace de pagination en cours dutilisation (25270). Le nombre de trames
de page de la liste des disponibilits (2691) est identique dans les deux comptes rendus.
Le nombre de pages fixes (2157) fait lobjet dun compte-rendu spar car les pages fixes
sont comptes dans les pages en cours dutilisation.
$ svmon G
m e m o r y
size inuse free
24576 21885 2691
pin
2157
i n
work
13172
u s e
pers clnt
7899
814
p i n
work pers
2157
0
p g s p a c e
clnt
size inuse
0 40960 25270
Pour faire ressortir un processus donn, long, sur cette machine, nous pouvons comparer
les comptes rendus ps v et svmon P. Le programme rel a t renomm anon.
$ ps v 35851
PID TTY STAT
35851
S
TIME PGIN
0:03 494
SIZE
1192
RSS
2696
LIM
xx
TSIZ
1147
TRS %CPU %MEM COMMAND

1380 0.2 3.0
anon
La valeur de SIZE (1192) est le nombre de Pgspace de svmon (298) multipli par quatre.
RSS (2696) est gal la somme du nombre de pages du segment priv du processus (329)
et du nombre de pages du segment du code (345) multiplie par quatre. TSIZE nest pas li
lutilisation de la mmoire relle. TRS (1380) est gal au nombre de pages utilises dans
le segment du code (345) multipli par quatre. %MEM est gal la valeur RSS divise par
la taille de la mmoire relle en ko, multiplie par 100 et arrondie.
$ svmon P 35851
Pid
Command
35851
anon
Pid: 35851
Command: anon
Segid Type Description
Inuse
18a3 pers /dev/hd2:5150
1
9873 pers /dev/hd2:66256
1
4809 work shared library
1734
748e work private
329
2105 pers code,/dev/hd2:4492 345
Inuse
2410
Pin
0
0
0
2
0
Pgspace
0
0
4326
298
0
Pin
2
Pgspace
4624
Address Range
0..0
0..0
0..4668 : 60123..65535
0..423 : 65402..65535
0..402
7-3
Au fur et mesure de lanalyse des diffrents processus de cet environnement, nous

observons que la bibliothque partage lest par presque tous les processus du systme, et
que ses besoins en mmoire font partie de la charge systme. La mmoire du
segment 9873, galement trs sollicite, peut y tre incluse. Pour estimer les besoins en
mmoire du programme anon, la formule serait la suivante :
La mmoire requise pour anon est gale 345 * 4 ko pour le texte programme (partag par
tous les utilisateurs), plus nombre estim dutilisateurs simultans de anon multipli par la
somme de la taille du segment de travail (329 * 4 ko) et de 4 ko pour le segment mapp
(ID segment 18a3 dans cet exemple).
Programmes perte de mmoire

Une perte de mmoire est un bogue logiciel qui fait quun programme affecte de la mmoire
plusieurs reprises, lutilise puis oublie de la librer. Sil sagit dun programme long
(une application interactive, par exemple), le problme peut tre srieux car la mmoire
risque dtre fragmente, et des pages remplies dinformations parasites risquent de
saccumuler en mmoire relle et en espace de pagination. Il sest dj produit que des
programmes manquent despace de pagination cause dune perte de mmoire dans un
seul programme.
svmon dtecte les pertes de mmoire en recherchant les processus qui contiennent des
segments de travail en augmentation continuelle. Il est plus difficile, en particulier pour les
applications AIXwindows, didentifier les sous-routines ou les lignes de codes qui gnrent
un grand nombre dappels malloc et free. Il existe des programmes de fournisseurs tiers
pour analyser les pertes de mmoire, mais ils ncessitent laccs au code source du
programme.
Certaines utilisations de realloc peuvent produire le mme effet quune perte de mmoire.
Si un programme exploite frquemment realloc pour augmenter la taille dune zone de
donnes, le segment de travail dun processus peut devenir de plus en plus fragment si la
mmoire libre par realloc ne peut pas tre rutilise. (Lannexe F, Gestion de la
mmoire des applications contient des informations sur malloc et realloc.)
Gnralement, la mmoire devenue inutile doit tre libre via free, si la mmoire doit tre
rutilise par le programme. Dun autre ct, cest une perte de temps CPU que de librer
(free) de la mmoire aprs le dernier malloc. Lorsque lexcution du programme est
termine, son segment de travail est dtruit et les trames de pages de mmoire relle qui
contiennent les donnes du segment de travail, ajoutes la liste des disponibilits.
Voir aussi
Commandes vmstat, ps et svmon.
7-4
Analyse de lexploitation de la mmoire via BigFoot

Remarque : Cette section ne concerne que les versions 4.1 et ultrieures dAIX.
BigFoot fait partie de Performance Toolbox for AIX. Pour savoir sil est disponible, entrez :
Si ce module est install, BigFoot est disponible.
BigFoot recueille les informations relatives lespace occup en mmoire par un
programme en cours. Il tablit un compte rendu sur les pages de mmoire virtuelle
touches par le processus. BigFoot est constitu de deux commandes :
bf
collecte des informations sur les pages touches au cours de
lexcution dun programme. Il gnre des donnes compltes sur
lexploitation dans le fichier __bfrpt.
bfrpt
filtre le fichier __bfrpt pour extraire les rfrences mmoire cres par
un processus donn.
7-5
Estimation de la mmoire requise via rmss

rmss (Reduced-Memory System Simulator) permet de simuler les ESCALA avec des tailles
de mmoire infrieures celles de la machine, sans dposer ni reposer de cartes mmoire.
De plus, rmss permet dexploiter une application avec diffrentes tailles de mmoire, en
affichant, pour chaque taille, des statistiques de performance sur, par exemple, le temps de
rponse de lapplication et la quantit de pagination. En bref, rmss est conu pour rpondre
la question : Combien de mga-octets de mmoire relle requiert un ESCALA pour
exploiter AIX et une application donne avec un niveau de performance acceptable ? ou,
dans un contexte multi-utilisateur, Combien dutilisateurs peuvent exploiter simultanment
cette application sur un systme disposant de X mgaoctets de mmoire relle ?
Sous AIX version 4.1, la commande rmss est intgre la bote outils PTX (Performance
Toolbox for AIX). Pour savoir si rmss est disponible, entrez :
Si ce module est install, rmss est disponible.
Il est important de ne pas oublier que la taille mmoire simule par rmss est la taille globale
de la mmoire relle de la machine, dont la mmoire utilise par AIX et les autres
programmes en cours. Il ne sagit pas de la quantit de mmoire utilise spcifiquement par
lapplication elle-mme. Compte tenu des dgradations de performances quelle peut
provoquer, rmss est exclusivement rserve lutilisateur root et aux membres du groupe
systme. Les sections suivantes dcrivent rmss plus en dtail :
Mthodes dexploitation de rmss
Exploitation de rmss pour modifier la taille de la mmoire et quitter
Exploitation de rmss pour lancer une commande avec des tailles de mmoire
diffrentes
Rgles dexploitation de rmss.
Mthodes dexploitation de rmss

rmss peut tre activ : (1) pour modifier la taille de la mmoire relle et quitter ; (2) comme
programme pilote, pour excuter une application avec diffrentes tailles de mmoire relle
et afficher des statistiques sur les performances pour chaque taille. La premire technique
donne des informations sur le comportement dune application dans un systme dune
certaine taille, lorsque lapplication est trop complexe pour tre exprime comme une
commande unique, ou lorsque vous souhaitez exploiter des instances multiples dune
application. La seconde technique est approprie lorsque lapplication peut tre active
comme excutable ou fichier script shell.
Remarque : Avant de lancer rmss, nous vous conseillons de lancer la commande
schedtune h 0, page 7-14 pour dsactiver le contrle de charge mmoire VMM. Faute
de quoi, ce contrle risque dinterfrer avec vos mesures, sur des mmoires de petite
taille. A la fin des essais, restaurez les paramtres de contrle de charge mmoire leur
valeur antrieure (ou lancez schedtune D pour revenir aux valeurs par dfaut).
Exploitation de rmss pour modifier la taille de la mmoire et quitter

Pour modifier la taille de la mmoire et quitter, utilisez lindicateur c :
# rmss c taille-mmoire
Par exemple pour faire passer la taille mmoire 12 Mo, entrez :
# rmss c 12
taille-mmoire est un nombre entier ou dcimal de mgaoctets (12,25, par exemple).
En outre, taille-mmoire doit tre compris entre 4 Mo et la taille physique relle de la
mmoire de votre machine. Selon la configuration matrielle et logicielle, il se peut que
rmss ne permette pas de rduire la taille mmoire moins de 8 Mo, cause de la taille de
7-6
la structure des systmes inhrents tels que le noyau. Si une taille de mmoire donne est
refuse par rmss, un message derreur est affich.
rmss diminue la taille effective de la mmoire dun ESCALA en volant des trames de page
disponibles dans la liste tenue par VMM. Ces trames, conserves dans un fond de trames
inutilisables, sont renvoyes dans la liste des disponibilits lorsque la taille de la mmoire
effective doit tre augmente. De plus, rmss ajuste dynamiquement certaines structures de
donnes et variables systme qui doivent rester proportionnelles la taille de la mmoire
effective.
La modification de la taille de la mmoire peut prendre jusqu 15 ou 20 secondes.
En gnral, plus la rduction souhaite est importante, plus rmss prend de temps.
Lorsque rmss a abouti, le message suivant saffiche :
Simulated memory size changed to 12,00 Mb.
Pour afficher la taille actuelle de la mmoire, utilisez lindicateur p :
# rmss p
rmss rpond par :
Simulated memory size is
12.00 Mb.
Si, finalement, vous souhaitez rgler la taille de la mmoire sur celle de la mmoire actuelle
de la machine, utilisez lindicateur r :
# rmss r
Quelle que soit la taille de la mmoire virtuelle actuelle, lindicateur r ramne la taille de la
mmoire celle de la mmoire relle physique de la machine. Dans cet exemple, o un
systme de 16 Mo est exploit, rmss rpond :
Simulated memory size changed to 16,00 Mb.
Remarque : La commande rmss indique la quantit de mmoire relle utilisable. Sur les
machines dont la mmoire nest pas fiable ou dj utilise, rmss indique la quantit de
mmoire relle, cest--dire la mmoire physique relle moins la mmoire non fiable ou
dj utilise par le systme. Par exemple, la commande rmss r peut indiquer :
Simulated memory size changed to 79.9062 Mb.
Dans cet exemple, une partie de la mmoire est considre comme non fiable ou est
rserve par un priphrique (et nest donc pas disponible pour lutilisateur).
Indicateurs c, p et r
Les indicateurs c, p et r de rmss permettent, contrairement dautres options,
dexploiter des applications complexes qui ne peuvent tre exprimes en un fichier
excutable ou un script shell unique. Les indicateurs c, p et r vous obligent, par contre,
valuer vous-mme les performances. Il existe un moyen simple de le faire : vmstat s
mesure lactivit au niveau de lespace de pagination lors de lexcution dune application.
Si vous lancez vmstat s, puis lapplication, puis nouveau vmstat s, et calculez la
diffrence entre le nombre de transferts en mmoire despace de pagination avant et
aprs, vous obtenez le nombre de transferts effectus pendant le programme. En outre,
en chronomtrant le programme, puis en divisant le nombre de transferts par la dure
dexcution du programme, vous obtenez le taux moyen de transferts de lespace de
pagination.
Il est galement important dexcuter plusieurs fois lapplication avec chaque taille mmoire.
Deux raisons : dabord, lors de la modification de la taille de la mmoire, rmss vide une
grande quantit de mmoire. Ainsi, la premire fois que lapplication est lance aprs
modification de la taille de la mmoire, il est possible quune partie importante du temps
dexcution soit pris par la lecture des fichiers en mmoire relle. Cependant, les fichiers
pouvant rester en mmoire aprs lexcution de lapplication, les temps dexcution suivants
peuvent tre plus courts. Lautre raison dexcuter plusieurs fois lapplication est davoir une
ide de ses performances moyennes avec une taille donne de mmoire. Le ESCALA et
7-7
AIX sont des systmes complexes, et il est impossible de dupliquer ltat du systme
chaque fois que votre application est excute. Ainsi, la performance dune application peut
varier de faon significative dune excution lautre.
En rsum, vous devez tenir compte des tapes suivantes pour activer rmss :
sil existe plusieurs tailles de mmoire examiner :
{
changez la taille de la mmoire via rmss c ;
lancez lapplication une premire fois ;
pour plusieurs excutions :
{
lancez vmstat s pour obtenir le nombre avant de transferts
en mmoire despace de pagination ;
lancez et chronomtrez lapplication ;
lancez vmstat s pour obtenir le nombre aprs de transferts
en mmoire despace de pagination ;
soustrayez la valeur avant de la valeur aprs pour
obtenir le nombre de transferts en mmoire pendant
lexcution ;
divisez le nombre de transferts en mmoire despace de pagination par
le temps de rponse
pour obtenir le taux de transferts en mmoire de lespace
de pagination ;
}
}
lancez rmss r pour restaurer la taille mmoire normale (ou ramorcez)
Le calcul du nombre dE/S de pagination (aprs avant) peut tre automatis via le script
vmstat.sh inclus dans le module PerfPMR.
Exploitation de rmss pour lancer une commande avec des tailles de mmoire
diffrentes
Les indicateurs s, f, d, n et o sont exploits pour activer rmss comme programme
pilote : rmss excute une application spcifie avec des tailles de mmoire diffrentes et
affiche des statistiques sur ses performances pour chaque taille de mmoire. La syntaxe
pour ce type dactivation de rmss est la suivante :
rmss [ s smemsize ] [ f fmemsize ] [ d memdelta ]
[ n numiterations ] [ o outputfile ] command
Lindicateur n permet de spcifier le nombre dexcutions et mesure le temps dexcution
de la commande pour chaque taille de mmoire. o spcifie le fichier dans lequel crire le
compte rendu rmss ; command est lapplication lancer et chronomtrer pour chaque
taille de mmoire. Ces indicateurs sont dtaills plus loin.
Les indicateurs s, f et d permettent de spcifier les diffrentes tailles de mmoire : s la
taille de dpart, f la taille finale et d la diffrence entre les tailles. Toutes ces valeurs sont
des nombres entiers ou dcimaux, en mgaoctets. Par exemple, pour lancer et mesurer
une commande avec 24, 20, 16, 12 et 8 Mo, utilisez la combinaison suivante :
s 24 f 8 d 4
De mme, pour les tailles 16, 24, 32, 40 et 48 Mo, la combinaison est la suivante :
s 16 f 48 d 8
Si vous omettez lindicateur s, rmss dmarre avec la taille mmoire actuelle de la
machine. Si vous omettez lindicateur f, rmss sarrte 8 Mo. Si vous omettez
lindicateur d, la valeur par dfaut (8 Mo) est applique.
Quelles sont les valeurs possibles pour s, f et d ? Le plus simple consiste choisir les
tailles mmoire des ESCALA censs faire tourner lapplication concerne. Cependant, une
incrmentation infrieure 8 Mo peut tre utile, car elle vous donne une ide de la marge
de manuvre dont vous disposez lorsque vous fixez votre choix sur une taille.
Par exemple, si une application donne semballe 8 Mo mais fonctionne sans transferts
7-8
de pagination 16 Mo, il est intressant de savoir quelle taille, entre 8 et 16 Mo,

lapplication commence semballer. Si elle dmarre 15 Mo, vous pouvez configurer le
systme avec plus de 16 Mo de mmoire, ou modifier lapplication de sorte que la marge de
manuvre soit plus importante. Mais, si elle dmarre 9 Mo, vous savez que vous
disposez dune marge suffisante avec une machine 16 Mo.
Lindicateur n spcifie le nombre dexcutions et de mesures dune commande pour
chaque taille de mmoire. Aprs avoir lanc et mesur lapplication autant de fois que
spcifi, rmss affiche des statistiques sur les performances moyennes de lapplication pour
une taille donne. Pour lancer la commande 3 fois pour chaque taille de mmoire, entrez :
n 3
Si n est omis, rmss dtermine au cours de linitialisation le nombre de fois o lapplication
doit tre excute pour accumuler un temps dexcution total de 10 secondes.
rmss effectue cette opration pour assurer que les statistiques relatives aux performances
des programmes courts ne seront pas fausses par des lments externes (dmons, par
exemple).
Remarque : Si vous mesurez un programme trs bref, le nombre dexcutions
ncessaires pour accumuler 10 secondes de temps CPU peut tre trs important.
Chaque excution du programme mobilisant environ, et au moins, 2 secondes de charge
rmss, il est prfrable de spcifier explicitement le paramtre n pour les programmes
courts.
Quelles sont les valeurs recommandes pour n ? Si vous savez que lapplication sexcute
en plus de 10 secondes, vous pouvez spcifier n 1 pour que la commande ne soit
excute et mesure quune seule fois pour chaque taille mmoire. Il est intressant
dutiliser lindicateur n car, au cours de linitialisation, rmss na pas dterminer le nombre
dexcutions du programme. Ceci est encore plus intressant lorsque les commandes
mesurer sont longues et interactives.
Il ne faut pas oublier que rmss excute toujours la commande une premire fois pour
chaque taille mmoire, titre de mise en route, avant de la lancer et de la mesurer.
Ceci pour viter les E/S qui se produisent normalement lorsque lapplication ne se trouve
pas dj en mmoire. Bien que de telles E/S affectent les performances, cela nest pas
forcment d un manque de mmoire relle. La mise en route nest pas compte dans le
nombre spcifi par lindicateur n.
Lindicateur o permet de spcifier un fichier dans lequel crire le rapport rmss. Si
lindicateur o est omis, le rapport est crit dans le fichier rmss.out.
command spcifie lapplication mesurer : command est un excutable ou un script shell,
avec ou sans arguments sur la ligne de commande. Il existe toutefois quelques contraintes
sur la forme de cette commande. Elle ne doit pas contenir de racheminement de lentre
ou de la sortie (foo > output, foo < input, par exemple). Ceci parce que rmss
considre tout ce qui se trouve droite du nom de la commande comme des arguments de
cette commande. Pour effectuer un racheminement, vous devez placer la commande dans
un fichier script shell.
Normalement, pour enregistrer la sortie de rmss dans un fichier spcifique, vous utilisez
loption o. Pour racheminer, par exemple, la sortie stdout de rmss (pour linsrer, par
exemple, la fin dun fichier existant), vous devez, avec le shell Korn, mettre lappel de
rmss entre parenthses, comme suit :
# (rmss s 24 f 8 foo) >> sortie
Interprtation des rsultats de rmss
Cette section propose quelques interprtations des statistiques de performance produites
par rmss. Commenons par quelques rsultats typiques.
Lexemple Compte rendu gnr pour le programme foo, page 7-10 a t gnr en
lanant rmss sur un programme rel, dont le nom t simplement modifi en foo pour
7-9
prserver lanonymat. La commande normale pour gnrer ce compte-rendu est la

suivante :
# rmss s 16 f 8 d 1 n 1 o rmss.out foo
Compte rendu gnr pour le programme foo
Hostname: widgeon.austin.ibm.com
Real memory size:
16,00 Mb
Time of day: Thu Jan 8 19:04:04 1990
Command: foo
Simulated memory size initialized to
16,00 Mb.
Number of iterations per memory size = 1 warmup + 1 measured = 2.
Memory size
Avg. Pageins Avg. Response Time Avg. Pagein Rate
(megabytes)
(sec.)
(pageins / sec.)
16.00
115.0
123.9
0.9
15.00
112.0
125.1
0.9
14.00
179.0
126.2
1.4
13.00
81.0
125.7
0.6
12.00
403.0
132.0
3.1
11.00
855.0
141.5
6.0
10.00
1161.0
146.8
7.9
9.00
1529.0
161.3
9.5
8.00
2931.0
202.5
14.5
Ce compte rendu comporte quatre colonnes : la premire indique la taille de la mmoire, et
la colonne Avg. Pageins le nombre moyen de transferts en mmoire au cours de
lexcution de lapplication avec cette taille de mmoire. Il est important de noter que Avg.
Pageins fait rfrence toutes les oprations de transfert en mmoire, y compris le code,
les donnes et les fichiers lus partir de tous les programmes, qui se sont droules en
mme temps que lapplication. La colonne Avg. Response Time indique la dure
moyenne dexcution de lapplication, tandis que Avg. Pagein Rate indique le taux
moyen de transferts de pages.
Etudions dabord la colonne Avg. Pagein Rate. Entre 16 et 13 Mo, le taux de transfert
est assez rduit (< 1,5 transfert/s). Entre 13 et 8 Mo, ce taux augmente, dabord
graduellement, puis plus rapidement lorsque lon sapproche de 8 Mo. La colonne Avg.
Response Time a la mme structure : relativement bas au dpart, puis de plus en plus
important au fur et mesure que la taille de la mmoire tend vers 8 Mo.
Ici, le taux de transfert en mmoire dcrot avec le passage de la taille de la mmoire de
14 Mo (1,4 transfert/s) 13 Mo (0,6 transfert/s). Il ny a pas de quoi salarmer : il est
impossible dobtenir des rsultats uniformes avec un systme rel. Lessentiel est que le
taux de transfert en mmoire reste relativement bas pour une mmoire de 14 Mo et de
13 Mo.
Nous pouvons dduire quelques remarques de ce compte rendu. Si la performance dune
application est juge inacceptable 8 Mo (ce qui est probable), le fait dajouter de la
mmoire amliore cette performance de faon significative. Le temps de rponse varie
entre 124 secondes pour 16 Mo et 202 secondes pour 8 Mo, ce qui constitue une
augmentation de 63 %. Dun autre ct, si la performance est juge inacceptable 16 Mo,
lajout de mmoire ne lamliore pas beaucoup car, cette taille, les transferts en mmoire
ne ralentissent pas le programme de faon significative.
Exemples dexploitation des indicateurs s, f, d, n et o
Pour connatre les performances du script shell ccfoo qui comprend la commande
cc O c foo.c avec 16, 14, 12, 10, 8 et 6 Mo de mmoire, lancer et mesurer la
commande deux fois pour chaque taille de mmoire, puis crire le compte rendu dans le
fichier cc.rmss.out, entrez :
7-10
# rmss s 16 f 6 d 2 n 2 o cc.rmss.out ccfoo

Compte rendu pour cc
La sortie de ce compte rendu est la suivante :
Hostname: terran
Real memory size:
32,00 Mb
Time of day: Mon Apr 20 16:23:03 1992
Command: ccfoo
16,00 Mb.

Memory size
Avg. Pageins
Avg. Response Time
Avg. Pagein Rate
(megabytes)
(sec.)
(pageins / sec.)
16.00
0.0
0.4
0.0
14.00
0.0
0.4
0.0
12.00
0.0
0.4
0.0
10.00
0.0
0.4
0.0
8.00
0.5
0.4
1.2
6.00
786.0
13.5
58.4
Simulated final memory size.
Ce compte rendu montre que la modification est insuffisante. Les performances se

dgradent avec une machine de 6 Mo, mais restent sensiblement les mmes pour les tailles
suprieures. Nous pouvons raliser une nouvelle mesure avec une fourchette de tailles de
mmoire moins importante et un delta infrieur comme suit :
rmss s 11 f 5 d 1 n 2 ccfoo
Cela nous donne une image plus prcise de la courbe du temps de rponse du compilateur
pour ce programme :
Hostname: terran
Real memory size:
32,00 Mb
Time of day: Mon Apr 20 16:11:38 1992
Command: ccfoo
11,00 Mb.

Memory size
Avg. Pageins
Avg. Response Time
Avg. Pagein Rate
(megabytes)
(sec.)
(pageins / sec.)
11.00
0.0
0.4
0.0
10.00
0.0
0.4
0.0
9.00
0.5
0.4
1.1
8.00
0.0
0.4
0.0
7.00
207.0
3.7
56.1
6.00
898.0
16.1
55.9
5.00
1038.0
19.5
53.1
Simulated final memory size.
7-11
Compte rendu pour une copie distante de 16 Mo

Lexemple suivant prsente un compte rendu gnr (sur une machine client) en lanant
rmss sur une commande qui copie un fichier de 16 Mo depuis une machine distante
(un serveur) via NFS.
Hostname: xray.austin.ibm.com
Real memory size:
48.00 Mb
Time of day: Mon Aug 13 18:16:42 1990
Command: cp /mnt/a16Mfile /dev/null
48.00 Mb.

Memory size
Avg. Pageins
Avg. Response Time
Avg. Pagein Rate
(megabytes)
(sec.)
(pageins / sec.)
48.00
0.0
2.7
0.0
40.00
0.0
2.7
0.0
32.00
0.0
2.7
0.0
24.00
1520.8
26.9
56.6
16.00
4104.2
67.5
60.8
8.00
4106.8
66.9
61.4
Remarquez que le temps de rponse et le taux de transfert en mmoire de ce compte

rendu dmarrent avec une valeur assez basse, augmentent rapidement jusqu 24 Mo de
mmoire avant datteindre un palier 16 et 8 Mo. Ce compte rendu illustre limportance du
choix dune fourchette de mmoire assez large lors de lexploitation de rmss. Si lutilisateur
navait considr que les tailles de mmoire entre 24 et 8 Mo, il naurait pas eu lopportunit
daffecter suffisamment de mmoire pour que lapplication fonctionne sans transfert en
mmoire.
Compte rendu de find / ls >/dev/null
Lexemple suivant est un compte rendu gnr en lanant rmss sur le script shell
findbench.sh, comportant la commande find / ls > /dev/null, qui effectue un ls
de chaque fichier du systme. La commande lorigine du compte rendu est la suivante :
# rmss s 48 d 8 f 4.5 n 1 o find.out findbench.sh
La taille de la mmoire finale (4,5 Mo) a t choisie car cest la plus petite taille mmoire
accessible via rmss sur cette machine.
Hostname: xray.austin.ibm.com
Real memory size:
48.00 Mb
Time of day: Mon Aug 13 14:38:23 1990
Command: findbench.sh
48.00 Mb.

Memory size
Avg. Pageins
Avg. Response Time
Avg. Pagein Rate
(megabytes)
(sec.)
(pageins / sec.)
48.00
373.0
25.5
14.6
40.00
377.0
27.3
13.8
32.00
376.0
27.5
13.7
24.00
370.0
27.6
13.4
16.00
376.0
27.3
13.8
8.00
370.0
27.1
13.6
4.50
1329.0
57.6
23.1
Comme dans le premier exemple, les temps de rponse moyens et les valeurs du taux de
transfert en mmoire restent presque stables avec la diminution de la taille de la mmoire
jusqu 4,5 Mo, seuil partir duquel les deux paramtres augmentent normment.
Cependant, le taux de transfert en mmoire est relativement lev (presque 14 transferts/s)
partir de 48 Mo et jusqu 8 Mo. La conclusion est que, avec certaines applications,
aucune taille de mmoire nest dans la pratique suffisante pour liminer les transferts en
7-12
mmoire, car les programmes sont euxmmes trs consommateurs dE/S. Parmi les
programmes courants trs consommateurs dE/S, se trouvent les programmes qui balayent
ou accdent en mode alatoire de nombreuses pages de fichier trs volumineux.
Conseils dutilisation des indicateurs s, f, d, n et o
Lune des fonctions utiles de rmss, exploit de cette faon, est quil peut tre interrompu
(par la touche dinterruption, CtrlC, par dfaut) sans dtruire le compte rendu crit dans
le fichier de sortie. Outre lcriture du compte rendu dans le fichier sortie, rmss redfinit la
taille de la mmoire celle de la mmoire physique de la machine.
Vous pouvez lancer rmss en arrire-plan, mme aprs vous tre dconnect, via la
commande nohup. Pour ce faire, faites prcder la commande rmss de nohup, et
terminez la commande par un perlute (&) :
# nohup rmss s 48 f 8 o foo.out foo &
Rgles dexploitation de rmss

Quelle que soit la mthode utilise pour activer rmss, il est important de recrer
lenvironnement de lutilisateur final aussi prcisment que possible. Par exemple,
utilisez-vous le mme modle de CPU ? Le mme modle de disques ? Le mme rseau ?
Les utilisateurs disposeront-ils de fichiers dapplication monts depuis un nud distant via
NFS ou dun autre systme de fichiers distribu ? Ce dernier point est particulirement
important car les pages des fichiers distants ne sont pas traites de la mme faon par
VMM que celles des fichiers locaux.
De mme, il est prfrable dliminer toute activit systme qui nest pas lie la
configuration souhaite ou lapplication que vous souhaitez mesurer. Il convient, par
exemple, dinterdire dautres personnes de travailler sur la machine o rmss est actif,
sauf si elles traitent une partie de la charge de travail mesurer.
Remaque : Il est impossible de lancer plusieurs appels simultans de rmss.
Une fois toutes les excutions rmss termines, mieux vaut mettre le systme hors tension
et le ramorcer. Cette opration supprime toutes les modifications effectues par rmss sur
le systme et restaure les paramtres habituels de contrle de charge mmoire.
7-13
Optimisation du contrle de charge mmoire VMM

Lutilitaire de contrle de charge de mmoire VMM, dcrit page 2-8, permet dviter
lemballement des systmes surchargs, qui gnre une paralysie continue et dans laquelle
les processus du systme passent leur temps se voler des trames de mmoire et lire ou
crire des pages sur lunit de pagination.
Optimisation du contrle de charge mmoire

Le contrle de charge mmoire est conu pour aplanir les pointes de charge peu frquentes
qui aboutissent lemballement du systme. Il na pas pour objet de pallier en permanence
les dfaillances dun systme insuffisamment dot en RAM. Il sagit de la scurit du
rseau, ce nest pas un trampoline. La seule solution une insuffisance chronique,
persistante de RAM est dajouter de la RAM, et non de bricoler via le contrle de charge
mmoire des temps de rponse acceptables. Par contre, le contrle de charge mmoire
doit vraiment tre optimis dans les cas o la quantit de RAM est suprieure aux valeurs
par dfaut, cest--dire dans les configurations o les valeurs par dfaut sont trop
modres.
Ne modifiez pas les paramtres du contrle de charge mmoire sauf si la charge de travail
est importante et que les paramtres par dfaut risquent de ne plus suffire.
Les paramtres par dfaut dorigine du systme sont toujours en vigueur sauf sils ont t
modifis, alors que les paramtres modifis ne perdurent pas aprs un ramorage. Toutes
les activits doptimisation du contrle de charge mmoire doivent tre effectues par un
utilisateur root. Ladministrateur systme peut modifier des paramtres pour adapter
lalgorithme une charge de travail particulire ou les dsactiver entirement. Cest lobjet
de la commande schedtune. Le code source et objet de schedtune rsident dans
/usr/samples/kernel.
Attention : schedtune rside dans le rpertoire samples car il dpend troitement de
limplantation de VMM. Le code schedtune est propre chaque version dAIX : il a t
mis au point pour le VMM de cette version. Lexploitation dune version de schedtune
sur une autre version peut aboutir un incident du systme dexploitation. En outre, les
fonctions de schedtune peuvent varier dune version lautre. Il est dconseill dutiliser
des scripts shell ou des entres inittab comprenant schedtune sur une nouvelle version
sans consulter la documentation schedtune de cette nouvelle version. schedtune nest
pas pris en charge sous SMIT, et toutes les combinaisons de paramtres nont pas t
testes.
schedtune ? affiche une brve description des indicateurs et des options. schedtune
sans indicateur affiche les paramtres courants, comme suit :
h
SYS
6
THRASH
p
m
PROC MULTI
4
2
SUSP
w
e
WAIT GRACE
1
2
FORK
f
TICKS
10
SCHED
t
TIME_SLICE
0
(Les indicateurs f et t ne font pas partie du mcanisme de contrle de charge mmoire.

Les renseignements les concernant se trouvent avec la description de la syntaxe de
schedtune. Il est galement question de lindicateur t dans Modification de la tranche
horaire du programmateur, page 6-25.) Aprs un essai doptimisation, le contrle de
charge mmoire peut tre restaur ses valeurs par dfaut via schedtune D.
Pour dsactiver le contrle de charge mmoire, affectez une valeur au paramtre telle que
les processus ne soient jamais interrompus. Ainsi, schedtune h 0 affecte au seuil
demballement une valeur excessive : lalgorithme nen dtecte plus.
Dans certains cas, il est prfrable de dsactiver le contrle de charge mmoire ds le
dbut. Par exemple, si vous exploitez un mulateur de terminal avec fonction de
dpassement de dlai pour simuler une charge de travail multi-utilisateur, lintervention dun
contrle de charge mmoire peut retarder suffisamment les rponses pour que le processus
7-14
soit tu par cette fonction. Si vous lancez rmss pour connatre les effets de la diminution
des tailles de mmoire, il est prfrable de dsactiver le contrle de charge mmoire pour
viter quil ninterfre avec vos mesures.
Si la dsactivation du contrle de charge mmoire augmente le nombre de situations
demballement (avec un temps de raction amoindri), alors le contrle de charge mmoire
joue un rle actif de soutien dans le systme. Dans ce cas, loptimisation des paramtres de
contrle de charge mmoire ou lajout de mmoire RAM peut amliorer les
performances.
La dfinition du niveau de multiprogrammation minimum, m, vite aux m processus dtre
suspendus. Supposons quun administrateur systme sache quau moins dix processus
doivent toujours tre rsidants et actifs en RAM pour de bonnes performances, et
souponne le contrle de charge mmoire de suspendre les processus de faon trop
brutale. Si schedtune m 10 est lanc, le systme ne suspendra jamais tant de processus
que moins de dix processus restent en comptition pour accder la mmoire.
Le paramtre m ne tient pas compte du noyau, des processus fixs en RAM par lappel
systme plock, des processus priorit fixe une valeur infrieure 60 et ceux en
attente dvnements. La valeur par dfaut du systme m=2 permet dassurer que le noyau,
les processus fixs et deux processus utilisateurs feront toujours partie des processus en
comptition pour laccs la RAM.
La valeur m=2, adapte aux configurations mono-utilisateur de bureau, est souvent
insuffisante pour les configurations multiutilisateurs plus importantes ou les serveurs
disposant de grandes quantits de RAM. Sur ces systmes, affecter la valeur 4 ou 6 m
peut amliorer les performances.
Lorsque vous avez dtermin le nombre de processus susceptibles de fonctionner sur le
systme pendant les pics dactivit, ajoutez schedtune la fin du fichier /etc/inittab, pour
vous assurer quil sera bien excut chaque amorage du systme et que les paramtres
par dfaut seront restaurs. Par exemple, la ligne /etc/inittab suivante fait passer le niveau
minimum de multiprogrammation 4 sous AIX version 4.1 :
schedtune:2:wait:/usr/samples/kernel/schedtune m 4
La ligne /etc/inittab correspondante sous la version 3.2.5 serait :
schedtune:2:wait:/usr/lpp/bos/samples/schedtune m 4
Noubliez pas que cette ligne ne doit pas tre utilise sur une autre version dAIX sans
consultation pralable de la documentation.
Alors quil est possible de modifier les paramtres qui contrlent le nombre dinterruptions
des processus et le critre de slection des processus interrompre, il est impossible de
prvoir avec prcision leffet de telles modifications sur une configuration et une charge de
travail particulires. Le choix des paramtres par dfaut est dlicat et requiert des outils de
mesure sophistiqus et une observation attentive des charges de travail rcurrentes. Soyez
trs prudent si vous envisagez dajuster des paramtres de contrle de charge mmoire
autres que ceux dtaills ici.
7-15
Optimisation du remplacement de page VMM

Lalgorithme de gestion de la mmoire, dtaill page 2-5, tente de maintenir dans les limites
spcifies la taille de la liste des disponibilits et le pourcentage de mmoire relle occupe
par des pages de segment persistant. Ces limites peuvent tre modifies via la commande
vmtune, qui ne peut tre lance que par un utilisateur root.
Attention : vmtune rside dans le rpertoire samples car il dpend troitement de
limplantation de VMM. Le code vmtune qui accompagne chaque version dAIX a t
mis au point spcialement pour cette version de VMM. Lexploitation dune version de
vmtune sur une autre version peut aboutir un incident du systme dexploitation. En
outre, les fonctions de vmtune peuvent varier dune version lautre. Il est dconseill
de diffuser des scripts shell ou des entres inittab comprenant vmtune dans une
nouvelle version sans vrifier dans la documentation vmtune de la nouvelle version que
les scripts conservent leffet dsir.
Paramtres minfree et maxfree

Le but de la liste des disponibilits est de garder trace des trames de page de la mmoire
relle libres par la fin de lexcution des processus et de les fournir immdiatement aux
demandeurs, sans les obliger attendre le vol des pages ni la fin des E/S associes.
La limite minfree prcise la taille de la liste des disponibilits en-de de laquelle doit
commencer le vol de pages pour rapprovisionner la liste. maxfree est la taille au-del de
laquelle le vol prend fin.
Loptimisation de ces limites a les buts suivants :
assurer toute activit ayant des objectifs de temps de rponse critiques lobtention des
trames de page ncessaires dans la liste des disponibilits ;
viter au systme une surcharge dE/S suite des vols de pages prmaturs pour
tendre la liste des disponibilits.
Si vous disposez dune courte liste des programmes excuter rapidement, vous pouvez
dterminer leur besoin en mmoire via svmon (voir Quantit de mmoire utilise,
page 7-2), et affecter la plus grande taille minfree. Cependant, cette technique risque
dtre trop modre car toutes les pages utilises par un processus ne sont pas acquises
en une seule rafale. En outre, vous pouvez passer ct de demandes dynamiques issues
de programmes ne figurant pas dans la liste, mais qui peuvent diminuer la taille moyenne
de la liste des disponibilits lors de leur excution.
vmstat est un outil moins prcis mais plus complet pour dterminer la valeur approprie de
minfree. Vous trouverez ci-aprs un exemple de sortie vmstat 1 obtenu lors dune
compilation XLC sur un systme autrement inactif. La premire ligne a t conserve ;
notez quelle contient un rsum des mesures CPU ainsi que celles dautres activits, mais
pas de statistiques sur la mmoire courante.
procs
memory
page
faults

r b
avm
fre re pi po fr
sr cy in
sy cs
0 0 3085
118
0
0
0
0
0
0 115
2 19
0 0 3086
117
0
0
0
0
0
0 119 134 24
2 0 3141
55
2
0
6 24
98
0 175 223 60
0 1 3254
57
0
0
6 176 814
0 205 219 110
0 1 3342
59
0
0 42 104 249
0 163 314 57
1 0 3411
78
0
0 49 104 169
0 176 306 51
1 0 3528
160
1
0 10 216 487
0 143 387 54
1 0 3627
94
0
0
0 72 160
0 148 292 79
1 0 3444
327
0
0
0 64 102
0 132 150 41
1 0 3505
251
0
0
0
0
0
0 128 189 50
1 0 3550
206
0
0
0
0
0
0 124 150 22
1 0 3576
180
0
0
0
0
0
0 121 145 30
0 1 3654
100
0
0
0
0
0
0 124 145 28
1 0 3586
208
0
0
0 40
68
0 123 139 24
7-16
cpu
us sy id wa
0 0 99 0
1 3 96 0
3 9 54 34
22 14 0 64
43 16 0 42
30 15 0 55
50 22 0 27
57 9 0 34
82 8 0 11
79 11 0 11
94 6 0 0
96 4 0 0
91 8 0 1
91 9 0 0
Le compilateur nayant pas t excut rcemment, le code du compilateur luimme doit

tre charg. Le compilateur acquiert environ 2 Mo en 6 secondes environ. Sur ce systme
32 Mo, la valeur de maxfree est de 64 et celle de minfree de 56. Le compilateur amne
presque instantanment la taille de la liste des disponibilits en dessous de la valeur
minfree, et pendant quelques secondes une intense activit de vol de page est dploye.
Certains de ces vols requirent lcriture des pages de segment de travail modifies dans
lespace de pagination, comme indiqu dans la colonne po. Si ces vols occasionnent
lcriture de pages de segments permanents modifis, cette E/S napparat pas dans le
compte rendu vmstat (sauf si vmstat doit reporter les E/S du/des volume(s) physique(s)
dans lesquels sont crites les pages permanentes).
Le but de cet exemple nest pas de vous inciter dfinir minfree 500 pour prendre en
charge des compilations importantes. Il indique seulement comment exploiter vmstat pour
identifier les situations dans lesquelles la liste des disponibilits doit tre rapprovisionne
lorsquun programme est en attente despace. Dans ce cas, la dure dexcution du
compilateur a t allonge denviron 2 secondes, car le nombre de trames de page
immdiatement disponibles tait insuffisant. Si vous analysez la consommation en trames
de pages de votre programme, au cours de linitialisation ou du traitement normal, vous
aurez rapidement une ide du nombre de trames de page requises pour que le programme
nattende pas de mmoire.
Lors du choix de la taille de la liste des disponibilits pour la charge de travail interactive,
vous pouvez dfinir minfree via vmtune. maxfree doit tre suprieur minfree dau
moins 8 (ou de la valeur de maxpgahead, si elle est suprieure). Si nous concluons de
lexemple prcdent que minfree doit tre dfini 128, et que maxpgahead est dfini 16
pour amliorer les performances de laccs squentiel, nous devons lancer la commande
vmtune suivante qui gnre la sortie qui suit :
# /usr/lpp/bos/samples/vmtune f 128 F 144
minperm maxperm minpgahead maxpgahead minfree maxfree numperm
1392
5734
2
16
56
64
3106
number of memory frames = 8192
number of bad memory pages = 0
maxperm=70.0% of real memory
minperm=17.0% of real memory
1392
5734
2
16
128
144
3106
Paramtres minperm et maxperm

AIX profite de la variation des besoins en mmoire relle pour laisser en mmoire des
pages de fichiers dj lues ou crites. Ainsi, si des pages de fichier sont rclames
nouveau avant que leurs trames de page aient t raffectes, une opration dE/S est
vite. (Mme si une trame dune page de fichier a t vole et place dans la liste des
disponibilits, si cette page est rclame avant que la trame ne soit effectivement utilise
autre chose, elle sera rcupre dans la liste des disponibilits.) Ces pages de fichier
peuvent appartenir des systmes de fichiers locaux ou distants (NFS, par exemple).
Le rapport trames utilises pour les fichiers/trames utilises pour les segments de calcul
(textes de travail ou programme) est plus ou moins contrl par minperm et maxperm.
Pour une charge de travail particulire, il peut tre intressant de privilgier labsence dE/S
de fichiers. Pour une autre charge, la conservation de segments de calcul en mmoire peut
primer. Pour analyser ce rapport dans un environnement non optimis, lancez la commande
vmtune sans argument :
7-17
# vmtune
1433
5734
2
16
128
144
3497
Les valeurs par dfaut sont calcules par lalgorithme suivant :

minperm (en pages) =
0,2
maxperm (en pages) =
0,8
((nombre de trames de mmoire) 1024) *

((nombre de trames de mmoire) 1024) *
La colonne numperm donne le nombre de pages de fichier en mmoire, 3497, soit 42,7 %
de mmoire relle. Si la charge de travail exploite peu de fichiers rcemment lus ou crits, il
est possible de rduire la quantit de mmoire utilise cet effet. La commande :
# vmtune p 15 P 40
dfinit minperm 15 % et maxperm 40 % de mmoire relle. Cela permet dassurer que
VMM ne vole les trames des pages de fichier que lorsque le rapport pages de
fichier/mmoire totale dpasse 40 %. A linverse, si lapplication renvoie frquemment un
jeu rduit de fichiers existants (spcialement si ces fichiers font partie dun systme de
fichiers mont NFS), il est possible daffecter plus despace pour la mise en mmoire cache
locale des pages de fichier avec :
# vmtune p 30 P 60
Voir aussi
Commandes schedtune et vmtune.
7-18
Chapitre 8. Contrle et optimisation des E/S disque
Ce chapitre traite des performances des units de disques locales.

Si vous tes peu familier des concepts AIX de groupe de volumes, de volumes logiques et
physiques, et de partitions physiques, reportez-vous Gestion AIX du stockage sur disque
fixe : prsentation des performances, page 2-13.
Cette rubrique traite galement des points suivants :
Optimisation des lectures squentielles anticipes
Rgulation des E/S disque
Performances et rpartition des volumes logiques
Performances et taille de fragment du systme de fichiers
Performances et compression
Performances et E/S disque asynchrones
Performances et E/S disque brutes
Performances et sync/fsync
Modification du paramtre max_coalesce du pilote SCSI
Limites de la file dattente de lunit de disque et de la carte SCSI
Contrle du nombre de pbufs systme
Prinstallation
laboration dune base doptimisation
valuation des performances disque aprs installation
valuation du placement physique des donnes sur disque
Rorganisation dun groupe ou dun volume logique
Rorganisation dun systme de fichiers
Performances et espaces de pagination
Mesure des E/S disque globales via vmstat
Analyse dtaille des E/S via filemon
Programmes disque limit
Extension de la configuration
Prinstallation
La configuration des systmes de fichiers a un impact non ngligeable sur lensemble des
performances du systme et toute modification intervenant aprs linstallation prend
beaucoup de temps. Dcider du nombre et du type des disques fixes ainsi que de la taille et
du placement des espaces de pagination et des volumes logiques sur ces disques est de ce
fait une opration critique de la prinstallation.
Pour des prcisions sur la planification de la configuration des disques au moment de la
prinstallation, reportez-vous Prinstallation du disque page 4-24.
8-1
laboration dune base doptimisation

Avant toute modification de la configuration disque ou toute optimisation des paramtres, il
est bon de dfinir une base de mesures, qui permette denregistrer la configuration et les
performances actuelles. Outre vos propres mesures, vous pouvez crer une base
exhaustive laide du module PerfPMR. Reportez-vous Contrle avant modification,
page 2-14.
valuation des performances disque aprs installation

Commencez lvaluation en lanant iostat avec un paramtre intervalle, pendant une pointe
de charge ou lexcution dune application critique pour laquelle vous souhaitez minimiser
les dlais dE/S. Le script suivant excute iostat larrireplan tandis quun cp appliqu
un fichier volumineux est excut lavantplan, de sorte quil y a quelques E/S
mesurer:
$ iostat 5 3 >io.out &
$ cp big1 /dev/null
Ce qui gnre les trois relevs suivants dans io.out:
tty:
tin
0.0
Disks:
hdisk0
hdisk1
hdisk2
cd0
tout
3.2
% tm_act
0.0
0.1
0.2
0.0
cpu:
% user
0.2
% sys
0.6
Kbps
0.3
0.1
0.8
0.0
tps
0.0
0.0
0.1
0.0
msps
% idle
98.9
Kb_read
29753
11971
91200
0
% iowait
0.3
Kb_wrtn
48076
26460
108355
0
Le premier, rcapitulatif, indique lquilibre (ou ici le dsquilibre) global des E/S sur chaque
disque. hdisk1 est quasi inutilis alors que hdisk2 reoit prs de 63 % du total des E/S.
Le deuxime relev indique lintervalle de 5 secondes pendant lequel cp a t excut. Les
donnes doivent tre tudies avec attention. La dure dexcution de ce cp a t denviron
2,6 secondes. Ainsi, 2,5 secondes de haute activit dE/S ont t compenses par
2,5 secondes de temps inoccup pour arriver aux 39,5 % iowait relevs. Un intervalle
plus court aurait permis de caractriser plus prcisment la commande elle-mme, mais cet
exemple illustre les prcautions prendre lors de lexamen de relevs indiquant des
moyennes dactivit.
8-2
valuation du placement physique des donnes sur disque

Si la charge de travail se rvle trs dpendante des E/S, vous avez intrt examiner la
position physique des fichiers sur le disque pour dcider sil convient de les rorganiser.
Pour tudier lemplacement des partitions du volume logique hd11 dans le volume physique
hdisk0, utilisez :
$ lslv p hdisk0 hd11
lslv gnre :
hdisk0:hd11:/home/op
USED USED USED USED
USED USED USED USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
110
1117
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
1827
2834
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
3544
4550
USED
0052
USED
0053
USED
0054
USED
0055
USED
0056
USED
0057
USED
0058
USED
USED
USED
5160
6167
0059
0069
0060
0070
0061
0071
0062
0072
0063
0073
0064
0074
0065
0075
0066
0067
0068
6877
7884
Le mot USED signifie que la partition physique est utilise par un volume logique autre que
hd11. Les chiffres indiquent la partition logique de hd11 affecte cette partition physique.
Pour consulter le reste de hd11 sur hdisk1, entrez :
$ lslv p hdisk1 hd11
qui gnre :
hdisk1:hd11:/home/op
0035 0036 0037 0038
0045 0046 0047 0048
0039
0049
0040
0050
0041
0051
0042
0043
0044
110
1117
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
1827
2834
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
USED
3544
4550
0001
0011
0002
0012
0003
0013
0004
0014
0005
0015
0006
0016
0007
0017
0008
0009
0010
5160
6167
0018
0028
0019
0029
0020
0030
0021
0031
0022
0032
0023
0033
0024
0034
0025
0026
0027
6877
7884
Nous constatons que le volume logique hd11 est rparti sur le volume physique hdisk1,
ses premires partitions logiques se trouvant dans les zones mdianes-internes et internes
de hdisk1, et les partitions 35 51, dans les zones externes. Un travail qui accde hd11
de faon alatoire subit inutilement des attentes dE/S, tandis que laccesseur disque va et
vient entre les diffrentes zones de hd11. Ces relevs montent galement quil nexiste
aucune partition physique libre ni sur hdisk0 ni sur hdisk1.
8-3
Si nous examinons hd2 (volume logique contenant le systme de fichiers /usr) sur hdisk2
via :
$ lslv p hdisk2 hd2
nous dcouvrons quelques partitions physiques libres (FREE) :
hdisk2:hd2:/usr
USED USED USED
FREE FREE FREE
FREE FREE FREE
FREE FREE FREE
FREE
USED
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
110
1120
2130
3140
4141
USED
USED
FREE
FREE
FREE
USED
USED
FREE
FREE
USED
USED
FREE
FREE
USED
USED
FREE
FREE
USED
USED
FREE
FREE
USED
USED
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
4251
5261
6271
7281
8282
USED
0009
USED
0025
USED
0010
0016
0026
0001
0011
0017
0027
0002
0012
0018
0028
0003
0013
0019
0029
0004
0014
0020
0030
0005
0015
0021
0031
0006
USED
0022
0032
0007
USED
0023
0033
0008
USED
0024
0034
8392
93102
103112
113122
0035
0045
0055
0065
0075
0036
0046
0056
0066
0037
0047
0057
0067
0038
0048
0058
0068
0039
0049
0059
0069
0040
0050
0060
0070
0041
0051
0061
0071
0042
0052
0062
0072
0043
0053
0063
0073
0044
0054
0064
0074
123132
133142
143152
153162
163163
0076
0086
0096
FREE
FREE
0077
0087
0097
FREE
0078
0088
0098
FREE
0079
0089
0099
FREE
0080
0090
0100
FREE
0081
0091
FREE
FREE
0082
0092
FREE
FREE
0083
0093
FREE
FREE
0084
0094
FREE
FREE
0085
0095
FREE
FREE
164173
174183
184193
194203
204204
Ce relev prsente quelques diffrences intressantes par rapport aux prcdents.

Le volume logique hd2 est contigu, sauf pour quatre partitions physiques (100 103).
Dautres lslv (non indiqus) montrent que ces partitions servent hd1, hd3 et hd9var
(/home, /tmp et /var, respectivement).
Pour voir comment le fichier copi prcdemment, big1, est stock sur disque, vous
pouvez lancer la commande fileplace :
$ fileplace pv big1
Le relev correspondant est le suivant :
File: big1 Size: 3554273 bytes Vol: /dev/hd10 (4096 byte blks)
Inode: 19 Mode: rwxrxrx Owner: frankw Group: system
Physical blocks (mirror copy 1)
0158401591 hdisk0
8 blks,
0162401671 hdisk0
48 blks,
0172802539 hdisk0
812 blks,
32 KB,
192 KB,
3248 KB,
Logical blocks
0,9%
0104001047
5,5%
0108001127
93.5%
0118401995
956 blocks over space of 869: space efficiency = 90,8%

3 fragments out of 868 possible: sequentiality = 99,8%
Ce qui indique quil y a trs peu de fragmentation dans le fichier et que les trous sont
petits. Nous pouvons en dduire que le mode de stockage de big1 a une incidence quasi
nulle sur la dure de lecture squentielle. Mieux, en supposant quun fichier de 3,5 Mo
rcemment cr subisse cette lgre fragmentation, il apparat que lensemble du systme
de fichiers est lui-mme peu fragment.
Remarque : Si un fichier a t cr par recherche demplacements et criture darticles
trs disperss, seules les pages contenant des articles occupent de la place sur le
disque et apparaissent sur un relev fileplace. Le systme de fichiers ne remplit pas
8-4
automatiquement les pages concernes lorsque le fichier est cr. Si toutefois un fichier
de ce type est lu squentiellement, via la commande cp ou tar, par exemple, lespace
entre les articles est interprt comme des zros binaires. Aussi, le rsultat dune
commande cp peut-il tre bien plus grand que le fichier dentre, bien que la quantit de
donnes nait pas vari.
Sous AIX version 4.1, la commande fileplace est intgre la bote outils PTX
(Performance Toolbox for AIX). Pour savoir si fileplace est disponible, entrez :
Si le module est install, fileplace est disponible.
Rorganisation dun groupe ou dun volume logique

Si vous dcouvrez un volume suffisamment fragment pour ncessiter une restructuration,
vous pouvez faire appel smit pour excuter la commande reorgvg
(smit > Mmoire physique et logique > Gestionnaire de volumes logiques >
Groupes de volumes > Dfinition caractristiques dun groupe de volumes >
Rorganisation dun groupe de volumes). Le raccourci est :
# smit reorgvg
Lancer cette commande sur rootvg sur le systme test, sans spcifier de volumes
logiques, entrane la migration de tous les volumes logiques vers hdisk2. Aprs
restructuration, le rsultat de la commande :
$ lslv p hdisk2 hd2
tait :
hdisk2:hd2:/usr
USED USED USED
FREE FREE FREE
FREE FREE FREE
FREE FREE FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
FREE
110
1120
2130
3140
4141
USED
USED
FREE
FREE
FREE
USED
USED
FREE
FREE
USED
USED
FREE
FREE
USED
USED
FREE
FREE
USED
USED
FREE
FREE
USED
USED
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
USED
FREE
FREE
FREE
4251
5261
6271
7281
8282
USED
0009
0019
0029
USED
0010
0020
0030
0001
0011
0021
0031
0002
0012
0022
0032
0003
0013
0023
0033
0004
0014
0024
0034
0005
0015
0025
0035
0006
0016
0026
0036
0007
0017
0027
0037
0008
0018
0028
0038
8392
93102
103112
113122
0039
0049
0059
0069
0079
0040
0050
0060
0070
0041
0051
0061
0071
0042
0052
0062
0072
0043
0053
0063
0073
0044
0054
0064
0074
0045
0055
0065
0075
0046
0056
0066
0076
0047
0057
0067
0077
0048
0058
0068
0078
123132
133142
143152
153162
163163
0080
0090
0100
FREE
FREE
0081
0091
FREE
FREE
0082
0092
FREE
FREE
0083
0093
FREE
FREE
0084
0094
FREE
FREE
0085
0095
FREE
FREE
0086
0096
FREE
FREE
0087
0097
FREE
FREE
0088
0098
FREE
FREE
0089
0099
FREE
FREE
164173
174183
184193
194203
204204
La fragmentation des partitions physiques dans hd2, observe sur le relev prcdent, a
disparu. Nous navons toutefois affect aucune fragmentation au niveau du bloc physique
existant ventuellement dans le systme de fichiers /usr. Dans la mesure o la plupart des
fichiers dans /usr sont crits une fois, pendant linstallation du systme, et ne sont plus mis
jour ensuite, /usr a peu de chance de subir des fragmentations. Ce qui nest pas le cas
des donnes utilisateur dans le systme de fichiers /home.
8-5
Rorganisation dun systme de fichiers

Le systme test comporte un volume logique et un systme de fichiers, hd11 (point de
montage : /home/op), spars, destins aux tests risquant de dtruire des donnes.
Si vous dcidez de rorganiser hd11, commencez par sauvegarder les donnes :
# cd /home/op
# find . print | pax wf/home/waters/test_bucket/backuptestfile
Ces commandes crent un fichier de sauvegarde (dans un systme de fichiers distinct)
contenant tous les fichiers du systme rorganiser. Si lespace disque du systme est
limit, vous pouvez effectuer cette sauvegarde sur bande.
Pour reconstituer le systme de fichiers, vous devez au pralable lancer la commande
unmount, comme suit :
# unmount /home/op
Si des processus utilisent /home/op ou un de ses sous-rpertoires, ils doivent tre tus
(via kill) pour que unmount aboutisse.
Pour reconstituer le systme de fichiers sur le volume logique de /home/op, entrez :
# mkfs /dev/hd11
Une confirmation vous est demande, avant destruction de lancien systme de fichiers. Le
nom du systme de fichiers nest pas modifi. Pour revenir la situation antrieure
(/home/op tant nanmoins vid), entrez :
# mount /dev/hd11 /home/op
# cd /home/op
Restaurez ensuite les donnes :
# pax rf/home/frankw/tuning.io/backuptestfile >/dev/null
La sortie standard est rachemine vers /dev/null pour viter laffichage de tous le noms
de fichiers, affichage qui peut demander beaucoup de temps.
Si vous examinez nouveau le fichier volumineux examin prcdemment, via :
# fileplace piv big1
vous constatez quil est prsent presque contigu :
File: big1 Size: 3554273 bytes Vol: /dev/hd11 (4096 byte blks)
Inode: 8290 Mode: rwxrxrx Owner: frankw Group: system
INDIRECT BLOCK: 60307
Physical blocks (mirror copy 1)
6029960306 hdisk1
8 blks,
6030861167 hdisk1
860 blks,
32 KB,
3440 KB,
0,9%
99.1%
Logical blocks
0855508562
0856409423
868 blocks over space of 869: space efficiency = 99.9%

2 fragments out of 868 possible: sequentiality = 99.9%
Loption i spcifie avec la commande fileplace montre que le trou de 1 bloc, entre les huit
premiers blocs du fichier et le reste, contient le bloc indirect, requis pour complter les
informations di-node lorsque la longueur du fichier dpasse huit blocs.
8-6
Performances et espaces de pagination

Les E/S de et vers les espaces de pagination sont alatoires, effectues le plus souvent
une page la fois. Les relevs vmstat indiquent la quantit despace de pagination occup
par les E/S. Les deux exemples suivants montrent lactivit de pagination au cours dune
compilation C, sur une machine artificiellement restreinte via rmss. Les colonnes pi et po
(pages charges et pages dcharges de lespace de pagination) indiquent les E/S dans
lespace de pagination (exprimes en pages de 4096 octets) au cours de chaque intervalle
de 5 secondes. Le premier relev, rcapitulatif, a t supprim. Notez que lactivit de
pagination se produit par rafales.
$ vmstat 5
procs
memory
page
faults

r b
avm
fre re pi po fr
sr cy in
sy cs
0 0 2502
432
0
0
0
0
0
0 134
26 20
0 0 2904
201
4
0
7 43 1524
0 129 227 38
1 0 3043
136
0
0
0 17 136
0 117
46 24
1 0 3019
90
3
0
0
0
0
0 126
74 34
0 0 3049
178
2
0 15 28 876
0 148
32 32
1 0 3057
216
0
1
6 11
77
0 121
39 25
0 0 2502
599
2 15
0
0
0
0 142 1195 69
0 0 2502
596
0
0
0
0
0
0 135
30 22
cpu
us sy id wa
0 1 99 0
64 12 15 10
92 6 0 2
84 6 0 10
85 6 0 9
93 5 0 2
47 9 11 34
1 1 98 1
Les relevs avant et aprs vmstat s suivants indiquent les cumuls dactivits de
pagination. Noubliez pas que ce sont les valeurs de paging space page ins et
. . outs qui reprsentent lactivit dE/S relle. Les dcomptes (non qualifis) de
page ins et de page outs indiquent le total des E/S (dans lespace de pagination,
mais aussi E/S normales de fichiers galement traites par le mcanisme de pagination).
(Les informations ne relevant pas de notre propos ont t supprimes des relevs.)
$ vmstat s
.
6602 page ins
3948 page outs
544 paging space page ins
1923 paging space page outs
71 total reclaims
.
.
$ vmstat s
.
7022 page ins
4146 page outs
689 paging space page ins
2032 paging space page outs
84 total reclaims
.
.
Le fait quil y ait eu plus de pages dcharges que de pages charges au cours de la
compilation laisse supposer que le systme a t restreint la limite de son point
demballement. Certaines pages ont t rfrences deux fois car leur trame a t vole
avant la fin de leur utilisation (cest--dire avant toute modification).
Mesure des E/S disque globales via vmstat

La technique dcrite ci-dessus peut galement tre utilise pour valuer la charge dE/S
disque gnre par un programme. Si le systme est inoccup par ailleurs, la squence :
$
$
$
$
$
vmstat s >statout
testpgm
sync
vmstat s >> statout
egrep ins|outs statout
gnre un relev avant et aprs, indiquant les cumuls dactivits disque, tels que :
5698
5012
0
32
6671
5268
8
225
page ins
page outs
paging space
paging space
page ins
page outs
paging space
paging space
page ins
page outs
page ins
page outs
8-7
Au cours de la priode dexcution de la commande (compilation dun vaste programme C),

le systme a lu un total de 981 pages (dont 8 issues de lespace de pagination) et crit un
total de 449 pages (dont 193 dans lespace de pagination).
Analyse dtaille des E/S via filemon

La commande filemon fait appel lutilitaire de suivi pour gnrer une image dtaille de
lactivit dE/S au cours dun intervalle dfini. Dans la mesure o la commande filemon
invoque cet utilitaire, seul lutilisateur root ou un membre du groupe system est habilit
la lancer.
Sous AIX version 4.1, la commande filemon est intgre la bote outils PTX
(Performance Toolbox for AIX). Pour dterminer si filemon est disponible, entrez :
Si ce module est install, filemon est disponible.
Le suivi, lanc par la commande filemon, peut tre suspendu par trcoff, relanc par trcon
et arrt par trcstop. Ds que le suivi est termin, filemon en envoie le compte rendu
stdout. La squence suivante illustre lutilisation de filemon :
# filemon o fm.test.out ; cp smit.log /dev/null ; trcstop
Voici le relev gnr par cette squence (sur un systme inoccup par ailleurs) :
Wed Jan 12 11:28:25 1994
System: AIX alborz Node: 3 Machine: 000249573100
0.303 secs in measured interval
Cpu utilization: 55.3%
Most Active Segments
#MBs #rpgs #wpgs segid segtype

volume:inode
0.1
26
0
0984 persistent
/dev/hd1:25
0.0
1
0
34ba .indirect
/dev/hd1:4
Most Active Logical Volumes
util #rblk #wblk

KB/s volume
description
0.66
216
0 357.0 /dev/hd1
/home
Most Active Physical Volumes
util #rblk #wblk

KB/s volume
description
0.65
216
0 357.0 /dev/hdisk1
320 MB SCSI
Detailed VM Segment Stats

(4096 byte pages)
SEGMENT: 0984 segtype:

segment flags:
reads:
read times (msec):
read sequences:
read seq. lengths:
SEGMENT: 34ba segtype:
segment flags:
reads:
read times (msec):
read sequences:
read seq. lengths:
persistent volume: /dev/hd1 inode: 25

pers
26
(0 errs)
avg 45.644 min
9.115 max 101.388 sdev
3
avg
8.7 min
1 max
22 sdev
.indirect volume: /dev/hd1 inode: 4
pers jnld sys
1
(0 errs)
avg 16.375 min 16.375 max 16.375 sdev
1
avg
1.0 min
1 max
1 sdev
33.045
9.5
0.000
0.0
Detailed Logical Volume Stats

(512 byte blocks)
8-8
VOLUME: /dev/hd1 description: /home

reads:
27
(0 errs)
read sizes (blks):
avg
8.0 min
8 max
8 sdev
0.0
read times (msec):
avg 44.316 min
8.907 max 101.112 sdev 32.893
read sequences:
12
read seq. lengths:
avg
18.0 min
8 max
64 sdev
15.4
seeks:
12
(44.4%)
seek dist (blks):
init
512
avg
312.0 min
8 max
1760 sdev
494.9
time to next req(msec): avg
8.085 min
0.012 max 64.877 sdev 17.383
throughput:
357.0 KB/sec
utilization:
0.66
Detailed Physical Volume Stats

(512 byte blocks)
VOLUME: /dev/hdisk1 description: 320 MB SCSI

reads:
14
(0 errs)
read sizes (blks):
avg
15.4 min
8 max
read times (msec):
avg 13.989 min
5.667 max
read sequences:
12
read seq. lengths:
avg
18.0 min
8 max
seeks:
12
(85.7%)
seek dist (blks):
init 263168,
avg
312.0 min
8 max
seek dist (cyls):
init
399
avg
0.5 min
0 max
time to next req(msec): avg 27.302 min
3.313 max
throughput:
357.0 KB/sec
utilization:
0.65
32 sdev
25.369 sdev
8.3
5.608
64 sdev
15.4
1760 sdev
494.9
2 sdev
64.856 sdev
0.8
22.295
Le relev Most Active Segments donne la liste des fichiers les plus actifs. Pour
identifier les fichiers inconnus, vous pouvez traduire le nom du volume logique, /dev/hd1,
vers le point de montage du systme de fichiers, /home, et lancer la commande find :
# find /home inum 25 print
qui renvoie :
/home/waters/smit.log
Lancer filemon sur des systmes traitant de vritables travaux gnre des relevs bien
plus longs, avec lventualit de devoir agrandir lespace du tampon de suivi.
La consommation despace et de temps CPU par filemon peuvent entraner une srieuse
dgradation des performances : testez filemon sur un systme non productif avant de vous
aventurer sur un systme rellement exploit.
Remarque : Bien que filemon indique la moyenne, le minimum, le maximum et la
dviation standard dans ses rubriques relatives aux statistiques, ces rsultats ne
peuvent servir de base la dfinition dintervalles fiables ou dautres conclusions
statistiques formelles. La rpartition des points de donnes nest en gnral ni alatoire
ni symtrique.
Programmes disque limit

Les problmes lis au disque sont de diffrents ordres, avec des solutions diversifies :
Si de vastes travaux en arrire-plan, trs consommateurs dE/S, interfrent avec les
temps de rponses interactives, vous pouvez activer la rgulation dE/S.
Sil apparat quun petit nombre de fichiers sont lus et relus rptition, envisagez
dajouter de la mmoire relle pour que la mise en tampon de ces fichiers soit plus
efficace.
Si iostat indique que les activits dE/S sont ingalement rparties sur les units de
disque et que lune de ces units accuse une charge dpassant 70 80 %, envisagez de
rorganiser le systme de fichiers.
8-9
Si les accs sont essentiellement de type alatoire, envisagez dajouter des disques et
de mieux rpartir les fichiers concerns.
Si les accs effectus par le travail sont majoritairement squentiels et impliquent
plusieurs units de disque, envisagez dajouter une ou plusieurs cartes disque. Il peut
tre intressant de construire un volume logique rparti, pour les fichiers squentiels
volumineux dont les performances sont critiques.
La section suivante donne plus de prcisions sur les ratios units/cartes disque.
Extension de la configuration
Malheureusement, toute opration doptimisation des performances a des limites. La
question devient alors : De quel matriel aije besoin, en quelle quantit et comment en
tirer le maximum ? La question est particulirement pineuse avec des travaux limits au
niveau des disques, du fait du nombre de variables. Pour amliorer les performances de ce
type de travaux, vous pouvez :
Ajouter des units de disque et y rpartir les donnes : la charge des E/S est ainsi
divise entre davantage daccesseurs.
Acqurir des units de disque plus rapides pour complter ou remplacer les units
existantes, pour les donnes trs sollicites.
Ajouter une ou plusieurs cartes disque SCSI pour connecter les units nouvelles et/ou
existantes.
Ajouter de la RAM au systme et augmenter les valeurs des paramtres VMM minperm
et maxperm pour amliorer la mise en mmoire cache des donnes trs sollicites.
Vu la complexit de la question, troitement lie limportance de la charge de travail et de
la configuration, et vu la rapidit dvolution de la vitesse des disques, des cartes et des
processeurs, nous ne vous donnerons pas ici de consignes prcises, mais de simples
conseils de base.
Si vous cherchez optimiser les accs squentiels :
Ne raccordez pas plus de trois units (nouvelles) de 1 Go une carte disque SCSI2
donne.
Les performances maximales dune carte disque SCSI2, en traitement squentiel
continu, dans des conditions idales, sont denviron 6,8 Mo/s.
Si vous cherchez optimiser les accs squentiels :
Ne raccordez pas plus de six units (nouvelles) de 1 Go une carte disque SCSI2
donne.
Les performances maximales dune carte disque SCSI2, en traitement alatoire (sur
des pages de 4 ko) continu, dans des conditions idales, sont denviron 435 pages/s.
Pour obtenir une analyse plus fine de votre configuration et de votre charge de travail, vous
pouvez utiliser un simulateur, tel BEST/1.
Voir aussi
Commandes backup, fileplace, lslv, lsps, lspv, reorgvg, smit et unmount.
Position et taille des espaces de pagination
8-10
Optimisation des lectures squentielles anticipes

La fonction VMM de lecture squentielle anticipe, dcrite Lecture squentielle
anticipe, peut amliorer les performances des programmes accdant squentiellement
des fichiers volumineux.
Les cas o lactivation de cette fonction amliore les performances sont rares. Nanmoins,
lanalyste des performances doit comprendre linteraction entre cette fonction et lapplication
ainsi quavec les autres paramtres doptimisation des E/S disque. La figure Exemple de
lecture squentielle anticipe illustre une situation classique.
Donnes
rf.
B C
F
...
numro
page
1 2 3
15 16
23
Exemple de lecture squentielle anticipe
Dans cet exemple, minpgahead a la valeur 2 et maxpgahead, la valeur 8 (valeurs par

dfaut). Le programme traite le fichier squentiellement. Seules les rfrences des donnes
significatives pour la fonction de lecture anticipe sont illustres (A F). Les tapes sont les
suivantes :
A
Le premier accs au fichier provoque la lecture de la premire page (page 0)

de ce fichier. A ce niveau, VMM ne fait aucune hypothse sur la nature de
laccs (squentiel ou alatoire).
Lorsque le programme accde au premier octet de la page suivante (page 1),

sans autre accs aux autres pages du fichier, VMM conclut un accs
squentiel. Il programme la lecture de minpgahead (2) pages (pages 2 et 3).
Laccs B entrane ainsi la lecture de 3 pages.
Lorsque le programme accde au premier octet de la premire page lue par

anticipation (page 2), VMM double la valeur du nombre de pages lire par
anticipation (qui passe 4) et programme la lecture des pages 4 7.

anticipation (page 4), VMM double la valeur du nombre de pages lire par
anticipation (qui passe 8) et programme la lecture des pages 8 15.

anticipation (page 8), VMM dtermine que le nombre de pages lire par
anticipation a atteint la valeur de maxpgahead et programme la lecture des
pages 16 23.
VMM poursuit la lecture de maxpgahead pages lorsque le programme accde

au premier octet du groupe prcdent des pages lire par anticipation, jusqu
la fin du fichier.
(Si le programme passe en cours de route un autre type daccs, la fonction
de lecture anticipe est arrte. Elle est relance avec minpgahead pages si
VMM dtecte une reprise des accs squentiels par le programme.)
Les paramtres minpgahead et maxpgahead peuvent tre modifis via la commande

vmtune. Si vous envisagez de le faire, noubliez pas que :
Les valeurs doivent appartenir lensemble : 0, 1, 2, 4, 8, 16. Toute autre valeur peut
avoir leffet inverse de celui escompt ou des effets fonctionnels non souhaits.
Les valeurs doivent tre des puissances de 2, du fait de lalgorithme de doublement.
Les valeurs de maxpgahead suprieures 16 (lecture anticipe de plus de 64 ko)
excdent la capacit de certains pilotes de disque.
8-11
Des valeurs suprieures de maxpgahead peuvent tre utilises sur des systmes o
les performances en mode squentiel des volumes logiques rpartis sont dune
importance capitale.
Donner minpgahead la valeur 0 annihile de fait le mcanisme. Ce qui peut avoir de
fcheuses consquences sur les performances.
La valeur par dfaut (8) de maxpgahead est celle qui entrane les performances
maximales des E/S squentielles pour les units de disque courantes.
Le passage de la valeur de lecture anticipe de minpgahead maxpgahead est
suffisamment rapide : pour les fichiers de taille courante, il ny a aucun intrt
augmenter la valeur de minpgahead.
8-12
Rgulation des E/S disque

La rgulation des E/S disque a pour but dempcher les programmes gnrant beaucoup
de sorties de saturer les fonctions dE/S du systme et de ralentir les temps de rponse des
programmes peu demandeurs. La rgulation des E/S force les niveaux haut et bas par
segment (cest--dire, en fait, par fichier) la somme des E/S en attente. Lorsquun
processus tente dcrire dans un fichier dont le niveau dcriture en attente est au plus haut,
le processus est mis en veille jusqu ce que le nombre dE/S en attente redevienne
infrieur ou gal au niveau bas. La logique de traitement des E/S reste identique. Seules les
sorties issues de processus gnrateurs de volumes levs sont quelque peu ralenties. Les
niveaux haut et bas sont dfinis via smit par les options Environnements systme et
processus > Modif/affich caractristiques du systme dexploitation (et entre du
nombre de pages correspondant aux deux niveaux). Leur valeur par dfaut est de 0, ce qui
dsactive la rgulation. Les nouvelles valeurs des paramtres de rgulation prennent
normalement effet immdiatement et restent en vigueur jusqu nouvelle modification.
Exemple
Leffet de la rgulation sur les performances peut tre tudi en lanant une session vi sur
un nouveau fichier, tandis quun autre processus copie (via cp) un fichier de 64 Mo. La
copie a lieu du disk1 vers le disk0 et lexcutable vi rside sur le disk0. Pour que la
session vi dmarre, elle doit se charger ellemme et effectuer quelques autres E/S, ce
quelle effectue en mode alatoire, une page la fois. Cette opration mobilise environ
50 E/S physiques, qui peuvent tre termines en 0,71 secondes, sous rserve quil ny ait
de concurrence pour laccs au disque. Si le niveau haut est dfini 0 (valeur par dfaut),
les critures logiques rsultant de cp passent avant les critures physiques et une longue
file dattente se construit. Chaque E/S initie par vi doit attendre son tour dans la file avant
que lE/S suivante puisse tre mise et vi ne peut ainsi pas dmarrer avant la fin de cp.
La figure Rsultats dun test de rgulation dE/S illustre les dlais dexcution de cp et
dinitialisation de vi avec diffrents paramtres de rgulation. Cette tude a t effectue
sur un Modle 530 quip de deux disques de 857 Mo et de 32 Mo de mmoire vive.
Niveau
haut
Niveau
bas
cp (s)
vi (s)
0
0
0
0
50
50,2
9
17
17
33
33
6
12
8
24
16
76.8
57.9
63.9
52.0
55.1
vi non fait
vi termin aprs cp
est termin
2.7
3.6
3.4
9.0
4.9
Rsultats dun test de rgulation dE/S

Notez que la dure de cp est toujours plus leve lorsque la rgulation est active.
La rgulation sacrifie quelques sorties de programmes trs consommateurs dE/S pour
amliorer les temps de rponse dautres programmes. La difficult pour un administrateur
est de trouver un quilibre dbit/temps de rponse qui rponde aux priorits de lentreprise.
Les niveaux haut et bas ont t choisis par ttonnements et erreurs, sur la base de notre
connaissance du chemin des E/S. Ce choix nest pas simple du fait de la combinaison des
critures diffres et asynchrones. Les niveaux hauts de la forme 4x + 1 sont
particulirement efficaces, car :
La fonction dcriture diffre envoie sur disque les 4 pages prcdentes lorsquune
criture logique a lieu sur le premier octet de la cinquime page.
8-13
Si le niveau haut de rgulation tait un multiple de 4 (disons 8), un processus latteindrait

lorsquil demande une criture qui stend jusqu la 9me page. Il serait alors mis en
veille avant que lalgorithme dcriture diffre ait la moindre chance de dtecter que la
quatrime page utilise est termine et que les quatre pages sont prtes tre crites.
Le processus sera alors maintenu en veille avec quatre pages pleines prtes sortir,
jusqu ce que le niveau de ses critures passe en dessous du niveau bas de rgulation.
Si, par ailleurs, le niveau haut a t dfini 9, lcriture diffre va avoir programmer
les quatre pages pour la sortie avant que le processus ne soit suspendu.
Une des limites de la rgulation intervient lorsquun processus crit dans des tampons de
taille suprieure 4 ko, auquel cas le contrle possible baisse singulirement.
Si, lorsquune criture est envoye VMM, le niveau haut na pas t atteint, VMM excute
un lancement des E/S sur toutes les pages du tampon, mme sil en rsulte un
dpassement du niveau haut. La rgulation fonctionne bien sur cp car cette commande
crit par tranches de 4 ko, mais si cp crivait dans des tampons plus grands, les dlais
illustrs la figure Rsultats du test de rgulation des E/S pour le lancement de vi
seraient suprieurs.
Niveau
haut
Niveau
bas
cp (s)
vi (s)
0
0
0
0
50
50,2
9
17
17
33
33
6
12
8
24
16
76.8
57.9
63.9
52.0
55.1
vi non fait
vi termin aprs cp
est termin
2.7
3.6
3.4
9.0
4.9
Rsultats dun test de rgulation dE/S

La rgulation des E/S disque est un paramtre doptimisation qui peut amliorer les temps
de rponse interactifs dans le cas o des programmes (en avant ou arrire-plan) qui
crivent dimportants volumes interfrent avec des requtes en avant-plan. Mal utilise, elle
peut linverse rduire le dbit de faon excessive. Les paramtres de la figure Rsultats
du test de rgulation des E/S constituent une bonne base de dpart, mais seule
lexprience vous aidera dterminer les paramtres adapts votre charge de travail.
Parmi les programmes susceptibles dimposer dactiver la rgulation des E/S, citons :
Les programmes gnrant par algorithmes de forts volumes de sorties et ne subissant de
ce fait aucune contrainte quant la dure de la lecture : une rgulation peut tre
ncessaire sur des processeurs rapides et pas sur des processeurs lents.
Les programmes crivant de longs fichiers peu modifis, peu de temps aprs leur lecture
intgrale (par une commande antrieure, par exemple).
Les filtres, telle la commande tar, qui lisent un fichier et le rcrivent aprs un traitement
minimal. Le besoin de rgulation est dautant plus pressant si lentre est lue partir
dune unit de disque plus rapide que lunit sur laquelle est crite la sortie.
8-14
Performances et rpartition des volumes logiques

La rpartition en bandes est une technique qui consiste distribuer les donnes dun
volume logique sur plusieurs units de disque, de sorte que la capacit dE/S des disques
puisse tre exploite en parallle pour laccs aux donnes du volume logique. (La fonction
de cration de volumes logiques rpartis en bandes nest pas disponible sous la version
3.2.5.) Le but principal de lopration est daccrotre les performances au niveau de la
lecture et de lcriture de longs fichiers squentiels. La figure Volume logique rparti
/dev/lvs0 en donne un exemple.
carte disque
premire
partition
logique
lment 1
lment 2
lment 3
premire bande
lment 4
...
lment 5
...
lment 6
...
deuxime bande
lment n
lment n+1
lment n+2
lment n+3
lment n+4
lment n+5
premier
volume
physique
premier
volume
physique
deuxime
volume
physique
.
.
.
deuxime partition logique
Volume logique rparti /dev/lvs0

Sur un volume logique classique, les adresses des donnes correspondent la squence
de blocs de la partition physique sous-jacente. Sur un volume logique rparti en bandes,
ces adresses suivent la squence des lments de bande. Une bande complte est
constitue dun lment par unit physique contenant une partie du volume logique rparti.
Le LVM dtermine les blocs et les units physiques correspondant au bloc en cours de
lecture ou dcriture. Si plusieurs disques sont concerns, les E/S requises sont
programmes simultanment pour toutes les units.
Par exemple, supposons que lvs0 est constitu dlments de bande de 64 ko, est
compos de six partitions de 2 Mo et contient un systme de fichiers journalis (JFS).
Si une application est en cours de lecture dun fichier squentiel long et que la lecture
anticipe a atteint un point de stabilit, chaque lecture va entraner la programmation de
deux ou trois E/S vers chaque unit de disque, pour un total de huit pages (en supposant
que le fichier se trouve sur des blocs conscutifs du volume logique). Les oprations de
lecture sont excutes dans lordre dtermin par le pilote de lunit de disque.
Les donnes requises sont reconstitues partir des diffrents lments des entres et
retournes lapplication.
Bien que chaque unit de disque ait un dlai de latence initial diffrent, fonction de la
position du mcanisme daccs au dbut de lopration, une fois que le processus a atteint
un tat stable, les trois disques procdent aux lectures une vitesse proche de leur vitesse
maximale.
8-15
Conception dun volume logique rparti

Pour dfinir un volume logique rparti, vous spcifiez :
units
A lvidence, il faut disposer dau moins deux disques physiques. Les

units choisies doivent en outre tre peu charges dautres activits au
moment des E/S squentielles critiques.
Certaines combinaisons de carte/unit de disque ncessitent de diviser
la charge de travail dun volume logique rparti entre deux ou plusieurs
cartes.
taille dlment Bien quen thorie toute puissance de 2 comprise entre 4 et 128 ko
de bande
convienne, vous devez tenir compte des lectures anticipes, puisque la
plupart des lectures passeront par ce mcanisme. Lobjectif est que
chaque lecture anticipe gnre au moins une E/S sur chaque unit de
disque (idalement un nombre gal).
taille
Le nombre de partitions physiques affectes au volume logique doit tre

un multiple du nombre de disques utiliss.
attributs
Ne peuvent tre mis en miroir, cest--dire que copies = 1.
Optimisation des E/S dun volume logique rparti

Dans des situations dvaluation, les techniques suivantes ont gnr les plus forts dbits
dE/S squentielles :
Taille dlment de bande de 64 ko.
max_coalesce de 64 ko (valeur par dfaut). gal la taille dun lment de bande.
minpgahead de 2.
maxpgahead de 16 fois le nombre dunits de disque. Ceci entrane la lecture anticipe
de page par units de la taille dun lment de bande (64 ko) multipli par le nombre
dunits de disque. Chaque lecture anticipe provoque donc la lecture dun lment de
bande de chaque unit de disque.
Requtes dE/S pour (64 ko fois le nombre dunits de disque). Egal la valeur de
maxpgahead.
Modification de maxfree en fonction de celle de maxpgahead. Reportezvous
Paramtres minfree et maxfree, page 7-16.
Tampons dE/S aligns sur 64 octets. Si le volume logique doit occuper des units
physiques connectes au moins deux cartes disque, les tampons dE/S utiliss doivent
tre affects dans la limite de 64 octets. Ceci pour viter que le LVM ne srialise les E/S
sur les diffrents disques. Le code suivant gnre un pointeur de tampon align sur
64 octets :
char *buffer;
buffer = malloc(MAXBLKSIZE+64);
buffer = ((int)buffer + 64) & ~0x3f;
Si les volume logiques rpartis se trouvent sur des volume logiques bruts et que des
critures de plus de 1,125 Mo sont effectues sur ces volumes logiques bruts rpartis,
augmenter le paramtre lvm_bufcnt de vmtune peut augmenter le dbit des critures.
8-16
Performances et taille de fragment du systme de fichiers

La fonction de fragmentation (AIX version 4.1 seulement) permet daffecter lespace dun
systme de fichiers par tranches infrieures 4 ko. A la cration dun systme de fichiers,
ladministrateur systme peut spcifier la taille de ces fragments : 512, 1024, 2048 et
4096 octets (valeur par dfaut). Les fichiers plus petits quun fragment sont stocks dans un
seul fragment, conomisant ainsi de lespace, ce qui est le but premier de lopration.
Les fichiers de taille infrieure 4096 octets sont stocks dans le minimum ncessaire de
fragments contigus. Les fichiers de taille comprise entre 4096 octets et 32 ko (inclus) sont
stocks dans un ou plusieurs blocs entiers (4 ko) et dans autant de fragments que requis
pour contenir le reste. Les fichiers de plus de 32 ko sont stocks entirement dans des
blocs complets.
Quelle que soit la taille dun fragment, un bloc complet est suppos contenir 4096 octets.
Si, toutefois, la taille de fragment dun systme de fichiers est infrieure 4096, un bloc
peut tre constitu dune squence quelconque de fragments contigus totalisant
4096 octets. Il ne doit pas ncessairement commencer la limite dun multiple de
4096 octets.
Le systme de fichiers tente daffecter aux fichiers des fragments contigus. Dans cette
optique, il rpartit les fichiers dans le volume logique pour viter les interfrences
daffectation inter-fichiers et la fragmentation.
Le principal cueil qui guette les systmes de fichiers dots dune taille de fragment minime
est la fragmentation de lespace. La prsence de petits fichiers dissmins au sein du
volume logique rend difficile, voire impossible, laffectation de blocs contigus ou mme
simplement proches dun fichier quelque peu volumineux. Laccs ce type de fichiers
devient moins performant. Pousse lextrme, la fragmentation de lespace peut rendre
impossible laffectation despace un fichier, mme sil existe suffisamment de fragments
isols libres.
Une part de la dcision de crer un systme de fichier avec de petits fragments doit tre
une stratgie de dfragmentation de lespace dans ce systme de fichiers via la commande
defragfs. Cette stratgie doit galement tenir compte du cot de performance induit par
lexcution de defragfs.
8-17
Performances et compression
Lorsquun fichier est crit dans un systme de fichiers pour lequel la compression est
active, lalgorithme correspondant comprime les donnes par tranches de 4 096 octets
(une page) et crit les donnes compresses dans le minimum de fragments contigus.
A lvidence, si la taille de fragment du systme de fichiers est de 4 ko, il ny a pas de gain
despace disque compensant leffort de compression des donnes. (La compression et les
fragments de taille infrieure 4 ko sont une nouveaut de AIX version 4.1.)
Bien que la compression gnre un gain despace, il convient toutefois de mnager un peu
despace libre dans le systme de fichiers.
En effet, dans la mesure o le degr de compression de chaque bloc de 4096 octets
nest pas connu lavance, le systme de fichiers commence par rserver un bloc entier.
Les fragments inutiliss sont librs aprs la compression, mais la rservation initiale
peut entraner un message de type manque despace prmatur.
Il faut de lespace pour lexcution de la commande defragfs.
8-18
Performances et E/S disque asynchrones

Les applications peuvent appeler les sous-routines aio_read et aio_write pour effectuer
des E/S disque asynchrones. Le contrle revient lapplication ds que la requte est mise
en file dattente. Celle-ci peut alors continuer le traitement pendant lexcution des
oprations sur disque.
Bien que lapplication puisse poursuivre le traitement, un processus noyau (kproc) appel
serveur prend en charge chaque requte depuis le moment o elle est extraite de la file
dattente jusqu la fin de son excution. Le nombre de serveurs limite le nombre dE/S
disque asynchrones excutables simultanment. Le nombre de serveurs est dfini via smit
(smit>Units>E-S asynchrones>Modif/affich caractristiques dE-S
asynchrones>{MINIMUM|MAXIMUM} nombre de serveurs ou smit aio) ou via chdev.
Le nombre minimal de serveurs est le nombre de serveurs lancer lamorage du
systme. Le maximum limite le nombre de serveurs qui peuvent tre dmarrs en rponse
un grand nombre de requtes simultanes.
Les valeurs par dfaut sont minservers=1 et maxservers=10. Sur les systmes o peu
dapplications font appel des E/S asynchrones, ces valeurs conviennent gnralement.
Dans un environnement riche en units de disque et en applications cls qui utilisent des
E/S asynchrones, ces valeurs par dfaut sont largement insuffisantes. Le dficit de serveurs
entrane un ralentissement apparent des E/S disque. Non seulement le temps pass par les
requtes dans la file dattente est dmesur, mais la faiblesse du ratio serveurs/units de
disque signifie que les algorithmes doptimisation des recherches disposent de trop peu de
requtes exploiter pour chaque unit de disque.
Dans les environnements o les performances au niveau des E/S disque asynchrones sont
capitales et le volume des requtes lev, nous vous conseillons de :
donner maxservers une valeur au moins gale 10*(nombre de disques dont laccs
est asynchrone)
donner minservers la valeur de maxservers/2.
Pour un systme quip de 3 disques dont laccs est asynchrone, vous pouvez cet effet
lancer la commande :
# chdev l aio0 a minservers=15 a maxservers=30
Remarque : Les actions AIO effectues sur un volume logique RAW ne font pas appel
aux processus serveur kproc. En loccurrence, les paramtres maxservers et
minservers nont aucun effet.
8-19
Performances et E/S disque brutes

Un programme dispose de trois moyens pour accder un disque en mode brut :
Les fichiers spciaux dunits disque brutes par bloc sont dots de noms de la forme
/dev/hdiskn et sont utiliss par certains sous-systmes. Ces units ne doivent pas tre
exploites par les programmes dapplication.
Les fichiers spciaux dunits disque brutes par caractre sont dots de noms de la
forme /dev/rhdiskn. Lexploitation de ces units par les programmes dapplication est
dconseille. Si vous dcidez nanmoins dadopter cette technique, vrifiez quaucun
volume logique AIX noccupe une partie de lunit de disque physique en cours daccs.
Leffet sur les performances de linteraction entre accs brut et accs du type systme de
fichiers la mme unit physique est imprvisible. Assurezvous de ne pas craser les
512 premiers octets du disque puisque cest l quest enregistr lID du volume physique.
Il est possible daccder en mode brut un volume logique sur lequel aucun systme de
fichiers na t cr. Toutes les oprations write, read, lseek, etc., doivent tre
effectues sur des multiples de 512 octets. Violer cette rgle a pour consquence, entre
autres, une trs nette dgradation des performances.
8-20
Performances et sync/fsync
La synchronisation force du contenu de la mmoire relle et des disques sopre de
diffrentes faons :
Un programme dapplication effectue un appel fsync() pour un fichier donn : toutes les
pages contenant des donnes modifies pour ce fichier sont alors crites sur disque.
Lcriture prend fin lorsque lappel fsync() revient au programme.
Un programme dapplication effectue un appel sync() : toutes les pages du fichier en
mmoire contenant des donnes modifies sont alors programmes pour une criture
sur disque. Lcriture ne prend pas ncessairement fin lorsque lappel sync() revient au
programme.
Un utilisateur lance la commande sync, laquelle son tour met un appel sync().
L aussi, certaines critures peuvent ne pas tre termines lorsque lutilisateur est invit
entrer une autre commande (ou que la commande suivante dun script shell est traite).
Le dmon sync, /usr/sbin/syncd, lance un appel sync() intervalle rgulier
gnralement de 60 secondes. Ceci garantit que le systme naccumule pas de
grandes quantits de donnes existant uniquement en RAM volatile.
Outre une faible consommation de CPU, une synchronisation :
regroupe les critures au lieu de les parpiller ;
crit au moins 28 ko de donnes systme, mme en labsence dactivit dE/S depuis la
dernire synchronisation ;
acclre lcriture des donnes sur disque, en annulant lalgorithme dcriture diffre.
Cet effet est particulirement visible sur les programmes qui mettent un fsync() aprs
chaque criture.
8-21
Modification du paramtre max_coalesce du pilote SCSI

Si la file dattente de lunit de disque SCSI contient un grand nombre de requtes dE/S
disque, lunit tente de les fusionner pour en diminuer le nombre. La taille maximale de
requte (en termes de donnes transmises) que lunit SCSI est autorise constituer est
dfinie par le paramtre max_coalesce. Normalement, max_coalesce a la valeur 64 ko.
Pour exploiter au maximum les volumes logiques rpartis et les piles de disques, il peut tre
souhaitable daugmenter la valeur de max_coalesce. Pour ce faire, une strophe de la base
de donnes ODM PdAt doit spcifier la nouvelle valeur de max_coalesce. Si vous avez
dj insr une strophe de ce type, vous pouvez en obtenir la version courante via :
# odmget q \
uniquetype=disk/scsi/osdisk AND attribute=max_coalesce \
PdAt > foo
Sil nexiste aucune strophe de ce type, crez, via un diteur, le fichier foo contenant :
PdAt:
uniquetype = disk/scsi/osdisk
attribute = max_coalesce
deflt = 0x20000
values = 0x20000
width =
type = R
generic =
rep = n
nls_index = 0
Notez que max_coalesce, en octets, est exprim par un nombre hexadcimal. La valeur
des champs deflt et values (0x20000) donne max_coalesce la valeur de 128 ko.
Remplacez ensuite lancienne strophe de PdAt (le cas chant) par foo, comme suit :
# odmdelete o PdAt \
q uniquetype=/disk/scsi/osdisk AND attribute=max_coalesce
# odmadd < foo
Pour appliquer la modification, reconstituez le noyau et ramorcez le systme, via :
# bosboot a d hdisk0
# shutdown rF
8-22
Limites de la file dattente de lunit de disque et de la

carte SCSI
AIX a la possibilit de forcer les limites du nombre de requtes dE/S issues de la carte
SCSI vers un bus ou une unit de disque SCSI donn. Ces limites ont pour but dexploiter la
capacit du matriel grer des requtes multiples, tout en assurant que les algorithmes
doptimisation de la recherche des pilotes dunits peuvent effectivement oprer.
Pour les units non BULL, il est parfois judicieux de modifier les valeurs par dfaut des
limites de la file dattente AIX, choisies lorigine pour faire face aux situations les moins
favorables. Les sections suivantes traitent des cas o il convient de modifier ces valeurs.
Unit de disque non BULL

Pour les units de disque BULL, le nombre par dfaut de requtes pouvant tre mises
simultanment est de 3. Cette valeur est base sur des considrations de performance
complexes et aucune interface directe nest fournie pour la modifier. La longueur par dfaut
dune file dattente matrielle des units de disque non BULL est de 1. Si une unit non
BULL spcifique na pas la capacit de mettre en tampon plusieurs requtes, la description
systme de cette unit doit tre modifie en consquence.
Par exemple, voici les caractristiques par dfaut dune unit de disque non BULL affiches
par la commande lsattr :
$ lsattr D c disk s scsi t osdisk
pvid
none Physical volume identifier
False
clr_q
no
Device CLEARS its Queue on error
q_err
yes Use QERR bit
q_type
none Queuing TYPE
queue_depth
1
Queue DEPTH
reassign_to
120 REASSIGN time out value
rw_timeout
30
READ/WRITE time out value
start_timeout 60
START unit time out value
Pour modifier ces paramtres, vous pouvez passer par smit (raccourci chgdsk) et par la
commande chdev. Par exemple, si votre systme contient lunit de disque SCSI non BULL
hdisk5, la commande :
# chdev l hdisk5 a q_type=simple a queue_depth=3
active la fonction de mise en file dattente pour cette unit et dfinit 3 la longueur de cette
file dattente.
Pile de disques non BULL

Une pile de disques est considre par AIX comme un seul disque, assez volumineux. Une
pile de disques non BULL, comme une unit de disque non BULL, est de la classe disk,
sous-classe scsi, type osdisk (cestdire Other SCSI Disk Drive). Une pile de disques
contenant en ralit un certain nombre de disques physiques, chacun prenant en charge de
multiples requtes, la longueur de la file dattente pour la pile de disques doit tre
suffisamment leve pour permettre une exploitation efficace de toutes les units
physiques. Par exemple, si hdisk7 est une pile de huit disques non BULL, effectuez la
modification comme suit :
# chdev l hdisk7 a q_type=simple a queue_depth=24
Si la pile de disques est connecte via un bus SCSI2 Fast/Wide, il faudra peut-tre
modifier galement la limite dfinie pour les requtes externes pour ce bus.
8-23
Limitation des requtes externes sur une carte disque

La carte SCSI2 Fast/Wide accepte deux bus SCSI : lun pour les units internes, lautre
pour les units externes. Une limite sur le nombre total de requtes en attente est dfinie
pour chaque bus (valeur par dfaut : 40, valeur maximale 128). Si une pile de disques BULL
est connecte un bus de carte SCSI2 Fast/Wide, la limite pour le bus est augmente
pour tenir compte de la taille de la file dattente de la pile de disques. Sil sagit dune pile de
disques non BULL, la limite pour le bus doit tre dfinie manuellement. Par exemple, pour
limiter 70 le nombre de requtes externes de la carte scsi3, spcifiez :
# chdev l scsi3 a num_cmd_elems=70
Sur le contrleur haute performance SCSI2, le nombre de requtes en file dattente est
limit 30 et cette limite ne peut tre modife. De ce fait, vous devez vrifier que la somme
des longueurs des files dattente relies un contrleur de ce type ne dpasse pas 30.
La carte SCSI ESCALA dorigine ne prend pas en charge la mise en file dattente.
Ne connectez pas dunit de piles de disques une carte de ce type.
8-24
Contrle du nombre de pbufs systme

Le gestionnaire LVM (Logical Volume Manager) utilise un lment appel pbuf pour
contrler les E/S disque en attente. Sous AIX version 3, il est requis un pbuf par page lue ou
crite. Sur les systmes effectuant beaucoup dE/S squentielles, le pool de pbufs peut se
trouver rapidement dgarni. La commande vmtune permet daugmenter le nombre de
pbufs pour compenser cette dperdition.
Sous AIX version 4.1, un seul pbuf est utilis par requte dE/S squentielle, quel que soit le
nombre de pages en cause. Ce qui diminue grandement la probabilit de manquer de
pbufs.
8-25
8-26
Chapitre 9. Contrle et optimisation des E/S de

communication
Ce chapitre traite de diffrents protocoles de communication, et notamment des moyens de

les contrler et de les optimiser. Il comporte les sections suivantes :
Performances UDP/TCP/IP
Optimisation de TCP et UDP
Rcapitulatif des paramtres doptimisation UDP, TCP/IP et mbuf
Optimisation de NFS
Service des stations de travail sans disque
Optimisation des connexions asynchrones pour transferts haut dbit
Evaluation des performances rseau avec netpmon
Analyse des problmes de performance avec iptrace
Contrle et optimisation des E/S de communication
9-1
Performances UDP/TCP/IP
Pour apprhender les caractristiques des performances de UDP et de TCP/IP, quelques
notions sur larchitecture sous-jacente simposent. La figure Flux des donnes
UDP/TCP/IP illustre la structure traite ici.
tampon
denvoi
tampon de
lecture
application
espace utilisateur
copie
mbuf
espace systme
envoi socket
tampon
copie
tampon de
mbuf
rception socket
datagrammes
flux
TCP
(conformit MTU)
UDP
conformit MTU
TCP
UDP
file dentre IP
application de MTU
mbufs file de transmission

DMA
socket
couche ou
sous-systme
(par exemple,
NFS, DFS)
couche
TCP ou
UDP
Couche IP
couche IF
file de rception
unit
pilote
DMA
adaptateur
support
Flux des donnes UDP/TCP/IP

Cette figure illustre le cheminement des donnes depuis une application sur un systme
une autre sur un systme distant. Le traitement des couches, dtaill plus loin, peut tre
rsum comme suit (en ne tenant pas compte du traitement des erreurs et des limites des
tampons) :
La requte dcriture manant de lapplication provoque la copie des donnes du
segment de travail de lapplication dans le tampon denvoi du socket.
La couche ou le sous-systme socket transmet les donnes UDP ou TCP.
Si les donnes sont plus volumineuses que le MTU (maximum transfer unit) du rseau :
TCP fragmente la sortie en segments conformes la limite MTU.
9-2
UDP dlgue la fragmentation de la sortie la couche IP.

Au besoin, IP fragmente la sortie en lments compatibles avec le MTU.
La couche IF (interface) vrifie quaucun paquet sortant ne dpasse la limite MTU.
Les paquets sont placs dans la file de sortie de lunit et transmis par ladaptateur de
rseau au systme destinataire.
A larrive, les paquets sont placs dans la file de rception du pilote dunit, et transmis
IP via la couche Interface.
Si lIP du systme destinataire dtermine que lIP du systme expditeur a fragment un
bloc de donnes, il rassemble les fragments dans leur forme dorigine et passe les
donnes TCP ou UDP :
TCP rassemble les segments dorigine et place lentre dans le tampon de rception
du socket.
UDP passe simplement lentre dans le tampon de rception du socket.
Lorsque lapplication met une requte de lecture, les donnes ad hoc sont copies
depuis le tampon de rception du socket (se trouvant dans la mmoire du noyau) dans le
segment de travail de lapplication.
Gestion de la mmoire du sous-systme de communication (mbuf)

Pour prvenir la fragmentation de la mmoire du noyau et une surcharge dappels
xmalloc(), les pools de tampons usuels sont partags par les diffrentes couches du
sous-systme de communication. La fonction de gestion des mbuf contrle deux pools de
tampons : un pool de tampons de faible capacit (256 octets chacun), simplement appels
mbuf, et un pool de tampons de capacit leve (4 096 octets chacun), gnralement
appels grappes mbuf ou grappes. Les pools sont constitus dlments fixes de mmoire
virtuelle du noyau ce qui signifie quils rsident en permanence en mmoire physique et
ne font jamais partie de pages vacues. En consquence, la capacit de mmoire relle,
disponible pour la pagination dans les programmes dapplication et les donnes, est
diminue dun volume quivalent laugmentation de la capacit des pools mbuf.
Outre le fait dviter la duplication, le partage des pools mbuf et grappes permet aux
diffrentes couches de se passer les pointeurs, rduisant les appels de gestion mbuf et les
copies de donnes.
Couche socket
Les sockets fournissent linterface de programmation API au sous-systme de
communication. Il en existe plusieurs types, offrant diffrents niveaux de service par le biais
de protocoles de communication diffrencis. Les sockets de type SOCK_DGRAM utilisent
le protocole UDP. Les sockets de type SOCK_STREAM utilisent le protocole TCP.
La smantique douverture, de lecture et dcriture relative aux sockets est semblable
celle qui rgit la manipulation des fichiers.
La taille des tampons de la mmoire virtuelle du systme (cest--dire la capacit totale des
pools mbuf) utiliss en entre et sortie des sockets est limite par les valeurs par dfaut du
systme (il est possible de passer outre ces valeurs pour un socket donn par un appel la
routine setsockopt()) :
udp_sendspace Taille des tampons des sockets de datagrammes. Les valeurs par
et
dfaut sont respectivement de 9216 et 41600.
udp_recvspace
tcp_sendspace
et
tcp_recvspace
Taille des tampons des sockets de flux. Par dfaut : 16384 (les deux).
9-3
Pour afficher ces valeurs, entrez :

$ no a
Pour les dfinir (en tant quutilisateur root), entrez, par exemple :
# no o udp_sendspace=nouvelle-valeur
Nouvelle-valeur doit tre infrieure ou gale au paramtre sb_max, qui contrle la taille
maximale despace utilisable par un tampon denvoi ou de rception de socket. sb_max est
affich par no a et dfini (avanttoute tentative daugmentation de sa valeur courante) par
la commande no :
# no o sb_max=nouvelle-limite
Remarque : La taille des tampons denvoi et de rception de socket ne doit pas
dpasser sb_max octets, sb_max constituant une valeur plafond au niveau de la
consommation despace tampon. Les deux quantits ne sont toutefois pas mesures de
la mme manire : la taille du tampon limite la quantit de donnes qui peut sy trouver ;
sb_max limite le nombre doctets de mbuf qui peut se trouver dans le tampon un
instant donn. Dans un environnement Ethernet par exemple, chaque grappe mbuf de
4 096 octets peut contenir juste 1500 octets de donnes. Dans ce cas, sb_max doit tre
2,73 fois suprieur la taille de tampon de socket, pour atteindre la capacit spcifie.
Empiriquement, nous prconisons de donner sb_max une valeur au moins double de
la taille du tampon de socket.
Flux denvoi
Lorsquune application crit dans un socket, les donnes sont copies de lespace
utilisateur dans le tampon denvoi du socket, dans lespace du noyau. Selon la quantit de
donnes copies, le socket les place dans le mbuf ou dans les grappes. Une fois la copie
termine, la couche socket appelle la couche transport (TCP ou UDP), et lui passe un
pointeur sur la liste des mbuf lis (chane mbuf).
Flux de rception
Du ct rception, une application ouvre un socket et y lit des donnes. Si le tampon de
rception nen contient pas, la couche socket met la routine de lapplication ltat veille
(bloqu) jusqu larrive de donnes. Lorsque des donnes arrivent, elles sont places
dans la file du tampon de rception du socket et la routine de lapplication peut tre diffuse.
Les donnes sont ensuite copies dans le tampon de lapplication (dans lespace
utilisateur), la chane mbuf est libre et le contrle revient lapplication.
Cration de socket
Sous AIX Version 4.3.1 et ultrieures, la valeur sockthresh dtermine la proportion de la
mmoire rseau du systme qui peut tre utilise avant que la cration de socket ne soit
dsactive. La valeur de sockthresh est fournie sous la forme dun pourcentage de
thewall. Elle est par dfaut de 85% et peut prendre toute valeur comprise entre 1 et 100,
condition toutefois que sockthresh ne soit pas infrieure la quantit de mmoire
actuellement utilise.
Loption sockthresh a pour but dviter que de trop nombreuses connexions soient
ouvertes, conduisant lutilisation de la totalit de la mmoire rseau disponible sur la
machine. Dans ce cas de figure, il ne resterait plus de mmoire pour les autres oprations
et la machine, bloque, devrait tre redmarre. Utilisez sockthresh pour dfinir partir
de quel point les nouveaux sockets sont refuss. Les appels vers socket() et socketpair()
choueront (erreur ENOBUFS), et les requtes de connexion entrantes seront annules de
manire transparente. Ainsi, la mmoire rseau restant disponible sur la machine pourra
tre utilise par les connexions existantes et aucun blocage de la machine ne sera
craindre.
Le dcompte netstat m sockets not created because sockthresh was
reached est incrment chaque fois que la cration dun nouveau socket est refus parce
que la quantit de mmoire rseau dj utilise est suprieure la valeur de sockthresh.
9-4
Pour afficher sockthresh, entrez :

$ no o sockthresh
Pour le dfinir (en tant quutilisateur root), entrez :
# no o sockthresh=Nouvellevaleur
Pour affecter sockthresh sa valeur par dfaut, entrez :
# no d sockthresh
Fonctions UDP et TCP

Les deux sections suivantes dcrivent les fonctions UDP et TCP. Pour faciliter la
comparaison entre les deux, chaque section est divise en rubriques : connexion, dtection
des erreurs, reprise sur erreur, contrle du flux, taille des donnes et gestion du MTU.
Couche UDP
UDP offre un protocole conomique pour les applications dotes de fonctions susceptibles
de traiter les incidents de communication. UDP convient bien aux applications de style
requte-rponse. Une application de ce type devant de toutes faons grer les incidents
de rponse, il suffit de peu pour lui faire grer les erreurs de communication comme une
des causes possibles dun dfaut de rponse. Cest pourquoi, outre son faible cot, des
sous-systmes tels NFS, ONC RPC, DCE RPC et DFS utilisent UDP.
Connexion
Aucun. UDP est un protocole sans tat. Chaque requte reue de

lappelant est gre indpendamment de celles qui la prcdent ou la
suivent. (Si la sous-routine connect() est appele pour un socket de
datagramme, les informations sur la destination sont considres
comme une technique pour placer en mmoire cache ladresse rsolue,
pour un usage ultrieur. Il ny a pas de liaison effective entre le socket
et ladresse, ou dincidence sur lUDP du systme destinataire.)
Dtection
derreur
Cration et vrification de total de contrle. LUDP expditeur tablit le

total de contrle et lUDP destinataire le vrifie. Si le contrle est
ngatif, le paquet est abandonn.
Recouvrement
derreur
Aucun. UDP naccuse pas rception des paquets et ne dtecte pas leur
perte en cours de transmission ou par saturation du pool de tampons.
En consquence, UDP ne retransmet jamais de paquet. La reprise doit
tre excute par lapplication.
Contrle de flux
Aucun. LorsquUDP est invit mettre, il envoie un paquet IP.

Lorsquun paquet arrive en provenance dIP, il est plac dans le tampon
de rception du socket. Si la file du tampon de la carte/du pilote dunit
est sature, le paquet est abandonn sans aucune notification derreur.
Cest lapplication ou au sous-systme expditeur de dtecter lerreur
(dlai imparti dpass) et de relancer la transmission.
Taille des
donnes
Doit tenir dans un seul tampon. Ce qui implique que les pools de
tampons de deux cts de UDP disposent de tampons dont la taille
rponde aux besoins des applications. La taille maximale dun paquet
UDP est de 64 ko. Bien entendu, une application qui gnre des blocs
plus grands peut les scinder elle-mme en plusieurs datagrammes
ce que fait DCE, par exemple mais il est plus simple de passer
par TCP.
Gestion de MTU Aucun. Le traitement des donnes de taille suprieure la taille du

MTU (maximum transfer unit) pour linterface est laiss la charge dIP.
Si IP doit fragmenter les donnes pour les adapter au MTU, la perte
des fragments devient une erreur, qui doit tre gre par lapplication
ou le sous-systme.
9-5
Flux denvoi
Si udp_sendspace est suffisamment grand pour contenir le datagramme, les donnes de
lapplication sont copies dans des mbuf de la mmoire du noyau. Si le datagramme est
plus grand que udp_sendspace, une erreur est renvoye lapplication.
Si le datagramme est suprieur ou gal 936 octets, il est copi dans une ou plusieurs
grappes de 4 ko. Le reste (et lventuel datagramme complet), de moins de 936 octets est
copi dans 14 mbufs. Par exemple, une criture de 8704 octets est copie dans deux
grappes et le reste dans trois mbuf. UDP ajoute len-tte UDP (dans le mme mbuf, si
possible), effectue un total de contrle sur les donnes et appelle la routine IP ip_output.
Flux de rception
UDP vrifie le total de contrle et met les donnes en file dattente sur le socket adquat. Si
la limite udp_recvspace est dpasse, le paquet est rejet. (Le dcompte de ces rejets est
consign par netstat s sous lintitul udp: socket buffer overflows.)
Si lapplication est en attente dun receive ou dun read sur le socket, elle est place en file
dattente dexcution. receive copie alors le datagramme dans lespace dadressage de
lutilisateur et libre le mbuf : lopration receive est termine. Normalement, le destinataire
adresse un accus de rception et un message lexpditeur.
Couche TCP
TCP fournit un protocole de transmission fiable. TCP convient aux applications qui, au
moins par priodes, sont essentiellement en mode entre ou en mode sortie. TCP assurant
que les paquets arrivent destination, lapplication est libre de la dtection derreur et
des tches de reprise. Parmi les applications exploitant le transport via TCP, citons : ftp,
rcp et telnet. DCE peut lutiliser sil est configur pour exploiter un protocole orient
connexion.
9-6
Connexion
Explicite. Linstance de TCP recevant la requte de connexion dune

application (dite linitiateur) tablit une session avec son homologue sur
lautre systme (dit lcouteur). Tous les changes de donnes et de
paquets de contrle ont lieu dans le cadre de cette session.
Dtection
derreur
Cration et vrification de total de contrle. Le TCP expditeur tablit le

total de contrle et le TCP destinataire le vrifie. Si le contrle est
ngatif, le destinataire ne reoit pas daccus de rception du paquet.
Recouvrement
derreur
Intgrale. TCP dtecte les erreurs au niveau des totaux de contrle et

les pertes de paquet ou de fragment, via le dpassement de dlai. En
cas derreur, TCP retransmet les donnes jusqu ce que la rception
aboutisse (ou notifie lapplication dune erreur irrmdiable).
Contrle de flux
Renforce. TCP adopte une technique dite de fentre coulissante pour

vrifier la livraison lapplication destinataire. Le concept de fentre
coulissante est illustr la figure Fentre coulissante TCP.
(Les enregistrements illustrs ont pour seul objet de clarifier les choses.
TCP traite les donnes comme un flux doctets et ne garde pas trace
des limites darticles, qui sont dfinies par lapplication).
fentre de
transmission
donnes
non acquittes
donnes
acquittes
expditeur TCP
ec5
art6
art7
application expditrice
(en veille)
art8
flux des donnes
ec5
destinataire TCP
...
art4
art6
art
espace disponible pour
donnes en transit
r
fentre de rception
application rceptrice
(en traitement)
Fentre coulissante TCP
9-7
Sur la figure, lapplication expditrice est en veille, car elle a tent

dcrire des donnes qui auraient conduit TCP saturer le tampon du
socket denvoi (tcp_sendspace). Le TCP expditeur dtient toujours la
fin de art5, lintgralit de art6 et art7, et le dbut de art8. Le TCP
destinataire na pas encore reu la fin de art7, ni art8. Lapplication
rceptrice a reu art4 et le dbut de art5 lors de sa dernire lecture du
socket, et elle procde actuellement au traitement des donnes.
Lorsquelle effectuera une nouvelle lecture du socket, elle recevra (en
supposant une lecture suffisamment vaste) la fin de art5, art6, et les
parties de art7 et art8 arrives ce moment.
Au moment de cette lecture, le TCP destinataire acquitte ces donnes,
le TCP expditeur les abandonne, lcriture en cours se termine et
lapplication expditrice passe ltat actif. (Pour viter de surcharger le
trafic rseau lorsque lapplication lit de faibles quantits de donnes,
TCP diffre lacquittement jusqu ce que lapplication rceptrice ait lu
une quantit de donnes au moins gale la moiti de la taille de la
fentre rceptrice ou au double de la taille maximale de segment.)
Au cours de ltablissement dune session, linitiateur et lcouteur
dialoguent pour dterminer leur capacit respective de mise en tampon
des donnes en entre et en sortie. La taille de la fentre est celle de la
plus petite des tailles. A mesure que les donnes sont inscrites dans le
socket, elles sont places dans le tampon de lexpditeur. Lorsque le
destinataire indique quil dispose despace, lexpditeur transmet
suffisamment de donnes pour remplir cet espace (sil en dispose, bien
entendu). Lorsque lapplication rceptrice lit le socket, le TCP rcepteur
renvoie autant de donnes quil en dtient dans son tampon. Il informe
ensuite lexpditeur que les donnes ont bien t transmises. Ce nest
qualors que lexpditeur supprime les donnes de son propre tampon,
dplaant effectivement la fentre vers la droite, en proportion des
donnes transmises. Si la fentre est sature, parce que lapplication
rceptrice ne suit pas, la routine expditrice est bloque (ou reoit un
errno spcifique) lorsquelle tente dcrire dans le socket.
La figure Taille des fentres TCP illustre la relation entre la taille des
tampons du socket et celle de la fentre.
tcp_sendspace
inutilis
tcp_recvspace
initiateur
tailles
maximales
des fentres
couteur
tcp_recvspace
tcp_sendspace
Taille des fentres TCP
9-8
tcp_recvspace est, dans les deux exemples, infrieur tcp_sendspace : dans la mesure o la technique de dplacement de fentre
impose que les deux systmes aient la mme capacit de tampon disponible, la taille de la fentre est dfinie son minimum dans les deux
directions. Lespace nominal supplmentaire disponible illustr nest
jamais utilis.
Si le paramtre rfc1323 est 1, la taille maximale de la fentre TCP est
de 4 Go (et non de 64 ko).
Taille des
donnes
Indfinie. TCP ne traite ni articles ni blocs, mais un flux continu doctets.

Si la capacit dun tampon denvoi excde celle que peut traiter le
tampon de rception, le flux doctets est segment en paquets de la
taille du MTU. Dans la mesure o il gre linsuffisance despace tampon
de faon transparente, TCP ne garantit pas que le nombre et la taille
des donnes reues soient identiques celles envoyes. Cest
lapplication didentifier (des deux cts), le cas chant, les limites des
blocs ou des articles dans le flux de donnes.
Remarque : Pour changer des messages de type requte/rponse via
TCP, lapplication doit passer par setsockopt pour activer loption
TCP_NODELAY. Ce qui provoque lenvoi immdiat du message par
TCP (dans le cadre des contraintes de la fentre coulissante), mme
sil natteint pas la taille MTU. Sinon, TCP attend jusqu
200 millisecondes dautres donnes avant de transmettre le message.
Ce qui induit une baisse des performances.
Gestion de MTU Gr par segmentation dans TCP. Lors de ltablissement de la

connexion, linitiateur et lcouteur ngocient la taille de segment
maximale (MSS) utiliser. Le MSS est normalement infrieur au MTU
(voir Optimisation de la taille maximale de segment (MSS) TCP,
page 9-21). Si le paquet de sortie dpasse le MSS, TCP effectue la
segmentation, rendant inutile la fragmentation dans IP. Le TCP
rcepteur place normalement les segments dans la file de rception du
socket mesure de leur arrive. Si le TCP rcepteur dtecte la perte
dun segment, il refuse lacquittement et renvoie les segments suivants
tant quil ne reoit pas le segment manquant.
Il nexiste bien entendu rien qui ressemble une fonction libre. Les autres oprations
excutes par TCP pour assurer la fiabilit de la connexion induisent un surcot au niveau
processeur denviron 7 12 % par rapport UDP.
Flux denvoi
Lorsque la couche TCP reoit une requte dcriture de la couche socket, elle affecte un
nouveau mbuf pour les informations den-tte et copie les donnes dans le tampon denvoi
du socket, dans le mbuf den tte TCP (sil y a de la place), ou dans une nouvelle chane
mbuf. Si les donnes copies se trouvent dans des grappes, de nouvelles grappes ne sont
pas cres : un champ pointeur est dfini dans le nouvel en-tte mbuf (cet en-tte fait partie
de la structure mbuf et na aucune relation avec len-tte TCP), pointant sur les grappes
contenant les donnes, vitant ainsi la charge dune ou plusieurs copies de 4 ko. TCP
effectue ensuite un total de contrle sur les donnes, met jour les diverses variables dtat
utilises pour le contrle de flux et autres services, et, enfin, appelle la couche IP avec le
mbuf den-tte dsormais li la nouvelle chane mbuf.
Flux de rception
Lorsque la routine dentre TCP reoit des donnes dIP, elle effectue un total de contrle
sur len-tte et les donnes TCP, pour dtecter dventuelles altrations, dtermine la
connexion laquelle sont destines les donnes, supprime les informations den-tte, lie la
chane mbuf au tampon de rception du socket associ la connexion, et fait appel un
service socket pour activer lapplication (si elle est en veille, comme expliqu plus haut).
9-9
Couche IP
Le protocole Internet (IP) fournit un service datagramme de base aux couches hautes.
Sil reoit un paquet plus grand que le MTU de linterface, il le fragmente et envoie les
fragments au systme destinataire, lequel les rassemble sous leur forme dorigine. En cas
de perte dun fragment au cours de la transmission, le paquet incomplet est rejet par le
destinataire. Le dlai dattente par IP dun fragment manquant est dfini par le paramtre
ipfragttl, affich et renseign via la commande no.
La taille maximale de la file dattente de paquets IP reus de linterface rseau est
contrle par le paramtre ipqmaxlen, dfini et affich via no. Si la taille de la file dattente
en entre atteint ce chiffre, les paquets suivants sont abandonns.
Flux denvoi
Lorsque la routine de sortie IP reoit un paquet mis par UDP ou TCP, elle identifie
linterface laquelle envoyer la chane mbuf, met jour et effectue un total de contrle sur
la partie IP de len-tte, et passe le paquet la couche interface (IF).
IP dtermine le pilote et la carte dunit utiliser, en fonction du numro du rseau. La table
dinterface du pilote dfinit le MTU maximal pour ce rseau. Si le datagramme est plus petit
que le MTU, IP insre len-tte IP dans le mbuf existant, effectue un total de contrle sur
len-tte IP et appelle le pilote pour envoyer la trame. Si la file denvoi du pilote est sature,
une erreur EAGAIN est renvoye IP, qui la transmet UDP, lequel la transmet son tour
lapplication. Lexpditeur na plus qu patienter et ressayer.
Si le datagramme est plus grand que le MTU (ce qui ne se produit que dans UDP), IP le
divise en fragments de taille gale celle du MTU, ajoute chaque fragment un en-tte IP
(dans un mbuf), et appelle le pilote pour chaque trame de fragment. Si la file denvoi du
pilote est sature, une erreur EAGAIN est renvoye IP. IP rejette tous les fragments non
envoys associs ce datagramme et renvoie EAGAIN UDP, qui le transmet
lapplication expditrice. UDP renvoie EAGAIN lapplication expditrice. IP et UDP ne
plaant pas les messages en file dattente, il appartient lapplication de diffrer lenvoi et
de le tenter ultrieurement.
Flux de rception
Sous AIX version 3, lorsque la routine dentre IP reoit le contrle suite une interruption
hors niveau planifie par IF, elle te la chane mbuf de la file dattente, vrifie le total de
contrle de len-tte IP pour sassurer quil nest pas altr, et dtermine si le paquet est
destin ce systme. Dans laffirmative, et si la trame nest pas un fragment, IP passe la
chane mbuf la routine dentre TCP ou UDP.
Sous AIX version 4.1, la couche demux (dmultiplexeur couche IF dans la version 3)
appelle IP sur la routine dinterruption. Toute activit de planification ou de mise (ou retrait)
en file dattente est interrompue. IP vrifie le total de contrle de len-tte IP pour sassurer
quil nest pas altr, et dtermine si le paquet est destin ce systme. Dans laffirmative,
et si la trame nest pas un fragment, IP passe la chane mbuf la routine dentre TCP
ou UDP.
Si la trame reue est un fragment de datagramme (ce qui ne peut se produire que dans
UDP), IP bloque la trame. A rception des fragments suivants, ils sont fusionns en un
datagramme logique, lequel, une fois complet, est transmis UDP. IP bloque les fragments
dun datagramme incomplet jusqu expiration du dlai ipfragttl (spcifi via no). Le dlai
ipfragttl par dfaut est de 30 secondes (valeur ipfragttl de 60). En cas de perte de
fragments (suite un incident rseau, une insuffisance despace mbuf, une saturation de la
file de transmission, etc.), IP ne les reoit jamais. A lexpiration de ipfragttl, IP rejette les
fragments reus. Ce qui est consign par netstat s sous lintitul ip:
fragments dropped after timeout.
9-10
Couche IF (couche Demux sous AIX version 4.1)

Flux denvoi
Lorsque la couche IF reoit un paquet mis par IP, elle associe un en-tte de liaison de
couche au dbut du paquet, vrifie que le format des mbuf est conforme aux spcifications
dentre du pilote dunit, puis appelle la routine dcriture du pilote de lunit.
Flux de rception
Sous AIX version 3, lorsque la couche IF reoit un paquet du pilote dunit, elle supprime
len-tte de liaison, place la chane mbuf sur la file dattente dentre IP (par le biais de
pointeurs, et non par copie) et planifie une interruption hors niveau pour excuter le
traitement dentre IP.
Sous AIX version 4.1, lorsque la couche demux reoit un paquet du pilote dunit, elle
appelle IP sur la routine dinterruption pour excuter le traitement dentre IP.
Cartes rseau local et pilotes dunit

Diffrents types de cartes rseau sont accepts dans lenvironnement AIX. Ces cartes se
distinguent non seulement par les protocoles et supports de communication quelles
prennent en charge, mais galement par leur interface avec le bus dE/S et le processeur.
De mme, les pilotes dunit se diffrencient par la technique de transfert des donnes
entre la mmoire et les cartes. La description ci-aprs sapplique globalement la plupart
des cartes et des pilotes dunit, quelques points de dtail tant nanmoins diffrents.
Flux denvoi
Au niveau de la couche du pilote dunit, la chane mbuf contenant le paquet est place sur
la file de transmission. Le nombre maximal de tampons de sorties qui peut tre en file
dattente est contrl par le paramtre systme xmt_que_size. Dans certains cas, les
donnes sont copies dans les tampons DMA du pilote. La carte est ensuite appele
dmarrer les oprations DMA.
A ce niveau, le contrle revient la routine de sortie TCP ou UDP, laquelle continue
mettre tant quelle a des donnes envoyer. Le contrle revient ensuite lapplication, qui
sexcute en mode asynchrone pendant que la carte transmet des donnes. Une fois la
transmission termine, la carte interrompt le systme et les routines dinterruption dunit
sont appeles pour adapter les files de transmission et librer les mbuf qui contenaient les
donnes transmises.
Flux de rception
Lorsque des trames sont reues par une carte, elles sont transfres dans une file de
rception gre par le pilote. Cette file dattente peut tre constitue de mbuf ou dun pool
de tampons distinct gr par le pilote dunit. Dans les deux cas, les donnes se trouvent
dans une chane mbuf lorsquelles passent du pilote dunit la couche IF.
Certains pilotes reoivent les trames DMA dans une zone de mmoire fixe. Ils affectent
ensuite des mbuf et y copient les donnes. Les pilotes/cartes recevant des trames MTU
volumineuses peuvent rceptionner les trames DMA directement dans des grappes mbuf.
Le pilote passe le contrle de la trame au protocole appropri (IP dans cet exemple) en
appelant une fonction de dmultiplexage qui identifie le type de paquet et place le mbuf
contenant le tampon dans la file dentre de ce protocole. A dfaut de mbuf disponible, ou si
la file dentre du plus haut niveau est sature, les trames entrantes sont rejetes.
9-11
Optimisation de TCP et UDP

Les valeurs optimales des paramtres de communication varient selon le type de rseau et
les caractristiques des E/S de communication du systme dominant et des programmes
dapplication. Les sections ciaprs dcrivent les principes gnraux doptimisation des
communications, et poursuivent avec des conseils spcifiques destins diffrents types de
rseaux locaux.
Recommandations
Vous pouvez viser soit un dbit maximal, soit une utilisation minimale de la mmoire. Les
conseils qui suivent sappliquent lune ou lautre des approches, parfois aux deux.
Optimisation du dbit de sortie

Protocoles requte-rponse
Pour maximiser le nombre de transactions par seconde, optez pour des messages
courts.
Pour maximiser le nombre doctets par seconde, optez pour des messages suprieurs ou
gaux 1000 octets et juste infrieurs ou gaux un multiple de 4096 octets.
Si les requtes et les rponses sont de taille fixe et tiennent dans un seul datagramme,
passez par UDP :
Si possible, dfinissez des tailles dcriture qui soient des multiples de la taille du MTU
diminue de 28 octets pour laisser la place aux en-ttes standard IP et UDP.
Il est plus efficace quune application crive des messages longs, qui sont ensuite
fragments et rassembls par IP, plutt que de multiplier les critures.
Chaque fois que possible, faites appel la routine connect pour associer une adresse
au socket UDP. Cette opration peut tre impossible sur un serveur communiquant
avec plusieurs clients via un seul socket.
Si les requtes et les rponses sont de taille variable, passez par TCP assorti de loption
TCP_NODELAY. Nous avons mesur que la charge de TCP est ngligeable par rapport
celle dUDP, notamment si des tailles dcriture optimales sont spcifies.
Pour viter que des donnes ne soient copies dans le noyau, dfinissez des tailles
dcriture suprieures 936 octets.
Optez pour des critures de taille gale ou lgrement infrieures un multiple de la
taille MTU. Ceci pour viter lenvoi dun segment (paquet) ne contenant que quelques
octets.
Flux
TCP offre un dbit de sortie suprieur celui dUDP et assure la fiabilit de la
transmission.
La taille des critures doit tre un multiple de 4 096 octets. Si possible, les critures
doivent tre de la taille du MSS (voir Optimisation de la taille maximum de segment
(MSS) TCP).
Optimisation de la mmoire
Si votre trafic est essentiellement local, optez pour la plus grande taille de MTU accepte
par le type de votre rseau : vous minimiserez la fragmentation de paquets changs par
les systmes locaux. Avec, en contrepartie, une fragmentation dans les passerelles
connectant votre rseau dautres rseaux locaux dots de MTU de taille infrieure
(voir Optimisation de la taille maximum de segment (MSS) TCP).
Chaque fois que possible, les programmes dapplication doivent lire et crire des
volumes :
9-12
soit infrieurs ou gaux 935 octets,

soit gaux ou lgrement infrieurs 4 096 octets (ou des multiples) :
Le premier sera plac dans les mbufs 1 4, les suivants feront bon usage des grappes
de 4 096 octets utilises pour les critures de taille suprieure 935 octets. Ecrire
936 octets entrane un gaspillage de 3 160 octets par criture : lapplication peut saturer
udp_recvspace (avec sa valeur par dfaut de 65 536) avec 16 critures ne totalisant
que 14 976 octets de donnes.
Passer par TCP gaspille temps et mmoire. TCP tente de former des donnes
dlimites en paquets de la taille du MTU. Si le MTU du rseau est plus grand que
14 976 octets, TCP place la routine denvoi ltat veille ds que la limite de
tcp_sendspace est atteinte. Il reoit un acquittement (ACK) de dpassement de dlai
du rcepteur pour forcer lcriture des donnes.
Remarque : Si vous modifiez des paramtres via la commande no, les modifications ne
sont effectives que jusqu lamorage systme suivant : les paramtres sont alors
rinitialiss leur valeur par dfaut. Pour prenniser des modifications, placez la
commande no approprie dans le fichier /etc/rc.net.
Optimisation des files de transmission et de rception de la carte

La plupart des gestionnaires de communication proposent une srie de paramtres
optimisables qui permettent de contrler les ressources de transmission et de rception.
Ces paramtres dterminent en gnral les limites des files dattente de transmission et de
rception, mais ils peuvent galement contrler le nombre et la taille des tampons ou
dautres ressources. La limitation porte sur le nombre de tampons ou de paquets qui
peuvent tre placs en file dattente avant transmission, ou sur le nombre de tampons
disponibles pour la rception de paquets. Ces paramtres peuvent tre optimiss de
manire permettre un placement suffisant en file dattente au niveau de la carte, afin de
grer les pointes de charge gnres par le systme ou le rseau.
Files dattente de transmission

Les gestionnaires de priphriques peuvent limiter la file de transmission. Les limites
peuvent tre matrielles ou logicielles, selon le type de gestionnaire et de carte. Certains
gestionnaires ne proposent quune file dattente matrielle, alors que dautres offrent des
files matrielles et logicielles. Daucuns autorisent un contrle de la file matrielle en interne
et la modification des limites de la file logicielle. En principe, le gestionnaire de priphrique
place le paquet transmettre directement dans la file dattente matrielle de la carte. Si le
CPU systme est rapide par rapport au rseau, ou sur un systme SMP, il peut arriver que
le systme produise les paquets transmettre plus rapidement que le rseau ne peut les
absorber. La file dattente matrielle sera donc sature. Dans ce cas de figure, certains
gestionnaires proposent alors une file dattente logicielle qui accueille les paquets en attente
de transmission. Lorsque la limite de la file logicielle est atteinte, les paquets transmettre
sont annuls. Les performances peuvent sen trouver affectes puisque les protocoles de
haut niveau doivent retransmettre le paquet.
Avant AIX version 4.2.1, les limites suprieures des files de transmission taient comprises
entre 150 et 250, selon les cartes. Les valeurs systme par dfaut taient gnralement
faibles, de lordre de 30. Depuis AIX version 4.2.1, les limites des files de transmission ont
t portes sur la plupart des gestionnaires 2048 tampons. Les valeurs par dfaut ont
galement suivi cette augmentation, jusqu 512 pour la plupart des gestionnaires. Ces
valeurs par dfaut ont t augmentes car les systmes SMP et CPU ayant gagn en
rapidit, ils arrivaient saturation avec les limites plus faibles autrefois dfinies.
9-13
Dans le cas de cartes prsentant des limites de files matrielles, la modification de ces
valeurs entrane une augmentation de la consommation de mmoire relle en raison des
blocs de contrle et tampons qui leur sont associs. Ces limites ne doivent donc tre
rehausses que si le besoin sen fait sentir ou, sur les gros systmes, si laccroissement de
lutilisation de la mmoire est ngligeable. Dans le cas de limites de files de transmission
logicielles, laugmentation de ces valeurs ne joue pas sur lutilisation de la mmoire. Elle
permet seulement de mettre en file dattente des paquets dj allous par les protocoles
des couches hautes.
Files dattente de rception

Certaines cartes vous permettent de configurer le nombre de ressources utiliser pour la
rception des paquets en provenance du rseau. Ces ressources peuvent dfinir le
nombre de tampons de rception (et leur taille) ou consister simplement en un paramtre
de file de rception (qui contrle indirectement le nombre des tampons de rception).
Il peut savrer ncessaire daugmenter les ressource de rception afin de grer les pointes
de charge du rseau.
AIX 3.2.x et AIX 4.x

Avec les versions AIX 3.2.x, les gestionnaires permettaient des applications spciales de
lire les paquets reus directement depuis le gestionnaire de priphrique. Le gestionnaire
de priphrique grait une file dattente de rception o ces paquets taient placs en
attente. Un paramtre de taille de la file de rception permettait alors de limiter le nombre
de paquets pouvant tre placs en attente pour ces applications. Sous AIX version 4.1,
cette interface nest plus prise en charge, sauf pour les anciennes cartes MicroChannel
condition que bos.compat LPP soit install. Pour plus dinformations sur des cartes
spcifiques, reportezvous la table des paramtres.
Pour les cartes PCI et les cartes Microchannel plus rcentes, les paramtres de file de
rception dterminent le nombre de tampons de rception mis la disposition de la carte
pour la rception des paquets entrants.
Tampons spcifiques au priphrique

AIX version 4.1.4 et ultrieures prennent en charge des Mbufs spcifiques au priphrique.
Ce dernier peut ainsi affecter son propre jeu de tampons et le prconfigurer lintention de
DMA. Les performances sen trouvent amliores puisque la charge supplmentaire induite
par le mappage DMA nintervient quune seule fois. Par ailleurs, la carte peut affecter les
tailles de tampon les plus adaptes sa taille de MTU. Ainsi, ATM, HIPPI et le
commutateur SP2 acceptent une taille de MTU (paquet) de 64 ko. La taille maximale de
mbuf systme est de 16 Ko. En accordant la carte des tampons de 64 ko, vous permettez
lcriture directe de grands blocs de 64 ko dans les tampons de 64 ko dtenus par la carte,
au lieu de leur copie vers plusieurs tampons de 16 ko (ce qui permet une meilleure
affectation de la charge et libre les tampons excdentaires).
Les cartes acceptant des Mbuf spcifiques aux priphriques sont MCA ATM, MCA HIPPI
et les diffrentes cartes SP2 grande vitesse.
Le revers de la mdaille de ces tampons spcifiques au priphrique est un niveau de
complexit accru pour ladministrateur systme. Ladministrateur doit faire appel des
commandes spcifiques au priphrique pour consulter les statistiques lies aux tampons
de carte et modifier les paramtres en consquence. Si les statistiques rvlent que
certains paquets ont t annuls par manque de ressources en tampons, les tailles de
tampons doivent tre augmentes.
Compte tenu de la diversit des gestionnaires et des utilitaires servant modifier leurs
paramtres, ils ne sont pas dcrits dans ce manuel. Les paramtres MCA ATM sont
rpertoris dans le tableau ciaprs. Les statistiques ATM peuvent tre consultes laide
de la commande atmstat d atm0 (substituez votre numro dinterface celui de
lexemple).
9-14
Quand les paramtres doiventils tre augments ?

Lorsque le CPU est plus rapide que le rseau et que plusieurs applications utilisent le
mme rseau. Ce cas de figure est classique sur un grand systme multiprocesseur
(SMP).
Lorsque les options de la commande no dfinissent des valeurs leves pour
tcp_sendspace ou tcp_recvspace, ou lors de lexcution dapplications pouvant
mettre des appels systme afin daugmenter la taille des tampons de socket denvoi et
de rception TCP. Ces valeurs leves peuvent entraner la transmission par le CPU
dun grand nombre de paquets vers la carte, ces paquets devant alors tre placs en
attente. Les procdures sont identiques pour udp_sendspace et udp_recvspace
pour les applications UDP.
Lorsque le trafic est trs intermittent (en rafales).
Un trafic important de petits paquets peut consommer plus de ressources quun trafic
important de grands tampons. Ceci est d au fait que les grands tampons tant plus
longs envoyer sur le rseau, le dbit des paquets est plus lent pour les gros paquets.
Comment savoir si les paramtres doivent tre augments ?

Plusieurs utilitaires dtat peuvent servir cet effet. A partir dAIX version 4.1.0, les
statistiques de la carte indiquent le niveau haut de la file de transmission et le nombre de
dpassements. Vous pouvez utiliser netstat v, ou faire appel directement aux utilitaires
statistiques de la carte (entstat pour Ethernet, tokstat pour Token Ring, fddistat pour FDDI,
atmstat pour ATM, etc.)
Voici par exemple le rsultat de la commande entstat d en0. Il indique les statistiques
concernant en0. Loption d gnre toutes les statistiques dtailles pour cette carte et doit
tre utilise pour garantir laffichage de lintgralit des statistiques. Le champ Max
Packets on S/W Transmit Queue: indique le niveau haut de la file de transmission. Le
champ S/W Transmit Queue Overflow: indique le nombre de dpassements de la file
dattente logicielle.
Remarque : Ces valeurs peuvent faire rfrence la file dattente matrielle si la carte
ne propose pas de file dattente logicielle. Sil existe des dpassements de la file de
transmission, il convient daugmenter les limites de la file matrielle ou logicielle pour ce
gestionnaire.
Des ressources insuffisantes en rception sont indiques par le champ Packets Dropped:
et, selon le type de carte, sont signales par Out of Rcv Buffers ou No Resource Errors:
ou toute autre indication comparable.
9-15
ETHERNET STATISTICS (en1) :

Device Type: IBM 10/100 Mbps Ethernet PCI Adapter (23100020)
Hardware Address: 00:20:35:b5:02:4f
Elapsed Time: 0 days 0 hours 7 minutes 22 seconds
Transmit Statistics:
Packets: 1869143
Bytes: 2309523868
Interrupts: 0
Transmit Errors: 0
Packets Dropped: 0
Receive Statistics:
Packets: 1299293
Bytes: 643101124
Interrupts: 823040
Receive Errors: 0
Packets Dropped: 0
Bad Packets: 0
Max Packets on S/W Transmit Queue: 41

S/W Transmit Queue Overflow: 0
Current S/W+H/W Transmit Queue Length: 1
Broadcast Packets: 1
Multicast Packets: 0
No Carrier Sense: 0
DMA Underrun: 0
Lost CTS Errors: 0
Max Collision Errors: 0
Late Collision Errors: 0
Deferred: 3778
SQE Test: 0
Timeout Errors: 0
Single Collision Count: 96588
Multiple Collision Count: 56661
Current HW Transmit Queue Length: 1
Broadcast Packets: 0
Multicast Packets: 0
CRC Errors: 0
DMA Overrun: 0
Alignment Errors: 0
No Resource Errors: 0
Receive Collision Errors: 0
Packet Too Short Errors: 0
Packet Too Long Errors: 0
Packets Discarded by Adapter: 0
Receiver Start Count: 0
General Statistics:
No mbuf Errors: 0
Adapter Reset Count: 0
Driver Flags: Up Broadcast Running
Simplex 64BitSupport
Une autre mthode consiste utiliser lutilitaire netstat i. Si cet utilitaire indique une valeur
non nulle dans la colonne Oerrs pour une interface, cela signifie que vous tes en
prsence dun dpassement de file dattente en sortie. Ceci est valable pour toutes les
versions dAIX.
9-16
Comment connatre la valeur des paramtres ?

Vous pouvez faire appel la commande de liste des attributs lsattr E l
[nomcarte] ou utiliser SMIT pour afficher la configuration de la carte.
Selon les cartes, les noms des variables diffrent. Ainsi, le paramtre correspondant la
file de transmission peut tre sw_txq_size, tx_que_size ou xmt_que_size pour nen
citer que quelquesuns. De mme, les paramtres correspondant au pool de tampons et
la taille de la file de rception peuvent tre appels rec_que_size, rx_que_sizeou encore
rv_buf4k_min.
Voici le rsultat de la commande lsattr E l atm0 sur une carte PCI 155 Mbs ATM. Il
indique que sw_txq_size a la valeur 250 et que les tampons de rception
rv_buf4K_min ont la valeur x30.
==== lsattr E
dma_mem
regmem
virtmem
busintr
intr_priority
use_alt_addr
alt_addr
sw_txq_size
max_vc
min_vc
rv_buf4k_min
interface_type
adapter_clock
uni_vers
========
0x400000
0x1ff88000
0x1ff90000
3
3
no
0x0
250
1024
32
0x30
0
1
auto_detect
N/A
Bus Memory address of Adapter Registers
Bus Memory address of Adapter Virtual Memory
Bus Interrupt Level
Interrupt Priority
Enable ALTERNATE ATM MAC address
ALTERNATE ATM MAC address (12 hex digits)
Software Transmit Queue size
Maximum Number of VCs Needed
Minimum Guaranteed VCs Supported
Minimum 4Kbyte premapped receive buffers
Sonet or SDH interface
Provide SONET Clock
N/A
False
False
False
False
False
True
True
True
True
True
True
True
True
True
Voici un exemple de paramtres pour Microchannel 10/100 Ethernet gnr en utilisant

lsattr E l ent0. Il indique que tx_que_size et rx_que_size ont tous deux la
valeur 256.
bus_intr_lvl
intr_priority
dma_bus_mem
bus_io_addr
dma_lvl
tx_que_size
rx_que_size
use_alt_addr
alt_addr
media_speed
ip_gap
11
3
0x7a0000
0x2000
7
256
256
no
0x
100_Full_Duplex
96
Bus interrupt level

Interrupt priority
Address of bus memory used for DMA
Bus I/O address
DMA arbitration level
TRANSMIT queue size
RECEIVE queue size
Enable ALTERNATE ETHERNET address
ALTERNATE ETHERNET address
Media Speed
InterPacket Gap
False
False
False
False
False
True
True
True
True
True
True
Comment modifier les paramtres ?

Le moyen le plus simple consiste dtacher linterface (ifconfig en0 detach, par exemple)
puis utiliser SMIT > devices > communications > [type carte] > change/show... pour
afficher les paramtres de la carte. Une fois les paramtres affichs, placez le curseur sur
celui que vous souhaitez modifier et appuyez sur F4 pour voir la fourchette des valeurs
minimale et maximale pour ce champ ou les diffrentes tailles possibles. Vous pouvez
slectionner lune de ces tailles et appuyez sur Entre pour valider la requte et mettre
jour la base de donnes ODM. Remettez la carte en ligne (ifconfig en0 [nomhte], par
exemple). Lautre mthode permettant de modifier les paramtres est la commande chdev.
chdev l [ifname] a [nomattribut]=nouvelle_valeur
Par exemple, pour ramener la valeur du paramtre tx_que_size cidessus sur en0
128, utilisez la squence de commandes suivante. Vous noterez que ce gestionnaire
nacceptant que quatre tailles diffrentes, il est prfrable de faire appel SMIT pour voir
quelles sont ces valeurs.
9-17
ifconfig en0 detach

chdev l ent0 a tx_que_size=128
ifconfig en0 [hostname] up
Les informations qui suivent documentent les diffrents paramtres doptimisation de carte.
Ces paramtres et les valeurs indiques concernent AIX 4.3.1 et peuvent tre soumis
modification. Ils sont destins vous aider comprendre les divers paramtres, ou si le
systme nest pas disponible, vous permettre de voir ces paramtres.
Les noms des paramtres, leurs valeurs par dfaut et les fourchettes de valeurs sont issus
de la base de donnes ODM. Le champ de commentaires est issu de la commande
lsattr E l nominterface.
Le champ Remarques contient des commentaires supplmentaires.
Carte MicroChannel (MCA)
Feature Code: 2980
(codename cant say)
Ethernet HighPerformance LAN Adapter (8ef5)
Parameter
Default

xmt_que_size
512
rec_que_size
30
rec_pool_size 37
Range
202048
20150
1664
Comment
Notes

TRANSMIT queue size
SW TX queue
RECEIVE queue size
See Note 1
RECEIVE buffer pool size On Adapter
Remarques :
1. Il sagit dune file de rception logicielle fournie uniquement des fins de compatibilit
avec les applications AIX 3.2.x utilisant linterface du gestionnaire de priphrique
rseau pour lire les paquets directement partir du gestionnaire. Cette file limite le
nombre de paquets entrants qui peuvent tre placs en attente avant dtre reus par
ces applications. Ce paramtre nest dfini que si bos.compat est install.
Cette file dattente nest pas utilise par la pile TCP/IP normale.
Feature Code: 2992
(codename Durandoak)
Ethernet HighPerformance LAN Adapter (8f95)
Parameter
Default
Range
Comment

xmt_que_size
512
202048 TRANSMIT queue size
Notes
SW queue
Feature Code: 2994

(codename SanRemo)
IBM 10/100 Mbps Ethernet TX MCA Adapter (8f62)
Parameter
Default

tx_que_size
64
rx_que_size
32
Range
16,32,64,128,256
16,32,64,128,256
Comment
Notes

TRANSMIT queue size
HW queue
RECEIVE queue size
HW queue
Feature Code: 2970

(codename Monterey)
TokenRing HighPerformance Adapter (8fc8)
Parameter
Default Range

xmt_que_size 99
322048
rec_que_size 30
20150
9-18
Comment
TRANSMIT queue size

RECEIVE queue size
Notes
SW queue
See Note 1
Feature Code: 2972

(codename Wildwood)
TokenRing HighPerformance Adapter (8fa2)
Parameter
Default Range
Comment

xmt_que_size 512
rx_que_size
32
32160
HARDWARE RECEIVE queue size
Notes
SW queue
HW queue
Feature Code: 2727

(codename Scarborgh)
FDDI Primary Card, Single Ring Fiber
Parameter
Default Range

tx_que_size
512
32048
rcv_que_size 30
20150
Comment
Notes

Transmit Queue Size (in mbufs)
Receive Queue
See Note 1
Feature Code: 2984

(codename Bumelia)
100 Mbps ATM Fiber Adapter (8f7f)
Parameter
Default
Range
Comment
Notes

sw_queue
512
02048 Software transmit queue len. SW Queue
dma_bus_width
0x1000000 0x8000000x40000000,0x100000
Amount of memory to map for DMA See Note 3
max_sml_bufs
50
40400
Maximum Small ATM mbufs
Max 256 byte buffers
max_med_bufs
100
401000
Maximum Medium ATM mbufs Max 4KB buffers
max_lrg_bufs
300
751000
Maximum Large ATM mbufs
Max 8KB buffers,
See note 2
max_hug_bufs
50
0400
Maximum Huge ATM mbufs
Max 16KB buffers
max_spec_bufs
4
0400
Maximum ATM MTB mbufs
Max of max_spec_bufsize
spec_buf_size
64
321024
Max Transmit Block (MTB) size kbytes)
sml_highwater
20
10200
Minimum Small ATM mbufs
Min 256 byte buffers
med_highwater
30
20300
Minimum Medium ATM mbufs Min 4KB buffers
lrg_highwater
70
65400
Minimum Large ATM mbufs
Min 8KB buffers
hug_highwater
10
4300
Minimum Huge ATM mbufs
Min 16KB buffers
spec_highwater 20
0300
Minimum ATM MTB mbufs
Min 64KB buffers
best_peak_rate 1500
1155000 Virtual Circuit Peak Segmentation Rate
2. MCA ATM, le ct rcv (rception) utilise galement de grands tampons (8 ko). La

logique de rception nutilise que des tampons de 8 ko ; par consquent, si cette taille se
rvle trop faible, les performances seront affectes.
Les autres tailles de tampons ne sont destines quaux tampons de transmission.
3. MCA ATM, Si vous augmentez le nombre total de tampons, vous aurez peuttre
modifier le paramtre dma_bus_width = 0x1000000. La largeur du bus mmoire
DMA dtermine la quantit totale de mmoire utilise pour les tampons ATM.
Augmentez la valeur de ce paramtre si vous recevez un message derreur lorsque vous
tentez daugmenter le nombre maximum de tampons ou les limites du niveau haut.
Feature Code: 2989
(codename Clawhammer)
155 Mbps ATM Fiber Adapter (8f67)
Parameter
Default
Range

(same as ATM 100 adapter above)
Comment
Notes

9-19
Cartes PCI
Feature Code 2985
(codename Klickitat)
IBM PCI Ethernet Adapter (22100020)
Parameter
Default

tx_que_size
64
rx_que_size
32
Range
Comment

16,32,64,128,256 TRANSMIT queue size
16,32,64,128,256 RECEIVE queue size
Notes
HW Queues
HW Queues
Feature Code 2968

(codename Phoenix)
IBM 10/100 Mbps Ethernet PCI Adapter (23100020)
Parameter
Default
Range
Comment
Notes

tx_que_size
256
16,32,64,128,256 TRANSMIT queue size
HW Queue Note 1
rx_que_size
256
16,32,64,128,256 RECEIVE queue size
HW Queue Note 2
rxbuf_pool_size 384
162048
# buffers in receive Dedicated receive
buffer pool
buffers Note 3
Remarques sur Phoenix :

1. Avant AIX 4.3.2, la valeur par dfaut de tx_queue_size tait 64
2. Avant AIX 4.3.2, la valeur par dfaut de rx_queue_size tait 32
3. AIX 4.3.2, le gestionnaire a ajout un nouveau paramtre pour contrler le nombre de
tampons ddis la rception de paquets.
Feature Code: 2969
(codename Galaxy)
Gigabit EthernetSX PCI Adapter (14100401)
Parameter
tx_que_size
rx_que_size
receive_proc
Default Range

512 5122048
512
512
6
0128
Comment
Notes

Software Transmit Queueu size
SW Queue
Receive queue size
HW Queue
Minimum Receive Buffer descriptors
Feature Code: 2986

(codename Candlestick)
3Com 3C905TXIBM Fast EtherLink XL NIC
Parameter
Default

tx_wait_q_size
32
rx_wait_q_size
32
Range
4128
4128
Comment
Driver TX Waiting Queue Size

Driver RX Waiting Queue Size
Notes
HW Queues
HW Queues
Feature Code: 2742

(codename Honeycomb)
SysKonnect PCI FDDI Adapter (48110040)
Parameter
Default

tx_queue_size
30
RX_buffer_cnt
42
Range
3250
1128
Comment
Notes

Transmit Queue Size
SW Queue
Receive frame count Rcv buffer pool
Feature Code: 2979

(codename Skyline)
IBM PCI Tokenring Adapter (14101800)
Parameter
xmt_que_size
rx_que_size
9-20
Default
96
32
Range
Comment
Notes

SW Queue
32160 HARDWARE RECEIVE queue size HW queue
Feature Code: 2979

(codename Cricketstick)
IBM PCI Tokenring Adapter (14103e00)
Parameter
xmt_que_size
rx_que_size
Default
512
64
Range
322048
32512
Comment
Notes

TRANSMIT queue size SW Queue
RECEIVE queue size
HW Queue
Feature Code: 2988

(codename Lumbee)
IBM PCI 155 Mbps ATM Adapter (14107c00)
Parameter
sw_txq_size
rv_buf4k_min
Default
Range

100
04096
48(0x30) 0512(x200)
Comment
Notes

Software Transmit Queue size
SW Queue
Minimum 4Kbyte premapped receive Buffers
Optimisation de la taille maximum de segment (MSS) TCP

Le protocole TCP comporte un mcanisme permettant aux deux extrmits dune
connexion de ngocier la taille maximale de segment (MSS) utiliser sur la liaison. Chaque
extrmit se sert du champ OPTIONS de lentte TCP pour proposer un MSS. Le MSS
choisi est la plus petite des valeurs proposes par les deux extrmits.
Le but de cette ngociation est dviter les dlais dattente et la baisse de dbit
conscutives la fragmentation des paquets lorsquils passent par des routeurs ou des
passerelles pour ntre rassembls que sur lhte destinataire.
La valeur de MSS indique par le logiciel TCP au cours de la configuration de la connexion
diffre selon que lautre extrmit est un systme local, sur le mme rseau physique
(cest--dire ayant le mme numro de rseau), ou un systme dun rseau distant.
Rseau local
Si lautre systme est local, le MSS notifi par TCP est bas sur le MTU (maximum transfer
unit) de linterface du rseau local :
TCP MSS = MTU taille entte TCP taille entte IP.
Il sagit du maximum possible sans fragmentation IP : cette valeur est donc optimale par
dfinition, et aucune optimisation du MSS nest requise pour les rseaux locaux.
Rseau distant
Lorsque lautre extrmit se trouve sur un rseau distant, TCP sous AIX spcifie pour MSS
une valeur par dfaut de 512 octets. Cette valeur conservatoire est base sur le fait que
tous les routeurs IP prennent en charge un MTU dau moins 576 octets.
Le MSS optimal pour les rseaux distants est bas sur le plus petit MTU des rseaux
intervenant sur la route entre la source et la destination. Il sagit gnralement dun nombre
dynamique qui ne peut tre tabli que par une certaine recherche au niveau du MTU du
chemin. Le protocole TCP ne fournit aucun mcanisme permettant de dterminer ce
nombre, cest pourquoi la valeur par dfaut est couramment adopte. Il est toutefois
possible de lancer une recherche du PMTU TCP laide de la commande :
no o tcp_pmtu_discover=1
Lun des effets secondaires de ce paramtre est laugmentation de la table de routage (une
entre de plus par connexion TCP active). Loption de la commande no route_expire doit
avoir une valeur non nulle afin que toute entre de routage en mmoire cache non utilise
soit supprime de la table lissue de la dure dinactivit route_expire.
9-21
Cette valeur par dfaut, qui convient bien Internet en gnral, peut se rvler inutilement
restrictive pour les interrseaux dun domaine administratif. Dans un environnement de ce
type, les tailles des MTU des rseaux physiques constitutifs sont connues et le MTU
minimal de mme que le MSS optimal peuvent tre dtermins par ladministrateur. AIX
offre plusieurs moyens pour forcer TCP utiliser ce MSS optimal. Les htes source et cible
doivent tous deux prendre en charge ces fonctions. Dans un environnement htrogne,
multifournisseur, la disponibilit de la fonction sur les deux systmes peut tre un facteur
dterminant dans le choix de la solution.
Routes statiques
Pour passer outre la valeur par dfaut de MSS (512), il suffit de spcifier une route statique
vers un rseau distant spcifique et dassocier loption mtu la commande route pour
spcifier le MTU ce rseau. Dans ce cas, spcifiez le MTU minimal effectif de la route, au
lieu de calculer une valeur MSS.
Dans un environnement stable et limit, cette mthode permet un contrle prcis du MSS
rseau par rseau. Elle prsente nanmoins quelques inconvnients :
Elle est incompatible avec le routage dynamique.
Elle devient peu pratique si le nombre de rseaux distants devient consquent.
Les routes statiques doivent tre dfinies aux deux extrmits, pour que les deux cts
ngocient avec un MSS suprieur au MSS par dfaut.
Option tcp_mssdflt de la commande no
La valeur par dfaut (512) adopte par TCP pour les rseaux distants peut tre modifie via
le paramtre tcp_mssdflt de la commande no. La modification sapplique lensemble du
systme.
La valeur destine remplacer la valeur de MSS par dfaut doit tre la valeur minimale de
MTU diminue de 40 pour laisser la place aux en-ttes TCP et IP.
Dans un environnement o le MTU est suprieur au MTU par dfaut, cette mthode offre
lavantage dliminer la ncessit de dfinir le MSS rseau par rseau. Inconvnients :
Augmenter la valeur par dfaut peut entraner une fragmentation au niveau du routeur IP
si la destination se trouve sur un rseau rellement loign et que les MTU des rseaux
intervenants sont inconnus.
Le paramtre tcp_mssdflt doit avoir la mme valeur sur lhte destination.
Sous-rseau et option subnetsarelocal de la commande no
Il est possible de faire partager plusieurs rseaux physiques le mme numro de rseau,
par le biais de sous-rseaux (voir Adressage TCP/IP). Loption subnetsarelocal de la
commande no spcifie, sur lensemble du systme, si les sous-rseaux doivent tre
considrs comme locaux ou distants. Avec subnetsarelocal=1 (valeur par dfaut), lhte A
sur le sous-rseau 1 considre lhte B sur le sous-rseau 2 comme se trouvant sur le
mme rseau physique.
La consquence est que lorsque les htes A et B tablissent une connexion, ils ngocient le
MSS en supposant quils se trouvent sur le mme rseau. Chaque hte indique un MSS sur
la base du MTU de son interface rseau. Ce qui conduit gnralement au choix dun MSS
optimal.
Cette approche prsente plusieurs avantages :
Elle ne requiert aucun liaison statique ; MSS est automatiquement ngoci.
Elle ne dsactive ni ne supplante la ngociation du MSS par TCP : de lgres diffrences
de MTU entre rseaux adjacents peuvent ainsi tre correctement gres.
9-22
Inconvnients :
Risque de fragmentation au niveau du routeur IP lorsque deux rseaux fort MTU sont
relis via un rseau faible MTU. La figure Fragmentation intersousrseaux illustre
ce problme.
hte
A
FDDI
routeur 1
MTU = 4 352
Ethernet
routeur 2
MTU = 1 500
FDDI
hte
B
MTU = 4 352
Fragmentation inter-sous-rseaux
Dans ce scnario, les htes A et B tablissement une connexion sur la base dun MTU
commun de 4 352. Un paquet transitant de A vers B sera fragment par le routeur 1 et
dfragment par le routeur 2 (et vice versa).
Source et destination doivent considrer les sous-rseaux comme locaux.
Optimisation des performances du protocole IP

Au niveau de la couche IP, le seul paramtre optimisable est ipqmaxlen, qui contrle la
longueur de la file dentre IP cite prcdemment (qui nexiste que sous AIX version 3).
Les paquets peuvent arriver trs vite et saturer cette file dentre. Sous AIX, il ny a aucun
moyen simple de savoir si cela sest produit. Seul un compteur de dpassement peut tre
affich via la commande crash. Pour vrifier cette valeur, lancez la commande crash et,
linvite, entrez : knlist ipintrq. Le rsultat est une valeur hexadcimale, variable
selon le systme. Ajoutez ensuite 10 (hexa) cette valeur et indiquez le total comme
argument de la commande od. Par exemple :
# crash
> knlist ipintrq
ipintrq: 0x0149ba68
> od 0149ba78 1
0149ba78: 00000000 <
Valeur du compteur de dplacement de la

file dentre IP
>quit
Si le nombre rsultant est strictement positif, un dpassement a eu lieu. La longueur
maximale de cette file dattente est dfinie via la commande no. Par exemple :
no o ipqmaxlen=100
permet la mise en file dattente de 100 paquets. La valeur exacte utiliser est dtermine
par la vitesse maximale de rception en rafale. Si celle-ci ne peut tre dtermine, le
nombre de dpassement peut aider dterminer laugmentation requise. Laugmentation de
la taille de la file dattente ninduit aucune consommation mmoire supplmentaire. Cette
augmentation peut nanmoins allonger le temps pass dans le gestionnaire dinterruption
hors niveau, dans la mesure o IP doit traiter davantage de paquets dans sa file dentre.
Ce qui risque daffecter le temps CPU requis par les processus. Le choix est entre un faible
taux de rejet de paquets et la disponiblit de la CPU pour dautres traitements. Le mieux est
daugmenter ipqmaxlen par petits incrments si le choix nest pas vident.
Optimisation des performances Ethernet

Ethernet a contribu llaboration de lalgorithme du plus petit commun dnominateur
pour le choix du MTU. Si une configuration inclut des rseaux Ethernet et dautres rseaux
locaux, et que le trafic est soutenu, les MTU de tous les rseaux devront peut-tre tre
dfinis 1 500 octets pour viter la fragmentation lorsque les donnes arrivent sur un
rseau Ethernet.
9-23
La valeur par dfaut (1 500), qui est aussi la valeur maximale de MTU, ne doit pas tre
modifie.
La taille de bloc de lapplication doit tre un multiple de 4 096 octets.
Les paramtres relatifs lespace socket peuvent conserver leur valeur par dfaut.
Si la charge de travail prvoit une utilisation intensive de services faisant appel UDP,
tels que NFS ou RPC, il convient daugmenter la valeur de sb_max pour prendre en
compte le fait que chaque MTU de 1 500 octets utilise un tampon de 4 096 octets.
Optimisation des performances anneau jeton (4 Mo)

La valeur par dfaut de MTU (1 492 octets) convient aux rseaux en anneau jeton
interconnects des rseaux Ethernet ou des rseaux htrognes dont le MTU minimal
est inconnu.
Sauf en cas de trafic intense entre le rseau et les rseaux externes, le MTU doit tre
augment sa valeur maximale (3 900 octets).
tels que NFS ou RPC, il convient daugmenter la valeur de sb_max pour prendre en
compte le fait que chaque MTU de 1 492 octets utilise un tampon de 4 096 octets.
Optimisation des performances anneau jeton (16 Mo)

La valeur par dfaut de MTU (1 492 octets) convient aux rseaux en anneau jeton
interconnects des rseaux Ethernet ou des rseaux htrognes dont le MTU minimal
est inconnu.
Sauf en cas de trafic intense entre le rseau et les rseaux externes, le MTU doit tre
augment la valeur de 8 500 octets. Ce qui permet aux paquets NFS de 8 ko de tenir
dans un seul MTU. Augmenter encore le MTU son maximum de 17 000 octets entrane
rarement une amlioration significative du dbit.
tels que NFS ou RPC, et que le MTU doit conserver sa valeur par dfaut cause des
interconnexions, il convient daugmenter la valeur de sb_max pour prendre en compte le
fait que chaque MTU de 1 492 octets utilise un tampon de 4 096 octets.
Optimisation des performances FDDI

En dpit dun MTU relativement faible, ce support haute vitesse tire parti des augmentations
substantielles de la taille du tampon de socket.
Sauf en cas de trafic intense entre le rseau et les rseaux externes, le MTU doit
conserver sa valeur par dfaut (4 352 octets).
Lorsque possible, une application exploitant TCP doit crire par tranches de multiples de
4 096 octets la fois (8 ou 16 ko de prfrence), pour un dbit maximal.
Spcifiez no o sb_max=(2*nouvelle-taille) pour relever le plafond de lespace tampon
du socket.
Spcifiez no o *_*space=nouvelle-taille pour donner lespace denvoi et de rception
du socket TCP et UDP la valeur par dfaut de nouvel-espace. Nouvelespace doit tre
au moins gal 57 344 octets (56 ko).
9-24
Pour ESCALA modle *90 ou plus rapide, utilisez no o rfc1323=1 pour que la taille des
tampons de socket puisse tre dfinie une valeur suprieure 64 ko. Suivez ensuite la
procdure prcdente avec nouvelle-taille au moins gal 128 ko.
Optimisation des performances ATM

Sauf en cas de trafic intense entre le rseau et les rseaux externes, le MTU doit
conserver sa valeur par dfaut (9 180 octets).
4 096 octets la fois (8 ou 16 ko de prfrence), pour un dbit maximal.
Spcifiez no o sb_max=(2*nouvelle-taille) pour relever le plafond de lespace tampon
du socket.
Spcifiez no o *_*space=nouvelle-taille pour donner lespace denvoi et de rception
du socket TCP et UDP la valeur par dfaut de nouvel-espace. nouvelespace doit tre
au moins gal 57 344 octets (56 ko).
Pour ESCALA modle *90 ou plus rapide, utilisez no o rfc1323=1 pour que la taille des
tampons de socket puisse tre dfinie une valeur suprieure 64 ko. Suivez ensuite la
procdure prcdente avec nouvelle-taille au moins gal 128 ko.
Optimisation des performances SOCC

Le MTU doit conserver sa valeur par dfaut (61 428 octets).
28 672 octets la fois (28 ko), pour un dbit maximal.
La valeur par dfaut de lespace denvoi et de rception du socket TCP et UDP doit tre
dfinie 57 344 octets.
Optimisation des performances HIPPI

Le MTU doit conserver sa valeur par dfaut (65 536 octets).
Lorsque possible, une application exploitant TCP doit crire par tranches de
65 536 octets la fois, pour un dbit maximal.
Donnez sb_max une valeur suprieure 2*655 360.
La valeur par dfaut de lespace denvoi et de rception du socket TCP et UDP doit tre
dfinie 655 360 octets. Spcifiez no o rfc1323=1 pour que la taille des tampons de
socket puisse tre dfinie une valeur suprieure 64 ko.
9-25
Optimisation du pool mbuf

Remarque : Cette section ne concerne que la version 3.2.5. Sous AIX version 4.1, le
mcanisme daffectation des mbuf est sensiblement diffrent. Vous pouvez fixer la
quantit maximale de mmoire qui sera utilise par le programme daffectation du
rseau, comme vous le faites sous la version 3.2.5, cest--dire avec la commande no et
le paramtre thewall. Les autres options doptimisation disponibles sous la version 3.2.5
ont t supprimes de la version 4.1 car le mcanisme daffectation des mbuf a une
fonction doptimisation automatique.
Le sous-systme rseau utilise une fonction de gestion de la mmoire qui dpend dune
structure de donnes appele mbuf. Les mbuf servent essentiellement stocker des
donnes entrantes et sortantes du rseau. Disposer de pools mbuf de la taille adquate
peut amliorer sensiblement les performances du rseau. A linverse, une configuration
inadquate des pools mbuf affecte les performances rseau et systme. Le systme
dexploitation AIX permet de configurer le pool mbuf en cours dexploitation. Cet avantage
suppose de savoir quand et comment adapter les pools.
Cest lobjet des sections suivantes :
Fonction de gestion des mbuf : gnralits
Optimisation des pools mbuf : quand ?
Optimisation des pools mbuf : comment ?
Fonction de gestion des mbuf : gnralits

La fonction de gestion des mbuf contrle deux pools de tampons : un pool de tampons de
faible capacit (256 octets chacun), simplement appels mbuf, et un pool de tampons de
capacit leve (4 096 octets chacun), gnralement appels grappes mbuf ou grappes.
Les pools sont crs partir de la mmoire systme, par une requte daffectation au
gestionnaire de mmoire virtuelle (VMM). Les pools sont constitus dlments fixes de
mmoire virtuelle ce qui signifie quils rsident en permanence en mmoire physique et ne
font jamais partie de pages vacues. En consquence, la capacit de mmoire relle,
disponible pour la pagination dans les programmes dapplication et les donnes, est
diminue dun volume quivalent laugmentation de la capacit des pools mbuf. Ne
loubliez pas lorsque vous augmentez la taille des pools mbuf.
La taille initiale des pools mbuf dpend du systme. Un nombre minimal de (petits) mbufs et
de grappes est affect chaque systme, mais ces minimums sont augments en fonction
de la configuration spcifique des systmes. Un des facteurs pris en compte est le nombre
de cartes de communication quipant le systme. La taille par dfaut est initialement
configure pour grer des rseaux de charge faible moyenne (trafic de 100
500 paquets/seconde). La taille des pools augmente dynamiquement avec laugmentation
de la charge du rseau. Le pool de grappe diminue si la charge du rseau diminue (le pool
mbuf nest jamais rduit). Pour optimiser les performances du rseau, ladministrateur doit
quilibrer la taille des pools mbuf en fonction de la charge du rseau (paquets/seconde). Si
cette dernire est axe sur le trafic UDP (comme sur un serveur NFS, par exemple), la taille
du pool mbuf doit tre double du taux de paquets/seconde. Ceci parce que le trafic UDP
consomme un petit mbuf supplmentaire.
Pour assurer lefficacit du service daffectation de mbuf, il est tentant de maintenir libres en
permanence un minimum de tampons dans les pools. Les paramtres lowmbuf et lowclust
permettent (via la commande no) de dfinir ces limites infrieures.
Le paramtre lowmbuf spcifie le nombre minimal de tampons libres du pool mbuf. Le
paramtre lowclust spcifie le nombre minimal de tampons libres du pool de grappe.
Lorsque le nombre de tampons passe en-de du seuil dfini par lowmbuf ou lowclust, les
pools sont agrandis. Cette extension nest pas immdiate, mais planifie pour tre effectue
par un service du noyau appel netm. Lorsque le service netm est distribu, les pools sont
9-26
agrandis de faon rpondre aux minimums dfinis par lowclust et lowmbuf. Cest la
structure VMM qui impose que cette opration soit le fait dun processus du noyau.
Le service de noyau netm limite en outre la croissance du pool de grappes. Le paramtre
mb_cl_hiwat dfinit cette limite suprieure.
Le paramtre mb_cl_hiwat contrle le nombre maximal de tampons libres que peut
contenir le pool de grappes. Lorsque le seuil dfini par mb_cl_hiwat est dpass, netm est
planifi pour librer quelques grappes et les restituer VMM.
Le systme de noyau netm est excut selon une priorit leve (fixe 37). De ce fait,
distribuer trop de netm peut avoir un effet ngatif non seulement sur les performances du
rseau, mais galement sur celles du systme pour cause de conflit avec les autres
processus utilisateur et systme. Des pools mal configurs peuvent provoquer
lemballement des netm, d des incompatibilits entre les besoins du trafic rseau et des
seuils mal dfinis. La distribution du systme de noyau netm peut tre minimise en
configurant les pools mbuf pour quils rpondent aux besoins du rseau et du systme.
La fonction de gestion mbuf se sert encore dun dernier paramtre rseau, thewall.
thewall contrle la taille de RAM maximale (en kilo-octets) susceptible dtre affecte par la
fonction de gestion mbuf partir de VMM. Ce paramtre sert viter tout dsquilibre des
ressources VMM, qui aurait un fcheux effet sur les performances systme.
Optimisation des polls mbuf : quand ?

Quand et de quelle quantit optimiser les pools mbuf est directement li la charge du
rseau laquelle est soumise une machine donne. Un serveur grant plusieurs clients fait
partie des machines dont il est bon doptimiser les pools mbuf. Pour ce faire, il est essentiel
que ladministrateur connaisse bien la charge du rseau pour un systme donn.
Vous pouvez, via la commande netstat, connatre approximativement la charge du rseau
en paquets/seconde. Par exemple :
netstat I tr0 5
indique le trafic en entre et en sortie, issu de la carte tr0 et de toutes les cartes LAN du
systme. Le listing ci-dessous indique lactivit entrane par une vaste opration
provoque par une commande ftp :
$ netstat I tr0 2
input
(tr0)
output
20615
227
3345
0
0
17
0
1
0
0
174
0
320
0
0
248
0
443
0
0
210
0
404
0
0
239
0
461
0
0
253
1
454
0
0
246
0
467
0
0
99
1
145
0
0
13
0
1
0
0
input
packets
20905
17
174
248
210
239
253
246
99
13
(Total)
output
errs packets errs colls
227
3635
0
0
0
1
0
0
0
320
0
0
0
443
0
0
0
404
0
0
0
461
0
0
1
454
0
0
0
467
0
0
1
145
0
0
0
1
0
0
9-27
La commande netstat peut tre assortie dun indicateur, m, qui donne des dtails sur
lusage et la disponibilit des mbuf et des grappes :
253 mbufs in use:
50 mbufs allocated to data
1 mbufs allocated to packet headers
76 mbufs allocated to socket structures
100 mbufs allocated to protocol control blocks
10 mbufs allocated to routing table entries
14 mbufs allocated to socket names and addresses
2 mbufs allocated to interface addresses
16/64 mapped pages in use
319 Kbytes allocated to network (39% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
La ligne 16/64 mapped pages in use indique quil existe 64 grappes fixes, dont 16
sont actuellement utilises.
Ce compte rendu peut tre compar aux paramtres systme dfinis, via la commande no
a. Les lignes intressantes cet gard sont :
lowclust
lowmbuf
thewall
mb_cl_hiwat
=
=
=
=
29
88
2048
58
Il est clair que sur le systme test, les 319 Kbytes allocated to network sont trs
en-de de la valeur de thewall (2 048 ko) et que les (64 16 = 48) grappes libres sont
galement en-de de la limite mb_cl_hiwat (58).
Le compteur requests for memory denied, tenu jour par la fonction de gestion des
mbuf, est incrment chaque fois quune requte daffectation de mbuf naboutit pas.
Normalement, la valeur de requests for memory denied est 0. Si une surcharge de
trafic se produit sur un systme, les pools mbuf configurs par dfaut peuvent se rvler
insuffisants : le compteur derreur est alors incrment chaque fois quune requte
daffectation de mbuf choue. Le compteur atteint rapidement des chiffres de lordre des
milliers, compte tenu du nombre de paquets arrivant dans un court laps de temps. Les
statistiques requests for memory denied correspondent aux paquets abandonns sur
le rseau. Ces paquets supposent des retransmissions, cest--dire une baisse des
performances. Si la valeur de requests for memory denied est suprieure zro, il
peut tre utile doptimiser les paramtres mbuf voir Optimisation des pools mbuf
comment ?.
Le dcompte Kbytes allocated to the network, tenu jour par la fonction de
gestion des mbuf, reprsente la quantit de mmoire systme actuellement affecte aux
deux pools mbuf. La limite suprieure de ce dcompte, dfinie par thewall, permet
dempcher la fonction de gestion mbuf de consommer trop de mmoire physique sur un
systme. La valeur par dfaut de thewall limite cette fonction 2 048 ko (comme indiqu
sur le comte rendu gnr par la commande no a). Si la valeur de Kbytes allocated
to the network est proche de thewall, il peut tre utile doptimiser les paramtres mbuf.
Reportez-vous Optimisation des pools mbuf : comment ?.
Il est des cas o les indicateurs ci-dessus laissent supposer quil faut tendre les pools
mbuf, alors quen fait, il y a un problme systme auquel il convient dabord de remdier.
Par exemple :
manque de mmoire mbuf
donnes en attente non lues partir dun socket ou dune autre structure dattente
interne.
9-28
Une perte de mmoire mbuf dnote une situation dans laquelle un code noyau ou une
extension noyau a omis de librer une ressource mbuf et dtruit le pointeur vers
lemplacement mmoire correspondant, perdant tout jamais ladresse du mbuf. Si cette
situation est rcurrente, toutes les ressources mbuf finiront par tre inaccessibles. Si les
statistiques mbuf gnres par netstat montrent un accroissement progressif de lusage
des mbuf, naccusant jamais de baisse, ou une utilisation intensive des mbuf sur un
systme relativement peu charg, il y a sans doute une perte de mmoire mbuf.
Les dveloppeurs dextensions noyau se doivent de toujours intgrer dans leurs tests un
contrle sur les pertes de mmoire.
Il se peut galement que de nombreux mbuf restent en attente dans un socket suite une
erreur dans une application. Normalement, un programme dapplication lit les donnes dun
socket, entranant la rattribution des mbuf la fonction de gestion du mbuf.
Un administrateur peut grer les statistiques gnres par la commande netstat m et
chercher un ventuel usage intensif du mbuf alors que le trafic rseau ne le justifie pas. Il
peut galement examiner la liste des processus en cours (via ps ef) et tudier de prs
ceux qui utilisent le sous-systme rseau avec une forte consommation de temps CPU.
Il convient alors disoler lapplication en cause et de la corriger.
Optimisation des polls mbuf : comment ?

Avec un minimum de connaissance sur leur organisation et leur gestion, optimiser les pools
mbuf est, sous AIX, une opration simple, qui peut tre effectue en cours dexploitation.
Lutilisateur racine dispose de la commande no pour modifier les paramtres du pool mbuf.
Voici quelques rgles :
Si vous modifiez les attributs lowclust et lowmbuf, vous devrez peut-tre commencer
par augmenter thewall, pour viter que lextension du pool natteigne le seuil thewall.
Dans tous les cas, la valeur de lattribut mb_cl_hiwat doit tre au moins double de celle
de lowclust. Ceci pour viter tout emballement de netm (voir plus haut).
Si vous modifiez lowclust, vous devez modifier lowmbuf dune valeur au moins
quivalente. Il existe un mbuf pointant sur chaque grappe.
Aprs extension des pools, lancez la commande vmstat pour vrifier que les taux de
pagination nont pas augment. Si vous ne parvenez pas amener les pools au niveau
souhait sans pour autant affecter les taux de pagination, un supplment de mmoire est
sans doute prvoir.
Voici un exemple de script shell qui peut tre excut la fin de /etc/rc.net pour optimiser
les pools mbuf pour un serveur NFS prenant en charge un trafic rseau denviron
1500 paquets/seconde.
9-29
#!/bin/ksh
# echo Tuning mbuf pools...
# set maximum amount of memory to allow for allocation (10MB)
no o thewall=10240
# set minimum number of small mbufs
no o lowmbuf=3000
# generate network traffic to force small mbuf pool expansion
ping 127.0.0.1 1000 1 >/dev/null
# set minimum number of small mbufs back to default to prevent netm from
# running unnecessarily
no d lowmbuf
# set maximum number of free clusters before expanding pool
# (about 6MB)
no o mb_cl_hiwat=1500
# gradually expand cluster pool
N=10
while [ $N lt 1500 ]
do
no o lowclust=$N
ping 127.0.0.1 1000 1 >/dev/null
let N=N+10
done
# set minimum number of clusters back to default to prevent netm
# from running unnecessarily
no d lowclust
Vous pouvez lancer netstat m la suite du script ci-dessus pour vrifier la taille du pool
de grappes (appeles pages mappes par la commande netstat ). Pour vrifier la taille du
pool de mbuf, vous disposez de la commande crash qui permet dexaminer une structure
de donnes noyau, mbstat (voir le fichier /usr/include/sys/mbuf.h). Ladresse du noyau de
mbstat peut tre affiche dans le cadre de crash, via la commande od mbstat. Entrez
ensuite od <adresse-noyau> pour obtenir un clich du premier mot de la structure
mbstat, qui contient la taille du pool mbuf. Si vous utilisez AIX version 4.1 ou version 3.2
avec pTF U437500, le dialogue est semblable :
$ crash
> od mbstat
001f7008: 00000180
> quit
La taille du pool mbuf est ainsi de 18016 (38410).
Si vous utilisez AIX version 3.2 sans le PTF U437500, le dialogue est semblable :
$ crash
> od mbstat
000e2be0: 001f7008
> od 1f7008
001f7008: 00000180
> quit
La taille du pool mbuf est ainsi de 18016 (38410).
9-30
Rcapitulatif des paramtres doptimisation UDP, TCP/IP et

mbuf
Les paragraphes suivants rpertorient tous les attributs et techniques doptimisation pour
chacun des paramtres doptimisation des communications.
thewall
Objet :
Limite suprieure absolue de la quantit de mmoire relle susceptible

dtre utilise par le sous-systme de communication.
Valeurs :
AIX 4.2.1 et versions antrieures : Par dfaut : 1/8 de la mmoire relle.

Intervalle : jusqu 1/2 de la mmoire relle ou 65536 (64 mgaoctets),
selon la plus petite valeur.
AIX 4.3.0 : Par dfaut : 1/8 de la mmoire relle. Intervalle : jusqu 1/2 de
la mmoire relle ou 131072 (128 mgaoctets), selon la plus petite
valeur.
AIX 4.3.1 : Par dfaut : 1/2 de la mmoire relle. Intervalle : jusqu 1/2 de
la mmoire relle ou 131072 (128 mgaoctets), selon la plus petite
valeur.
Affichage :
no a ou no o thewall
Modification :
no o thewall=nouvelle-valeur
nouvelle-valeur est en ko, et non en octets.
La modification est immdiate pour les nouvelles connexions.
La modification est effective jusqu lamorage systme suivant.
Diagnostics :
Aucun.
Optimisation : Augmentez la taille, de prfrence un multiple de 4 ko.

Voir :
Optimisation du pool mbuf, page 9-26.
Objet :
Sous AIX Version 4.3.1 ou ultrieure, permet dviter la cration de

nouveaux sockets lorsque presque toute la mmoire rseau est utilise.
Valeurs :
Par dfaut : 85% de thewall. Intervalle : 1100
Affichage :
no a or no o sockthresh
Modification :
no o sockthresh=nouvelle-valeur
sockthresh
nouvellevaleur est un pourcentage de thewall.

La modification est immdiate.
Remarque : La modification choue si lutilisateur tente de
slectionner une nouvelle valeur infrieure la quantit de mmoire
actuellement utilise.
Diagnostics :
Aucun.
Optimisation : Diminuez le pourcentage.

Voir :
Couche socket, page 9-3.
9-31
sb_max
Objet :
Limite suprieure absolue de la taille des tampons de socket TCP et UDP.

Limite setsockopt(), udp_sendspace, udp_recvspace, tcp_sendspace
et tcp_recvspace.
Valeurs :
Par dfaut : 65536 Intervalle : N/A.
Affichage :
no a ou no o sb_max
Modification :
no o sb_max=nouvelle-valeur
Diagnostics :
Aucun.
Optimisation : Augmentez la taille, de prfrence un multiple de 4 096. Doit tre

environ double de la limite du plus grand tampon de socket.
Voir :
Objet :
1 indique que tcp_sendspace et tcp_recvspace peuvent dpasser

64 ko.
Valeurs :
Par dfaut : 0 Intervalle : 0 ou 1
Affichage :
no a ou no o rfc1323
Modification :
no o rfc1323=nouvelle-valeur
rfc1323

Diagnostics :
Aucun.
Optimisation : Effectuez la modification avant de tenter de donner tcp_sendspace et

tcp_recvspace une valeur suprieure 64 ko.
Voir :
Couche TCP, page 9-6.
udp_sendspace
Objet :
Valeur par dfaut de la taille du tampon denvoi du socket UDP.
Valeurs :
Par dfaut : 9216 Intervalle : 0 65536

Doit tre infrieur ou gal sb_max.
Affichage :
no a ou no o udp_sendspace
Modification :
no o udp_sendspace=nouvelle-valeur
Diagnostics :
Aucun.
Optimisation : Augmentez la taille, de prfrence un multiple de 4 096.

Voir :
udp_recvspace
Objet
Valeur par dfaut de la taille du tampon de rception du socket UDP.
Valeurs :

9-32
Affichage :
no a ou no o udp_recvspace
Modification :
no o udp_recvspace=nouvelle-valeur
Diagnostics :
n non nul dans le compte rendu de netstat s de udp: n socket buffer

overflows

Voir :
tcp_sendspace
Objet
Valeur par dfaut de la taille du tampon denvoi du socket TCP.
Valeurs :
Par dfaut : 16384 Intervalle : 0 64 ko si rfc1323=0,

Intervalle : 0 4 Go si rfc1323=1.
Doit tre gal tcp_recvspace et uniforme sur tous les systmes AIX
frquemment sollicits.
Affichage :
no a ou no o tcp_sendspace
Modification :
no o tcp_sendspace=nouvelle-valeur
Diagnostics :
Dbit faible

Voir :
tcp_recvspace
Objet :
Valeur par dfaut de la taille du tampon de rception du socket TCP.
Valeurs :
Par dfaut : 16384 Intervalle : 0 64 ko si rfc1323=0,

Doit tre gal tcp_sendspace et uniforme sur tous les systmes AIX
Affichage :
no a ou no o tcp_recvspace
Modification :
no o tcp_recvspace=nouvelle-valeur
Diagnostics :
Dbit faible

Voir :
Objet :
Nombre maximal dentres de la file dentre IP.
Valeurs :
ipqmaxlen
9-33
Affichage :
no a ou no o ipqmaxlen
Modification :
no o ipqmaxlen =nouvelle-valeur
Diagnostics :
Utilisez la commande crash pour accder au compteur de dpassement

de la file dentre IP.
Optimisation : Augmentez la taille.

Voir :
Optimisation des performances du protocole IP, page 9-23.
xmt_que_size
Objet :
Spcifie le nombre maximal de tampons denvoi susceptibles dtre en file

dattente pour lunit.
Valeurs :
Affichage :
lsattr E l tok0 a xmt_que_size
Modification :
ifconfig tr0 detach

chdev I tok0 a xmt_que_size=nouvelle-valeur
ifconfig tr0 nom-hte up
Le changement reste effectif mme aprs ramorage du systme.
Diagnostics :
netstat i
Oerr > 0
Optimisation : Augmentez la taille. Doit tre naturellement dfinie 150 sur les systmes
orients rseau, et notamment les serveurs.
Voir :
Cartes rseau local et pilotes dunits, page 9-11.
rec_que_size
Objet :
(optimisable sous AIX version 3 exclusivement). Spcifie le nombre

maximal de tampons de rception qui peuvent tre en file dattente pour
linterface.
Valeurs :
Affichage :
lsattr E l tokn a rec_que_size
Modification :
ifconfig tr0 detach

chdev I tokn a rec_que_size=nouvelle-valeur.
Le changement reste effectif mme aprs ramorage du systme.
Diagnostics :
Aucun.
Optimisation : Augmentez la taille. Doit tre naturellement dfinie 150 sur les systmes
orients rseau, et notamment les serveurs.
Voir :
9-34
MTU
Objet :
Limite la taille des paquets transmis via le rseau.
Valeurs :
trn (4 Mo) : Par dfaut : 1492 Intervalle : 60 3900

trn (16 Mo) : Par dfaut : 1492 Intervalle : 60 17960
enn: Par dfaut : 1500 Intervalle : 60 1500
fin: Par dfaut : 4352 Intervalle : 60 4352
hin: Par dfaut : 65536 Intervalle : 60 65536
son: Par dfaut : 61428 Intervalle : 60 61428
lon: Par dfaut : 1500 (version 3.2.5), 16896 (AIX version 4.1), Intervalle :
60 65536
Affichage :
lsattr E l trn
Modification :
chdev l trn a mtu=nouvelle-valeur.

Ne peut tre modifi en cours dexploitation de linterface. Tous les
systmes du rseau local (LAN) devant tre dots du mme MTU, ils
doivent tre modifis simultanment. Le changement reste effectif mme
aprs ramorage.
Diagnostics :
Statistiques de fragmentation de paquets
Optimisation : Augmentez la taille MTU pour les interfaces en anneau jeton :

trn (4 Mo) : 4056
trn (16 Mo) : 8500
Pour linterface en boucle lon sous la version 3.2.5, augmentez 16896.
Pour les autres interfaces, conservez la valeur par dfaut.
Voir :
Voir aussi
Les commandes crash, ifconfig, lsattr, netstat et no.
La sousroutine setsockopt.
9-35
Optimisation de NFS
NFS fournit des programmes dun systme un accs transparent des fichiers sur un
autre systme, par le biais du montage du rpertoire distant (via mount). Normalement,
lamorage du serveur, la commande exportfs rend les rpertoires disponibles, et les
dmons grant le tl-accs (nfsd) sont lancs. De mme, le montage des rpertoires
distants et linitialisation du nombre requis de biod pour la gestion du tl-accs sont
effectus au cours de lamorage du systme client.
La figure Interaction client-serveur NFS illustre la structure du dialogue entre un serveur et
des clients NFS. Lorsquune routine dun systme client tente de lire ou dcrire un fichier
dans un rpertoire mont par NFS, la requte est rachemine du mcanisme dE/S normal
vers lun des dmons dE/S par bloc NFS du client (biod). Le biod envoie la demande au
serveur ad hoc, o il est affect lun des dmons NFS du serveur (nfsd). Pendant le
traitement de cette requte, ni le biod ni le nfsd concern nexcutent aucune tche.
client A
routine m
serveur Z
biod i
nfsd a
biod j
nfsd b
biod k
biod a
nfsd c
.
.
nfsd x
biod b
nfsd y
biod c
nfsd z
LAN
client B
routine n
Interaction client-serveur NFS
Nombre de biod et de nfsd requis

Les biod et les nfsd ne traitant quune requte la fois, et le dlai de rponse NFS tant
souvent le plus important du total du temps de rponse, il nest pas souhaitable que des
routines soient bloques suite labsence dun biod ou dun nfsd. Voici quelques
remarques sur la configuration des dmons NFS :
Augmenter le nombre de dmons ne peut compenser un dfaut de mmoire ou de
puissance du client ou du serveur, ou linadquation de la largeur de bande du disque
serveur. Avant de changer le nombre de dmons, vrifiez, via les commandes iostat et
vmstat, les niveaux dutilisation des ressources serveur et client.
Les dmons NFS sont relativement peu coteux : un biod consomme 36 ko de mmoire
(9 pages dont 4 fixes), un nfsd en consomme 28 ko (7 pages dont 2 fixes). Bien entendu,
les pages non fixes ne se trouvent en mmoire relle que si nfsd ou biod a t
rcemment actif. En outre, les nfsd AIX inactifs ne consomment pas de temps CPU.
Toutes les requtes NFS passent par un nfsd, seules les lectures et critures passent
par un biod.
Nombre initial de nfsd et de biod

Dterminer le bon nombre de nfsd et de biod est un processus itratif. Les estimations
empiriques ne constituent au mieux quun point de dpart.
Par dfaut, il existe six biod sur un client et huit nfsd sur un serveur. Ces valeurs par dfaut
constituent un point de dpart satisfaisant pour les petits systmes, mais devront srement
tre augmentes sur les systmes client grant plus de deux utilisateurs ou les serveurs
grant plus de deux clients. Voici quelques conseils :
9-36
Pour chaque client, estimez le nombre maximal de fichiers susceptibles dtre crits
simultanment. Configurez au moins deux biod par fichier. Si les fichiers sont
volumineux (plus de 32 ko), vous pouvez commencer avec quatre biod par fichier pour
prendre en charge les activits de lecture anticipe ou dcriture diffre. Il nest pas rare
de mobiliser cinq biod pour crire un fichier volumineux.
Sur chaque serveur, commencez par configurer autant de nfsd que la somme des biod
configurs sur les clients pour grer les fichiers partir de ce serveur. Ajoutez 20 % pour
les requtes NFS autres que de lecture/criture.
Si les stations client sont rapides, mais connectes un serveur plus lent, vous devrez
peut-tre limiter le taux de gnration des requtes NFS mises par les clients. Le mieux
est de rduire le nombre de biod sur les clients, en tenant compte de limportance
relative de la charge et du temps de rponse de chaque client.
Optimisation du nombre de nfsd et de biod

Aprs avoir dtermin ou modifi le nombre initial de biod et de nfsd :
Contrlez nouveau les systmes concerns, via vmstat et iostat, la recherche de
saturation au niveau des E/S ou de la CPU. Si le serveur est satur, vous devez diminuer
sa charge ou augmenter sa puissance, ou les deux.
Lancez netstat s pour dterminer si un systme nest pas confront un dpassement
de tampon de socket UDP. Dans laffirmative, lancez no a pour vrifier que les conseils
indiqus Optimisation des autres couches pour amliorer les performances NFS,
page 9-39 ont bien t suivis. Si oui, et que le systme nest pas satur, augmentez le
nombre de biod ou de nfsd.
La commande chnfs permet de modifier le nombre de nfsd et de biod. Ainsi, pour dfinir
10 le nombre de nfsd sur un serveur, immdiatement et chaque ramorage, entrez :
# chnfs n 10
Pour dfinir temporairement 8 le nombre de biod sur un client, sans prenniser le
changement (perdu lamorage suivant), entrez :
# chnfs N b 8
Pour dfinir 9 le nombre de biod et de nfsd, le changement ne prenant effet qu
lamorage (IPL) suivant du systme, entrez :
# chnfs I b 9 n 9
Dans le cas, extrme, dun client provoquant une surcharge du serveur, vous devrez
peut-tre ramener le client un seul biod. Pour ce faire, lancez la commande :
# stopsrc s biod
Le client ne dispose plus que du biod kproc.
Performances et montages logiciels et matriels de NFS

Un des choix que vous serez amens faire lorsque vous configurez des rpertoires
monts via NFS est de dcider si le montage est logiciel ou matriel. Si, aprs un montage
russi, laccs un rpertoire mont logiquement gnre une erreur (dpassement de
dlai, le plus souvent), lerreur est immmdiatement reporte au programme qui a demand
le tl-accs. Si une erreur est gnre lors de laccs un rpertoire mont physiquement,
NFS relance lopration.
Une erreur persistante au niveau de laccs un rpertoire mont physiquement peut
entraner une nette dgradation des performances, car le nombre de ressais par dfaut
(1 000) et le dlai par dfaut (0,7 seconde), combins un algorithme qui augmente le dlai
imparti chaque nouvelle tentative, conduit NFS relancer lopration pratiquement
indfiniment (tant quelle naboutit pas).
Il est techniquement possible de rduire le nombre de relances, ou daugmenter la valeur
du dlai, ou les deux, via les options de la commande mount. Malheureusement, modifier
9-37
substantiellement ces valeurs (pour supprimer effectivement le problme de performance)

peut entraner lindication inutile derreurs matrielles. Mieux vaut monter physiquement les
rpertoires avec loption intr, qui permet lutilisateur dinterrompre partir du clavier un
processus se trouvant dans une boucle de relance.
Bien que le montage logiciel des rpertoires permette une dtection plus rapide des erreurs,
le risque est grand que des donnes soient endommages. Pour les rpertoires de
lecture/criture, optez de prfrence pour un montage physique.
Optimisation des retransmissions

Paralllement au choix du type de montage (physique ou logique), se pose la question du
dlai imparti dans une configuration donne. Si le serveur est trs charg, quil est spar
du client par un ou plusieurs ponts ou passerelles, ou quil est connect au client via un
WAN, le dlai imparti par dfaut peut se rvler peu raliste. Dans ce cas, serveur et client
se retrouveront surchargs par des retransmissions inutiles. Si, par exemple :
$ nfsstat cr
gnre un nombre significatif (> 5 % du total) de timeout s et de badxid s, il convient
daugmenter la valeur du paramtre timeo via :
# smit chnfsmnt
Identifiez le rpertoire modifier, et entrez une nouvelle valeur sur la ligne NFS TIMEOUT.
In tenths of a second. Pour un trafic LAN-LAN via un pont, essayez 50 (diximes de
seconde). Pour une connexion WAN (longue distance), essayez 200. Aprs au moins une
journe, vrifiez les statitisques NFS. Si elles indiquent toujours un nombre excessif de
retransmissions, augmentez encore timeo de 50 % et ressayez. Vrifiez galement la
charge du serveur et des ponts et passerelles concerns, pour dterminer si un lment est
satur par un trafic autre.
Optimisation du cache dattribut de fichier NFS

NFS tient jour, sur chaque systme client, un cache des attributs des rpertoires et des
fichiers auxquels un accs a rcemment t effectu. Cinq paramtres, dfinissables dans
le fichier /etc/filesystems, contrlent la dure de maintien dune entre dans le cache.
Il sagit de :
actimeo
Dure absolue pendant laquelle les entres fichier et rpertoire sont

conserves dans le cache des attributs de fichier aprs une mise jour.
Si elle est spcifie, elle prvaut sur les valeurs *min et *max ci-aprs,
leur donnant effectivement la valeur actimeo.
acregmin
Dure minimale pendant laquelle les entres fichier sont conserves

aprs une mise jour. Valeur par dfaut : 3 secondes.
acregmax
Dure maximale pendant laquelle les entres fichier sont conserves

aprs une mise jour. Valeur par dfaut : 60 secondes.
acdirmin
Dure minimale pendant laquelle les entres rpertoire sont

conserves aprs une mise jour. Valeur par dfaut : 30 secondes.
acdirmax
Dure maximale pendant laquelle les entres rpertoire sont

conserves aprs une mise jour. Valeur par dfaut : 60 secondes.
Chaque fois quun fichier ou un rpertoire est mis jour, sa suppression est diffre dau
moins acregmin ou acdirmin secondes. Sil sagit dune deuxime ou nime mise jour,
lentre est conserve pendant une dure au moins gale lintervalle entre les deux
dernires mises jour, sous rserve quelle reste infrieure acregmax ou acdirmax
secondes.
9-38
Dsactivation du support ACL NFS inutilis

Si votre charge de travail nexploite pas le support ACL de NFS sur un systme de fichiers
mont, vous pouvez rduire la charge du serveur et du client en spcifiant :
options = noacl
dans la strophe /etc/filesystems du client, pour ce systme de fichiers.
Optimisation de la mise en cache des donnes NFS

NFS ne propose pas de fonction de mise en cache de donnes, mais le gestionnaire de
mmoire virtuel (VMM) dAIX cache les pages de donnes NFS exactement comme les
pages de donnes disque. Si un systme est prioritairement un serveur NFS ddi, il peut
tre souhaitable dautoriser le VMM utiliser autant de mmoire que ncessaire pour
cacher les donnes. Pour ce faire, donnez la valeur 100 % au paramtre maxperm, qui
contrle le pourcentage maximal de mmoire occup par les pages de fichier, via la
commande :
# vmtune P 100
La mme technique peut sappliquer aux clients NFS, mais na de sens que si leur charge
de travail ne requiert que trs peu de pages de segments de travail.
Optimisation des autres couches pour amliorer les performances NFS

NFS passe par UDP pour effectuer ses E/S rseau. Assurez-vous que les techniques
doptimisation dcrites Optimisation de TCP et UDP, page 9-12 et Optimisation du pool
mbuf, page 9-26 ont t appliques. Vous devez, notamment :
Vrifiez que les files de transmission et de rception de la carte LAN sont dfinies leur
maximum (150).
Passez la taille maximale du tampon du socket (sb_max) au moins 131 072. Si la taille
du MTU est infrieure 4 096 octets, donnez sb_max une valeur suprieure ou gale
262 144. Donnez galement la taille des tampons de socket UDP (udp_sendspace
et udp_recvspace) la valeur 131 072.
Si possible, augmentez la taille du MTU sur le rseau local. Sur un anneau jeton
16 Mo, par exemple, passer de la taille par dfaut (1 492 octets) 8 500 octets permet
de transmettre sans fragmentation une requte de lecture ou dcriture complte NFS de
8 ko. Cette opration optimise galement lexploitation de lespace mbuf, rduisant les
risques de surcharges.
Augmentation de la taille du tampon du socket NFS

Au cours de loptimisation dUDP, vous pouvez dcouvrir que la commande :
$ netstat s
indique un nombre non ngligeable de dbordements du tampon du socket UDP. Comme
pour loptimisation classique dUDP, vous devez augmenter la valeur de sb_max. Vous
devez galement augmenter la valeur de nfs_chars, qui spcifie la taille du tampon, du
socket NFS. La squence :
#
#
#
#
no o sb_max=131072
nfso o nfs_chars=130000
stopsrc s nfsd
startsrc s nfsd
donne sb_max une valeur dau moins 100 octets suprieure la valeur souhaite de
nfs_chars, donne nfs_chars la valeur 130 972, puis arrte et relance les nfsd pour que
les nouvelles valeurs entrent en vigueur. Si vous constatez que cette modification amliore
les performances, insrez les commandes no et nfso dans /etc/rc.nfs, juste avant la
commande startsrc qui lance les nfsd.
9-39
Configuration du disque du serveur NFS

Pour les serveurs NFS qui ont faire face un niveau lev dactivit dcriture, vous avez
intrt configurer le volume logique journal sur un volume physique distinct de celui des
donnes. Reportez-vous Prinstallation du disque, page 4-24.
Acclrateurs matriels
Prestoserve
Le but du produit Prestoserve est de rduire le temps de latence des critures NFS, en
proposant une mthode plus rapide que les E/S disque pour satisfaire limpratif NFS
dcritures synchrones. Il fournit de la RAM non volatile (NVRAM) dans laquelle NFS peut
crire des donnes. Les donnes sont alors considres comme en scurit et NFS peut
autoriser le client poursuivre. Les donnes sont crites ultrieurement sur un disque, en
fonction de la disponibilit des units. Enfin, il est impossible de dpasser la largeur de
bande du disque, mais dans la mesure o lessentiel du trafic NFS est en rafales,
Prestoserve permet daplanir la charge de travail sur le disque, avec des gains de
performance parfois considrables.
Interphase Network Coprocessor

Ce produit gre le traitement du protocole NFS sur les rseaux Ethernet, rduisant la
charge de la CPU. Le traitement du protocole NFS est particulirement onreux sur les
rseaux Ethernet, car les blocs NFS doivent tre fractionns pour correspondre la taille de
MTU maximale (1 500 octets) de Ethernet.
Du bon usage de NFS

Le plus souvent, lexploitation incorrecte de NFS est due au fait que les utilisateurs oublient
que les fichiers auxquels ils accdent se trouvent lautre extrmit dune voie de
communication coteuse. Quelques exemples (rels) :
Une application COBOL sous un systme AIX effectuant des mises jour alatoires dun
fichier dinventaire mont via NFS prenant en charge une application de registre de
caisse de dtail en temps rel.
Environnement de dveloppement dans lequel un rpertoire de code source sur chaque
systme a t mont via NFS sur tous les autres systmes dans lenvironnement
les dveloppeurs se connectant nimporte quel systme pour modifier leurs
programmes et les compiler. Cette structure garantit quasi-invitablement que le code
source de toutes les compilations est import depuis des systmes distants, et
rciproquement pour le rsultat des compilations.
Excution de la commande ld sur un systme pour transformer les fichiers .o dun
rpertoire mont via NFS en fichier a.out dans le mme rpertoire.
Il peut tre argu quil sagit l dune exploitation lgitime de la transparence offerte par
NFS. Sans doute, mais ces pratiques cotent du temps processeur, consomment de la
largeur de bande et augmentent les temps de rponse. Lorsquun systme est configur de
sorte que laccs NFS fasse partie des opration standard, les concepteurs de cette
configuration doivent pouvoir dfendre leur choix si coteux par de substantiels avantages
techniques ou commerciaux :
Disposer de toutes les donnes ou du code source sur un serveur, et non sur des postes
individuels amliore le contrle du code source et facilite la centralisation des
sauvegardes.
Plusieurs systmes ont accs aux mmes donnes, rendant un serveur ddi plus
efficace quun ou plusieurs systmes combinant les rles de client et de serveur.
9-40
Service des stations de travail sans disque

Potentiellement, les systmes sans disque offrent une excellente puissance de traitement
couple un faible cot, une mission sonore rduite, peu de besoin despace et une
gestion centralise des donnes. Aussi tentants que semblent ces avantages, les stations
sans disque ne sont pas forcment lidal pour tous les bureaux. Cette section a pour but
dclairer certains aspects du fonctionnement des stations sans disque AIX : types de
charges prsentes aux serveurs et performances de diffrents types de programmes.
Lessentiel de ce qui traite de NFS ici sapplique galement aux stations avec disques.
Particularits dun systme sans disque
Remarques sur NFS
Excution dun programme sur une station de travail sans disque
Pagination
Ressources requises pour une station de travail sans disque
Optimisation des performances
Performances des commandes
Etude de cas 1 Environnement de bureau
Etude de cas 2 Environnement de dveloppement de logiciels
Particularits dun systme sans disque

Dans un systme quip de disques locaux (appel systme disque), le systme
dexploitation et les programmes requis pour la plupart des fonctions de base se trouvent
sur un ou plusieurs disques locaux. Au lancement du systme, le systme dexploitation est
charg partir du disque local. Lorsque le systme est compltement oprationnel, les
fichiers accessibles aux utilisateurs se trouvent galement sur disque local. Les disques
locaux sont grs par le systme JFS (systme de fichiers journalis).
Dans un systme sans disque, il faut amorcer le systme dexploitation partir dun serveur
via un code damorage se trouvant dans la ROM de la machine sans disque.
Le chargement a lieu sur un rseau local : Ethernet ou anneau jeton. Lorsque le systme
est compltement oprationnel, les fichiers accessibles aux utilisateurs se trouvent sur les
disques dun ou de plusieurs systmes serveur.
NFS (Network File System) est le principal mcanisme utilis par les stations de travail sans
disque pour accder aux fichiers. Avec NFS, les fichiers distants semblent se trouver sur le
systme sans disque. NFS nest pas propre aux systmes sans disque. Les systmes
disque peuvent galement monter des systmes de fichiers distants. Les systmes sans
disque, ou disque mais dpendant de serveurs pour les fichiers, sont gnralement
appels des clients.
Normalement, plusieurs clients sans disque sont relis chaque serveur, il y a donc
concurrence pour laccs aux ressources serveur. La diffrence de performance entre deux
systmes identiques, lun dot de disque et lautre non, dpend des systmes de fichiers
(NFS ou JFS), de la vitesse du rseau et des ressources du serveur.
Remarques sur NFS

NFS (Network File System) multiplie les accs client aux donnes tlmontes. Il fournit
des primitives pour les fonctions de base (cration, lecture, criture, suppression, etc. des
systmes de fichiers). NFS assure galement des oprations sur les rpertoires
(suppression, lecture et dfinition des attributs, consultation du chemin daccs, etc.).
Le protocole utilis par NFS est sans tat : aucune requte au serveur ne dpend dune
requte antrieure. Ce qui ajoute la solidit du protocole. Mais qui introduit galement des
9-41
problmes de performances. Considrons le cas de lcriture dun fichier. Pendant cette

criture, les donnes modifies se trouvent soit dans la mmoire client, soit sur le serveur.
Le protocole NFS requiert que les donnes crites du client vers le serveur soient
consignes dans un espace de stockage non volatil (le disque gnralement) avant que
lcriture ne soit considre termine. Ainsi, en cas de dfaillance du serveur, les donnes
crites par le client peuvent tre recouvres aprs rinitialisation du systme. Les donnes
en cours dcriture, non consignes sur le disque sont rcrites par le client sur le serveur
jusqu ce que lopration aboutisse. NFS nautorisant pas la mise en tampon des critures
dans le serveur, chaque criture NFS requiert une ou plusieurs critures disque
synchrones. Par exemple, si un nouveau fichier de 1 octet est crit par le client, lexcution
de cette criture entrane trois E/S disque sur le serveur : la premire sont les donnes
elles-mme. La seconde est lenregistrement du journal, une fonction JFS destine
maintenir dintgrit du systme de fichiers. La troisime est un clich des donnes
dallocation de fichier. Les critures sur disque tant limites 50 100 par seconde, le
total des sorties dcriture est limit par le nombre et le type de disque du serveur.
Les requtes de lecture/criture mises par les clients AIX sont de 4 096 ou 8 192 octets.
Elles requirent gnralement plus de ressources serveur que les autres types de requtes.
Les fichiers distants et leur attributs pouvant se trouver dans la mmoire cache du client, le
protocole NFS fournit un outil permettant de vrifier que la version client des informations
sur le systme de fichiers est jour. Par exemple, si un fichier de 1 octet est en cours de
lecture, le fichier de donnes sera en mmoire cache tant que lespace quil occupe sur le
client nest pas rquisitionn par une autre activit. Si un programme du client relit le fichier
plus tard, le client assure que les donnes de la copie locale du fichier sont actuelles. Cette
opration est effectue par le biais dun appel Get Attribute au serveur pour dterminer si le
fichier a t modifi depuis sa dernire lecture.
La rsolution des noms de chemin est le processus de parcours de larborescence des
rpertoires jusquau fichier. Par exemple, ouvrir le fichier /u/x/y/z requiert normalement
dexaminer /u, x, y et z, dans cet ordre. Si un des lments du chemin nexiste pas, le
fichier ne peut exister sous son nom. Un des caches NFS est ddi aux noms frquemment
utiliss, rduisant dautant le nombre de requtes achemines vers le serveur.
Le serveur reoit videmment un panachage de requtes de lecture, dcriture et autres, au
cours dun intevalle de temps quelconque. Ce panachage est quasi-impossible prvoir.
Les travaux qui impliquent de frquents dplacements de fichiers volumineux entranent
une prdominance des requtes de lecture/criture. La prise en charge de plusieurs
stations sans disque tend gnrer une proportion plus importante de petites requtes NFS
mais tout dpend beaucoup de la charge de travail.
Excution dun programme sur une station de travail sans disque

Pour mieux apprhender le flux des requtes NFS sur un client sans disque, tudions
lexcution du shell Korn du programme trivial C :
#include <stdio.h>
main()
{
printf(Ceci est un programme test\n);
}
Le programme est compil, gnrant lexcutable a.out. Si la variable denvironnement
PATH est /usr/bin:/usr/bin/X11:(le point reprsentant le rpertoire de travail courant
se trouve la fin du chemin) et que la commande a.out est entre sur la ligne de
commande, voici la squence excute :
9-42
type de requte
composant
octets envoys et reus
NFS_LOOKUP
usr (appel par statx)
(send 178, rcv 70)
NFS_LOOKUP
bin
NFS_LOOKUP
a.out
(non trouv)
NFS_LOOKUP
usr (appel par statx)
NFS_LOOKUP
bin
NFS_LOOKUP
X11
(send 174, rcv 156)
NFS_LOOKUP
a.out (non trouv)
(send 174, rcv 70)
NFS_LOOKUP
. (appel par statx)
(send 174, rcv 156)
NFS_LOOKUP
10
NFS_LOOKUP
a.out
11
NFS_LOOKUP
. (appel par accessx)
12
NFS_LOOKUP
a.out
13
NFS_GETATTR
a.out
14
NFS_LOOKUP
15
NFS_LOOKUP
a.out
16
fork
17
exec
18
NFS_LOOKUP
usr
19
NFS_LOOKUP
bin
20
NFS_LOOKUP
a.out (non trouv)
21
NFS_LOOKUP
usr
22
NFS_LOOKUP
bin
23
NFS_LOOKUP
X11
24
NFS_LOOKUP
a.out (non trouv)
25
NFS_LOOKUP
26
NFS_LOOKUP
a.out
27
NFS_OPEN
28
NFS_GETATTR
29
NFS_ACCESS
30
NFS_GETATTR
a.out
31
FS_GETATTR
a.out
32
NFS_READ
a.out (excutable Read)
33
NFS_GETATTR
a.out
34
NFS_LOOKUP
usr (Access library)
35
NFS_LOOKUP
lib
36
NFS_LOOKUP
libc.a
37
NFS_READLINK
libc.a
38
NFS_LOOKUP
usr
39
NFS_LOOKUP
ccs
40
NFS_LOOKUP
lib
(send 178, rcv 156)
(send 170, rcv 104, send 190,

rcv 168)
(send 178, rcv 70)
(send 178, rcv 70)
(send 166, rcv 138)

a.out
(send 170, rcv 104, send 190,
rcv 182)
(send 178, rcv 1514, rcv 1514,

rcv 84)
(send 166, rcv 80)
9-43
41
NFS_LOOKUP
libc.a
42
NFS_OPEN
libc.a
43
NFS_GETATTR
libc.a
44
NFS_ACCESS
libc.a
45
NFS_GETATTR
libc.a
46
NFS_GETATTR
libc.a
47
NFS_CLOSE
libc.a
48
_exit
(send 166, rcv 124)

(send 170, rcv 104, send 190,
rcv 178)
Avec une autre variable PATH, la srie doprations NFS serait diffrente. Par exemple,
avec la variable PATH .:/usr/bin:/usr/bin/X11: , le programme a.out aurait t
trouve plus rapidement. A linverse, avec ce PATH, la plupart des commandes auraient t
excutes plus lentement, car elles rsident presque toutes dans /usr/bin. Un autre
moyen rapide dexcuter le programme est dentrer ./a.out, dans la mesure o il est
inutile de parcourir lexcutable (la rsolution de bibliothque est nanmoins toujours
requise). Ajouter un nombre important de rpertoires peu utiliss au chemin (PATH) ralentit
lexcution des commandes. Ceci sapplique tous les environnements, mais est
particulirement significatif dans les environnements sans disque.
Un autre facteur prendre en compte lors du dveloppement de programmes est la
minimisation du nombre de bibliothques rfrences. Il est vident que plus il y a de
bibliothques charger, moins lexcution du programme est rapide. La variable
denvironnement LIBPATH peut galement affecter la vitesse de chargement du
programme. Soyez donc prudent lorsque vous lutilisez.
Le support NLS (National Language Support) peut aussi avoir une incidence sur lexcution
des programmes. Dans lexemple prcdent, lexcution avait lieu dans lenvironnement
local C, le plus efficace. Lexcution dans dautres environnements peut induire une
charge supplmentaire lors de laccs aux catalogues de messages.
A premire vue, lactivit NFS pour un petit programme semble disproportionne. En fait,
les performances de lexemple restent dans des normes acceptables. Noubliez pas que la
rsolution de chemin pour laccs aux fichiers est galement effectue pour les systmes
de fichiers JFS : le nombre total doprations est donc similaire. Le cache NFS assure que
les oprations NFS ne gnreront pas toutes de trafic rseau. Au total, les dlais de latence
des oprations rseau restent gnralement courts, et le cumul des dlais pour les
commandes peu lev sauf si le serveur est lui-mme surcharg.
Pagination
Les systmes sans disque AIX effectuent la pagination via le protocole NFS. La pagination
est le processus par lequel lespace de travail (variables du programme, par exemple) peut
tre crit et lu sur disque. Cette opration a lieu lorsque la somme des besoins en mmoire
des processus excuts sur un systme est suprieure la mmoire systme.
(Reportez-vous Performances du gestionnaire de la mmoire virtuelle (VMM), page 2-5.)
Les avantages de la pagination sont mitigs. Elle permet certes dviter de surcharger la
mmoire, mais gnralement aux dpens des performances. En fait, seule une faible dose
de pagination maintient des temps de rponse acceptables dans un environnement de
stations de travail.
Dans lenvironnement sans disqsue, la pagination est particulirement lente. Ceci est d au
protocole NFS qui force les critures sur disque. En pratique, on peut considrer quau
mieux, lcriture dune page prendra deux trois fois plus de temps que sur un systme
disque. Compte tenu de ce fait, il est important que les systmes sans disque disposent de
suffisamment de mmoire pour que les applications excutes naient pas besoin de
recourir la pagination. (Voir Programmes CPU limite.)
9-44
Les produits bureautiques AIXwindows favorisent les attitudes conduisant des priodes de
pagination intense sur des systmes dpourvus de mmoire suffisante. Par exemple, un
utilisateur peut lancer simultanment deux programmes : un tableur consquent dans une
fentre et une base de donnes dans une autre. Supposons quil mette jour une feuille de
calcul, attende le rsultat puis passe la fentre base de donnes pour interroger la base.
Bien que le tableur soit inactif, il occupe un espace non ngligeable. Interroger une base de
donnes requiert galement beaucoup despace. Sauf si la mmoire relle est suffisante
pour contenir ces deux programmes, les pages de mmoire virtuelle du tableur sont
pagines vers lextrieur et la base de donnes charge. A linteraction suivante de
lutilisateur avec le tableur, la mmoire occupe par la base de donnes doit tre pagine,
et le tableur recharg. En clair, les limites de cette situation sont dtermines par la
frquence de passage dune fentre lautre et par la charge qui incombe alors au serveur.
Ressources requises pour les stations de travail sans disque

Plusieurs services AIX permettent de mesurer la charge client-serveur. Le nombre de
requtes NFS traites par un systme est accessible via nfsstat. Cette commande
dcompte en dtail les requtes NFS par catgorie. La commande netstat analyse le
dcompte de paquets et doctets transfrs une unit du rseau. La commande iostat
dtaille lutilisation du processeur et du disque paramtres utiles pour les mesures sur les
systmes serveur. Enfin, lutilitaire de suivi AIX permet de rassembler des donnes prcises
sur les performances.
Planifier la capacit de rseaux sans disque est une tche souvent complique par
lintermittence des requtes dE/S des clients courtes priodes enregistrant des pointes de
requtes entrecoupes de longues priodes o le taux de requte est trs bas.
Ce phnomne est courant sur les systmes o les applications sont principalement
pilotes par les utilisateurs.
La capacit, cest--dire le nombre de clients pris en charge par un serveur et un rseau
pour une charge de travail donne, est dtermine par les statistiques des requtes et les
besoins des utilisateurs finals. Quelques questions doivent tre poses.
Quelle est la frquence relle dexcution de ce travail ? Normalement, un utilisateur
passe lessentiel de son temps des tches autres que la compiltaion et ldition de liens
de programmes. Supposer que tous les autres utilisateurs passent tout leur temps en
interaction avec leur station de travail une vitesse maximale conduit une
surestimation du nombre dutilisateurs susceptibles dtre pris en charge.
Quelle est lutilisation moyenne acceptable du rseau ? Pour les rseaux Ethernet, le
pourcentage est de 30 60 %, selon le site.
Quelle est la probabilit quun nombre important de clients se trouvent simultanment
dans une priode dutilisation de pointe du rseau ? Dans une telle priode, les temps de
rponse augmentent. Quelle est la frquence de ces pointes simultanes ? Quelle est
leur dure ?
Il est parfois intressant de tl-excuter les applications volumineuses. Excuter
lapplication sur un serveur, via une fentre distante, donne au client lavantage de
bnficier de la mmoire du serveur et permet plusieurs instances de lapplication
appeles par diffrents clients de partager des pages de code et des fichiers document.
Si lapplication est excute sur le client, les passages dune fentre lautre, tels que
dcrits prcdemment, ont une incidence catastrophique sur les temps de rponse.
Dautres tches, impliquant par exemple de vastes et intenses oprations make ou cp,
peuvent galement bnficier du dplacement de lapplication proximit des disque fixes.
Lors de la configuration des rseaux et des serveurs pour des clients sans disque, il
convient deffectuer ds que possible les mesures relatives aux applications. Noubliez pas
de mesurer lutilisation du processeur du serveur ainsi que celle du disque. Ces rseaux
sont plus susceptibles de prsenter des goulots dtranglement que les rseaux Ethernet ou
en anneau jeton 16 Mo.
9-45
Optimisation des performances

La capacit dune configuration client/serveur doit tre pense en termes de fourniture et de
demande. La fourniture des ressources dpend du type du rseau et de la configuration du
serveur. La demande est la somme de tous les besoins client vis--vis du serveur. Si une
configuration gnre des performances inacceptables, modifier la demande client ou
augmenter la fourniture des ressources serveur ne peut quamliorer la situation.
Le taux dutilisation correspond au pourcentage de temps pendant lequel une unit est
mobilise. Les units dont le taux dutilisation est suprieur 70 % constateront rapidement
un allongement des temps de rponse, les requtes entrantes devant attendre la fin du
traitement de la requte prcdente. Les taux dutilisation acceptables maximum sont un
compromis entre temps de rponse et dbit. Sur un systme interactif, le taux dutilisation
des units ne doit pas excder 70 80 % pour des temps de rponse acceptables. Les
systmes en diffr, o le dbit des flux de travaux multiples est important, peuvent
tourner quasi 100 %. Dans des systmes mixtes (interactifs et diffrs), il convient bien
entendu de ne pas trop grver les temps de rponse.
Optimisation du client
Plusieurs oprations peuvent concourir loptimisation dun client :
Ajout de mmoire client
Augmentation du nombre des dmons biod du client NFS
Modification de la configuration rseau du client
Ajout dun disque la configuration client
Si la mmoire dun client est insuffisante, lespace de travail est pagin. Ce qui peut tre
dtect via la commande vmstat s. Si lespace de travail dun client est en permanence
pagin, ajouter de la mmoire ne peut quamliorer ses performances.
Le nombre de dmons dE/S par bloc (biod) configurs sur un client limite le nombre de
requtes de lecture et dcriture NFS en suspens. Sur un systme sans disque sur lequel
NFS na pas t explicitement activ, seuls quelques biod sont disponibles. Si NFS est
activ, ce nombre augmente. Normalement, le nombre de biod disponibles par dfaut avec
NFS activ est suffisant pour une station sans disque.
Les pilotes dunit Ethernet et en anneau jeton sont assortis de paramtres qui dfinissent
la taille des files de transmission et de rception pour lunit. Ces paramtres peuvent avoir
une incidence sur les performances client. Voir Optimisation des autres couches pour
amliorer les performances NFS, page 9-39.
Ajouter un disque une station sans disque nest pas une hrsie : en fait, des tudes
marketing ont montr que les systmes sans disque sont gnralement quips dun
disque dans lanne qui suit leur achat. Ajouter un disque ne met pas en cause le principal
avantage des systmes sans disque la maintenance centralise des fichiers. Le disque
peut tre rserv la pagination. On parle alors dun systme sans donnes. Dautres
combinaisons sont possibles. Un disque peut par exemple contenir de lespace de
pagination et de lespace pour les fichiers temporaires.
Optimisation du rseau
La largeur de bande dun rseau est, nominalement, de 10 megabits/seconde. Dans la
pratique, la concurrence entre utilisateurs Ethernet rend impossible lexploitation de
lintgralit de la largeur de bande. Sachant quun disque SCSI Bull peut fournir jusqu
32 megabits/seconde, il est inquitant de voir de nombreux clients partager le mme quart
de largeur de bande dun disque. Cette comparaison ne vaut, toutefois, que pour les
applications qui effectuent des E/S disque squentielles ce qui nest pas le plus courant,
les E/S alatoires (limites en temps de recherche et dlai de rotation) tant nettement plus
frquentes. La plupart des disques SCSI ayant un dbit soutenu de 50 85 oprations
dE/S alatoires par seconde, le taux effectif dE/S alatoires dun disque est de
2 - 3 mgabits/seconde. Ainsi, une largeur de bande Ethernet est sensiblement quivalente
9-46
deux disques effectuant des E/S alatoires. Il convient den tirer une leon : les
applications effectuant des E/S squentielles sur des fichiers volumineux doivent tre
excutes sur le systme auquel est rattach le disque, et non sur une station sans disque.
Bien que le MTU (Maximum Transfer Unit) dun rseau local (LAN) puisse tre modif via
SMIT, les stations sans disque sont limites leur valeur par dfaut.
Optimisation du serveur
La configuration du serveur fait intervenir :
CPU du serveur
Configuration du disque du serveur
Configuration du NFS du serveur
Configuration de la mmoire du serveur
Configuration du rseau du serveur
La puissance de traitement de la CPU du serveur est significative car toutes les requtes
serveur font appel au service CPU. Gnralement, le traitement CPU requis par les
requtes de lecture/criture est sensiblement suprieur celui requis par les autres
requtes.
La configuration du disque du serveur est gnralement le premier goulot dtranglement
rencontr. Une technique doptimisation vidente consiste quilibrer les E/S disque de
sorte quaucune utilisation disque ne soit largement suprieure une autre. Une autre
technique est de maximiser le nombre de disques. Par exemple, deux disques de 400 Mo
offrent prs de deux fois plus de possibilits dE/S alatoires par seconde quun seul disque
de 857 Mo. En outre, avec AIX, il est possible de placer un historique du journal sur une
autre unit. Cettet opration amliore la squence dcritures NFS multiple comme suit :
Ecriture des donnes sur un disque fichier
Ecriture de lhistorique du journal sur le disque journal (pas de recherche de disque)
Ecriture des donnes daffectation de fichier sur disque fichier (recherche de disque peu
importante)
De par labsence du journal sur le disque fichier, une ou deux recherches potentiellement
longues sur le disque sont vites. (Si le fichier et lhistorique du journal se trouvaient sur un
mme disque peu charg, laccesseur passeraient continuellement de la zone de fichier la
zone de lhistorique de journal, et vice-versa.)
Le nombre dinstances du dmon NFS (nfsd) excutes sur le serveur limite le nombre de
requtes NFS excutables concuremment par le serveur. Le nombre de nfsd par dfaut
nest que de 8, ce qui nest gnralement suffisant que pour les serveurs dentre de
gamme. Le nombre de nfsd lancs chaque amorage peut tre modifi via smit nfs
(Network File System (NFS) > Configuration NFS sur ce systme).
La taille de la mmoire du serveur nest significative que pour les oprations de lecture
NFS. Dans la mesure o les critures ne peuvent tre places en mmoire cache, la taille
de la mmoire est sans incidence sur les performances relatives lcriture. Dautre part,
en supposant que certains fichiers sont utiliss rptition, plus la mmoire du serveur est
leve, plus grande est la probabilit quune lecture puisse tre satisfaite par la mmoire,
en vitant une E/S disque. Gagner une E/S disque rduit le taux dutilisation du disque,
amliore les temps de rponse pour les lectures et diminue le taux dutilisation de la CPU
du serveur. Vous disposez de la commande iostat pour tudier lactivit du disque.
Les indices suivants rvlent quun supplment de mmoire peut amliorer les
performances du serveur :
Un ou plusieurs pilotes de disque oprent presque la limite de leurs capacits
(40 85 E/S alatoires par seconde). Voir Prinstallation du disque, page 4-24.
9-47
Sur une priode de quelques minutes ou plus, le nombre doctets lus est sensiblement
suprieur au nombre doctets crits.
Comme le client, les pilotes dunit Ethernet et en anneau jeton sont limits quant au
nombre de tampons disponibles pour lenvoi des donnes. Voir Optimisation des autres
couches pour amliorer les performances NFS, page 9-39.
Performance des commandes

Les commandes AIX subissent le mme type dactions que celles constates lors de
lexcution dun programme trivial (voir Excution dun programme sur une station de
travail sans disque, page 9-42). Le comportement des commandes peut tre dduit du type
et du nombre doprations sur les sytmes de fichiers quelles requirent. Les commandes
impliquant de nombreuses consultations de fichiers, telles que find, ou de
lectures/critures, telles que cp, sont excutes beaucoup plus lentement sur un systme
sans disque. La figure Rsultats des tests donne une ide des performances sur un
systme sans disque de quelques commandes usuelles.
mkdir
rmdir
bc
dc
vi
pack
more
cat
cmp
grep
sort
join
wc
cut
diff3
cc
cp
find
ld
make
tar
ar
modr
lev
awk
diff
minimal
ls
echo
pwd
rm
ps
court
dure normale
relative sur
systme
disque
long
dure augmente lorsque

excut sur un systme sans disque
Rsultats des tests
La pnalit subie par une commande sur un client sans disque est exprime comme le
rapport entre le temps requis sur systme disque et le temps requis sur un systme sans
disque. Ce taux est intressant, mais pas toujours important. Par exemple, si une
commande demande 0,05 seconde sur un systme disque et 0,2 seconde sur un systme
sans, la pnalit est de quatre. Mais est-ce vraiment important pour lutilisateur final ?
Un temps de rponse de 0,2 seconde est tout fait suffisant pour un individu normal...
Mais si la commande se trouve dans un script shell et est excute 100 fois, le temps de
rponse du script passe de 5 20 secondes, ce qui est dj plus gnant. Cest pourquoi il
convient dviter dattribuer des stations sans disque des utilisateurs qui lancent souvent
des scripts shell complexes.
9-48
Etude de cas 1 Environnement de bureau

Pour tudier les caractristiques des E/S client, nous avons mesur la charge reprsentant
un environnement de bureau avec un seul utilisateur par client, sur un ESCALA modle 220
sans disque 16 Mo. La charge tudie consiste crer un fichier, laide de lditeur vi,
avec une vitesse de frappe de 6 caractres/seconde, excuter les utilitaires nroff, spell et
cat sur le document. Le document est transfr via tftp sur le serveur. Dautres commandes
sont galement lances : cal, calendar, rm et mail, ainsi quun petit programme qui
consulte les numros de tlphone. Des temps de rflexion simuls sont intercals entre
les commandes.
Les figures Utilisation du CPU serveur dans un environnement bureautique et Utilisation
du disque serveur dans un environnement bureautique illustrent lutilisation des ressources
du disque et du CPU du serveur pour la charge tudie. Le serveur est un modle 530H
avec un disque dur de 857 Mo. Le client excutant le travail est un seul modle 220. La
charge est intermittente (en rafales) les pics dutilisation tant disproportionns par
rapport au taux moyen.
La figure Paquets/seconde dans un environnement bureautique Ethernet illustre les
variations du taux de requtes dE/S pendant la dure dexcution du travail. Le taux NFS
moyen est de 9.5 requtes/seconde, avec une pointe 249 requtes/seconde. La figure
Octets/seconde dans un environnement bureautique Ethernet indique le nombre doctets
transfrs par seconde (activit du protocole comprise). Le taux de transfert moyen est de
4 000 octets/seconde, avec une pointe 114 341 octets/seconde. Ce travail consomme en
moyenne 1/300me de la largeur de bande nominale dun rseau Ethernet, avec une pointe
1/11me dutilisation.
La moyenne dutilisation de CPU serveur par client tant de 2% %, la moyenne dutilisation
de disque serveur par client de 2.8% % et la moyenne dutilisation du rseau Ethernet de
0.3% %, le disque sera probablement la ressource critique si plusieurs occurrences de ce
travail font appel un seul serveur.
30
25
20
%
utilisation
CPU
15
10
5
0
dure
Utilisation de la CPU serveur dans un environnement bureautique
9-49
22
20
18
16
14
%
utilisation 12
disque
10
8
6
4
2
0
dure
Utilisation du disque serveur dans un environnement bureautique
270
240
210
180
Ethernet :
paquets/seconde 150
envoys et
120
reus
90
60
30
0
dure
Paquets/seconde dans un environnement bureautique Ethernet
140000
120000
100000
octets/seconde
transfrs et
reus
80000
60000
40000
20000
0
dure
Octets/seconde dans un environnement bureautique Ethernet
9-50
Etude de cas 2 Environnement de dveloppement de logiciels

Autre exemple de caractristiques dE/S client, nous avons mesur une charge de
compilation/tablissement de liens/excution sur un ESCALA modle 220 16 Mo sans
disque. Il sagit dune charge autrement importante que celle de lexemple prcdent.
Ce travail combine plusieurs services AIX couramment utiliss dans le cadre du
dveloppement de logiciels, dans un environnement utilisateur unique par client. Des
temps de rflexion simuls sont intercals pour tenir compte du dlai de frappe.
Les figures Dveloppement de logiciels : utilisation de la CPU serveur et Dveloppement
de logiciels : utilisation du disque serveur illustrent lutilisation des ressources du serveur
pour cet environnement de travail (avec la mme configuration que dans lexemple
prcdent).
25
20
%
utilisation
CPU
15
10
5
0
dure
Dveloppement de logiciels : utilisation de la CPU serveur
%
utilisation
disque
90
80
70
60
50
40
30
20
10
0
dure
Dveloppement de logiciels : utilisation du disque serveur
9-51
400
360
320
280
240
200
160
120
80
40
0
paquets
transfrs
et reus
dure
Dveloppement de logiciel : paquets/seconde (Ethernet)
octets
transfrs
et reus
360000
320000
280000
240000
200000
160000
120000
80000
40000
0
dure
Dveloppement de logiciel : octets/seconde (Ethernet)
La figure Paquets/seconde dans un environnement de dveloppement de logiciel Ethernet

illustre les variations du taux de requtes dE/S pendant la dure dexcution du travail.
Le taux NFS moyen est de 82 requtes/seconde, avec une pointe 364 requtes/seconde.
La figure Dveloppement de logiciels : octets/seconde (Ethernet) illustre le nombre
doctets transfrs par seconde (activit du protocole comprise). Le taux de transfert moyen
est de 67 540 octets/seconde, avec une pointe 314 750 octets/seconde. Ce travail
consomme en moyenne 1/18me de la largeur de bande nominale dun rseau Ethernet,
avec une pointe 1/4me dutilisation.
La moyenne dutilisation de CPU serveur par client tant de 4.2 %, la moyenne dutilisation
de disque serveur par client de 8.9 % et la moyenne dutilisation du rseau Ethernet de
5.3 %, le disque sera probablement la ressource critique si plusieurs occurrences de ce
travail font appel un seul serveur. Si un second disque a t ajout la configuration du
serveur, cest le rseau Ethernet qui saturera sans doute. Il y a toujours un goulot
dtranglement suivant.
9-52
100
90
80
%
70
dutilisation 60
moyenne
50
du serveur 40
30
20
10
0
disq
ue
CPU
nombre de clients
Utilisation moyenne du serveur
55
requte NFS
temps de
rponse en
millisecondes
45
35
25
15
nombre de clients
Temps de rponse aux requtes NFS
En supposant que le goulot dtranglement disque sest produit avec un nombre rduit de
clients pour cette charge de travail, il est facilement mesurable. La figure Utilisation
moyenne du serveur illustre lutilisation moyenne de CPU et du disque en fonction du
nombre de clients (serveur dun disque). La figure Temps de rponse aux requtes NFS
illustre lvolution du temps de rponse en fonction du nombre de clients.
Voir aussi
Optimisation de NFS
Commandes iostat, nfsstat, rm et smit.
Dmons biod and nfsd.
9-53
Optimisation des connexions asynchrones pour transferts

haut dbit
Les ports asynchrones permettent de raccorder un ordinateur des priphriques en
option, tels que terminaux, imprimantes, tlcopieurs et modems. Ces ports se trouvent sur
des units telles que les cartes BULL 8, 16 ou 64 ports, ou la carte Digiboard 128 ports, qui
rsident sur le Micro Channel et fournissent de nombreuses connexions asynchrones,
gnralement RS-232 ou RS-422. Nombre de cartes, comme les cartes asynchrones BULL
prcites, furent conues lorigine pour servir terminaux et imprimantes, et sont donc
optimises pour les sorties (envois). Le traitement des entres (rception) est moins
optimis, peut-tre parce quil a t dcrt quun utilisateur ne pourrait jamais taper une
vitesse telle quil faille se proccuper de loptimisation des entres clavier. Le problme ne
se pose pas non plus lorsque la transmission des donnes est lente et irrgulire, comme
les entres au clavier. Mais il se pose avec les applications en mode brut, o des blocs
importants dentre sont transmis par dautres ordinateurs ou des machines telles que les
photocopieurs.
Cette section traite des performances respectives des diffrentes cartes lors des transferts
(envoi et rception) de fichiers en mode brut. Nous indiquerons les techniques et les
mthodes permettant dobtenir les meilleures performances lors de ces transferts, en dpit
des limitations inhrentes certaines cartes.
Configurations et objectifs des mesures

Nos mesures ont un double objectif : valuer le dbit en sortie, le dbit effectif en bauds et
le taux dutilisation de CPU diffrents dbits pour les cartes, et dterminer le nombre
maximal de ports susceptibles dtre pris en charge par chaque unit en fonction des
diffrents dbits.
Remarque : Les mesures de dbit sortant, effectues sur des travaux dont les transferts
de fichiers sont excuts en mode brut, sont particulirement utiles pour estimer les
performances dunits fonctionnant en mode brut, tels les tlcopieurs et les modems.
Ces mesures ne sappliquent pas aux configurations multi-utilisateurs commerciales,
dont la CPU peut tre fortement sollicite par les accs aux bases de donnes ou la
gestion de lcran, et qui sont gnralement limites au niveau des E/S disque.
En mode brut, les donnes sont traites comme un flux continu : les octets en entres ne
sont pas regroups en lignes et les fonctions supprimer et tuer sont dsactives. Une
taille minimale de bloc de donnes et une horloge de lecture permettent de dterminer le
traitement appliqu aux octets par le systme, avant transmission lapplication.
Les mesures ont t effectues sur les cartes natives 8, 16 et 64 ports, aux vitesses de
2 400, 9 600, 19 200 et 38 400 bauds. (Les ports asynchrones natifs et les cartes 8 et
16 ports du ESCALA tant tous servis par le mme pilote et leurs performances tant
similaires, ils sont rfrencs sous le mme terme, la carte 8/16 ports.) La carte 128 ports
na t teste qu 19 200 et 38 400 bauds.
La commande AIX de contrle des performances, iostat (ou sar, pour la carte 128 ports), a
t excute en arrire-plan une frquence prdfinie, pour tester les performances du
systme. Des mesures ont t effectues ds quun tat restait stable pendant un intervalle
de temps fixe, dans la portion rectiligne de la courbe de sortie. Pour chaque test, la charge
systme a t progressivement accrue par lajout de ports actifs jusquau maximum admis
ou lutilisation de la CPU 100 %).
Trois mesures significatives au niveau des performances de pointe sortie moyenne
cumule de caractres par seconde (car/sec) sur lintervalle considr, dbit effectif par
ligne et utilisation de la CPU ont t effectues pour la rception et lenvoi semi-duplex.
La rgulation XON/XOFF (tablissement de connexion asynchrone, sans relation avec la
rgulation dE/S disque AIX), la rgulation RTS/CTS et labsence de rgulation ont t
testes. Rgulation et tablissement de connexion font rfrence des mcanismes
9-54
logiciels ou matriels, exploits en communication, pour interrompre les transmissions

lorsque lunit rceptrice ne peut plus stocker les donnes quelle reoit. Nous avons
constat ladquation de la rgulation XON/XOFF avec les cartes 8/16 ports pour la
rception, et avec la carte 128 ports pour lenvoi et la rception. RTS/CTS est plus adapt
la carte 64 ports en rception. Pour lenvoi, labsence de rgulation sest impose pour les
cartes 8/16 et 64 ports.
La sortie de caractres est la somme cumule des caractres transmis par seconde sur
toutes les lignes. Les vitesses des lignes (dbit en bauds) de 2 400, 9 600, 19 200 et
38 400, dfinies par le logiciel, sont optimales pour le transfert des donnes via des lignes
TTY. Alors que le dbit correspond la vitesse de pointe de la ligne, exprime en
bits/seconde, le dbit effectif, toujours moindre, est calcul comme tant gal 10 fois le
dbit de caractre divis par le nombre de lignes. (Le produit par 10 est justifi par le fait
que le tranfert dun caractre de 8 bits utilise 10 bits.)
Rsultats
Le tableau suivant rcapitule les rsultats obtenus. Max ports: est le nombre maximal de
ports pris en charge par la carte, lorsque le dbit effectif est proche de la vitesse de la ligne.
Vitesse ligne 8/16 ports :
64 ports :
128 ports :

Send
Receive Send
Receive Send
Receive
2400 baud
Max ports:
32
16
64
64
N/A
N/A
Char/sec
7700
3800
15200
14720
Eff. Kb/sec: 2.4
2.4
2.3
2.3
CPU util. %: 5
32
9
76
9600 baud
Max ports:
32
12
56
20
128
128
Char/sec
30700
11500
53200
19200
122200
122700
Eff. Kb/sec: 9.6
9.6
9.5
9.6
9,6
9.6
CPU util. %: 17
96
25
99
21
27
19,200 baud
Max ports:
32
6
32
10
128
128
Char/sec
48900
11090
51200
18000
245400
245900
Eff. Kb/sec: 15.3
18.5
16
18
19.2
19.2
CPU util. %: 35
93
23
92
39
39
38400 baud
Max ports:
32
4
24
7
75
75
Char/sec
78400
10550
50400
15750
255200
255600
Eff. Kb/sec: 24.5
26.4
21
22.5
34
34
CPU util. %: 68
98
23
81
40
37
Carte asynchrone 8/16 ports

Envoi semi-duplex 8/16 ports
Les mesures relatives aux envois semi-duplex 8/16 ont t effectues sans rgulation,
permettant la libre transmission des donnes. Pour la carte 8/16 ports, le ESCALA traite
environ 1 400 car/sec pour 1 % dutilisation CPU. La pointe de sortie dune seule carte
16 ports est de 48 000 car/sec.
Rception semi-duplex 8/16 ports

Dans cette configuration, avec rgulation XON/XOFF, le ESCALA traite environ 120 car/sec
pour 1 % dutilisation CPU. La pointe de largeur de bande est de 11 000 car/sec 100 %
dutilisation CPU pour la carte asynchrone 16 ports.
Carte asynchrone 64 ports

Dans les systmes carte asynchrone 64 ports, les limites proviennent le plus souvent du
botier concentrateur 16 ports (il peut y en avoir quatre). La saturation du concentrateur est
un problme car, lorsquelle approche, aucun transit nest plus accept. Le dbit effectif est
9-55
rduit, et on constate une importante baisse dactivit. Pour les mesures qui suivent, quatre
concentrateurs 16 ports ont t connects aux 64 ports RS-232.
Rception semi-duplex 64 ports

Les mesures relatives la rception semi-duplex 64 ports ont t effectues avec
rgulation matrielle RTS/CTS. Dans cette configuration, le ESCALA traite environ
195 car/sec pour 1 % dutilisation CPU. La pointe de largeur de bande est de
19 500 car/sec 100 % dutilisation CPU.
En rception semi-duplex, un botier concentrateur unique 16 ports sature 8 450 car/sec
avec 44 % dutilisation CPU. Une fois le concentrateur satur, aucun transit nest possible
tant quun autre concentrateur nest pas install. A 38 400 bauds, le point de saturation
dun concentrateur unique est atteint avec quatre ports actifs et un dbit effectif de
22,5 kbauds. A 19 200 bauds, le point de saturation est atteint avec cinq ports actifs et un
dbit effectif de 17 kbauds. A 9 600 bauds, le point de saturation est atteint avec neuf ports
actifs et un dbit effectif de 9,6 kbauds. A 2 400 bauds, le systme accepte les 64 ports
avec un dbit effectif de 2,3 kbauds sans point de saturation. La pointe de dbit est de
14 800 car/sec.
Envoi semi-duplex 64 ports

Les mesures relatives aux envois semi-duplex 64 ports ont t effectues sans rgulation,
permettant la libre transmission des donnes, sans restriction au niveau du contrle de flux.
Pour la carte 64 ports, le ESCALA traite environ 1 400 car/sec pour 1 % dutilisation CPU.
La pointe de dbit de la carte 64 ports avec les quatre concentrateurs est de
54 500 car/sec.
Un botier concentrateur unique sature 13 300 car/sec avec 6 % dutilisation CPU.
A 38 400 bauds, il accepte six ports avec un dbit effectif denviron 22 kbauds.
A 19 200 bauds, il accepte huit ports avec un dbit effectif denviron 16,3 kbauds.
Carte asynchrone 128 ports

Sept cartes asynchrones Digiboard 128 ports peuvent tre connectes un ESCALA, pour
un total de 896 ports.
Il existe deux liaisons SDLC (synchronous-data-link-control) par carte, avec une capacit
cumule de 2,4 Mbauds. (La carte 64 ports est dote dun SDLC quatre canaux pour une
capacit cumule de 768 kbauds.)
Dautres caractristiques de la carte 128 ports amliorent la vitesse de transmission des
donnes et rduisent le taux dutilisation CPU :
Lalgorithme dinterrogation prend en charge linterruption dhorloge, vitant toute
interruption hte supplmentaire. Les taux dinterrogation peuvent tre modifis par
lapplication port par port.
Le pilote de lunit dtecte les E/S en mode brut et dplace les donnes de la mmoire
de la carte vers lespace utilisateur, passant outre la procdure de transmission hte.
Le concentrateur traite la plupart des options de discipline de ligne. Le code prpar est
une exception : tous les traitements sont effectus par lhte.
Le microcode de la carte raffecte les tampons mmoire en fonction du nombre de
concentrateurs et de la mmoire disponible.
Le concentrateur ne sature pas avec les cartes asynchrones 128 ports, donnant cette
carte un avantage certain sur les cartes asynchrones 64 ports.
Pour les mesures, huit botiers concentrateurs 16 ports ont t connects aux 128 ports
RS-232.
Rception semi-duplex 128 ports

Avec la rgulation logicielle XON/XOFF, cette configuration traite environ 6 908 car/sec pour
1% dutilisation CPU. La pointe de dbit est de 255 600 car/sec 37 % dutilisation CPU.
9-56
Envoi semi-duplex 128 ports

Sans rgulation, le taux maximal auquel cette configuration peut envoyer des donnes
une unit TTY est denviron 5 800 car/sec pour 1 % dutilisation CPU. La pointe de sortie de
la carte 128 ports est 255 200 car/sec.
Techniques doptimisation du port asynchrone

Les configurations test de cette tude font appel nombre de mcanismes logiques et
physiques de contrle de flux, ainsi qu des techniques logicielles pour optimiser les taux
de transmission de caractres. Vous trouverez ci-dessous quelques prcisions sur ces
techniques. (Un script shell contenant les commandes stty permettant dimplanter
lessentiel de ces techniques est fourni en fin de section.)
Augmentez la valeur (4, par dfaut) de la variable vmin pour chaque TTY. vmin est le
nombre minimal doctets recevoir lorsque la lecture aboutit. La valeur de vmin doit tre
la plus petite de la taille de bloc des donnes ou 255 (maximum autoris). Si la taille de
bloc de lapplication est variable ou inconnue, dfinissez vmin 255 : le nombre de
lectures sera rduit de mme que le taux dutilisation de CPU (de 15 20 % pour les
programmes de transfert de fichiers).
Sauf sur la carte 128 ports, dfinissez vtime > 0 pour prvenir une lecture de bloc
indfinie. Si vtime est dfini zro sur la carte 128 ports, le traitement de la procdure de
transmission POSIX sera dcharg sur le matriel de la carte, rduisant sensiblement le
traitement CPU.
Pour les envois en mode brut o aucune translation en sortie nest ncessaire,
dsactivez loption opost sur ligne de procdure POSIX. Les performances CPU seront
amliores par la rduction de la longueur du chemin de sortie. Pour les applications de
transfert de fichiers, qui dplacent dimportantes quantits de donnes sur les lignes TTY,
le taux dutilisation de CPU peut tre divis par 3. Exemple :
# stty opost < /dev/ttyn
La carte 64 ports tant sujet des surcharges de donnes imprvisibles lorsque le dbit
est lev et que la rgulation est effectue via XON/XOFF, optez pour la rgulation
matrielle RTS/CTS. Vous vitez ainsi les risques de perte de donnes.
Dans la mesure o les botiers concentrateurs de la carte 64 ports ont une largeur de
bande limite et saturent lorsque les dbits sont levs, ajouter des ports un
concentrateur satur ne fera que dgrader les performances de tous les ports connects.
Ajoutez plutt un autre concentrateur et poursuivez jusqu ce que lui aussi sature ou
que la CPU soit surcharge.
Pour le traitement des entres, loption echo est coteuse, dans la mesure o elle accrot
la dure de traitement par caractre. Lcho de caractre est utile pour les entres
utilisateur canoniques, mais le plus souvent inutile pour la plupart des applications en
mode brut. Exemple :
# stty echo < /dev/ttyn
9-57
Transfert rapide de fichiers avec fastport

Le script fastport.s a pour objet de configurer un port TTY pour le transfert rapide des
fichiers en mode brut (lorsquun tlcopieur doit tre raccord, par exemple). Utiliser ce
script peut multiplier par 3 les performances CPU ( un dbit de 38 400 bauds).
fastport.s nest pas destin au traitement canonique utilis lors de linteraction avec un
utilisateur sur terminal asynchrone, car un traitement canonique ne peut pas tre aisment
plac en mmoire tampon. La largeur de bande dune lecture canonique est trop faible pour
les paramtres du port rapide pour quune diffrence soit perceptible.
Nimporte quel port TTY peut tre configur comme port rapide. Lamlioration des
performances qui en rsulte est due la diminution du nombre dinterruptions vers la CPU
au cours du cycle de lecture sur une ligne TTY donne.
1. Crez un TTY pour le port via SMIT (Units > TTY > Ajout dun TTY), avec
Activation de la connexion=disable et Vitesse de transmission=38 400.
2. Crez le script shell Korn fastport.s, comme suit :
#****************************************************************
#
#
Configures a fastport for raw async I/O.
#
#****************************************************************
set x
sync;sync
i=$1
if [ $i le 100 ]
then
# for the native async ports and the 8, 16, and 64port adapters
# set vmin=255 and vtime=0.5 secs with the following stty
stty g </dev/tty$i |awk BEGIN { FS=:;OFS=: }
{ $5=ff;$6=5;print $0 } >foo
# for a 128port adapter, remove the preceding stty, then
# uncomment and use the
# following stty instead to
# set vmin=255 and vtime=0 to offload line discipline processing
# stty g </dev/tty$i |awk BEGIN { FS=:;OFS=: }
# { $5=ff;$6=0;print $0 } >foo
stty cat foo </dev/tty$i
sleep 2
# set raw mode with minimal input and output processing
stty opost icanon isig icrnl echo onlcr</dev/tty$i
rm foo
sync;sync
else
echo Usage is fastport.s < TTY number >
fi
3. Appelez le script pour le numro TTY avec la commande :

fastport.s number
9-58
Evaluation des performances rseau avec netpmon

La commande netpmon fait appel la fonction de suivi pour obtenir une image dtaille de
lactivit du rseau pendant un intervalle de temps dtermin. Dans la mesure o la
commande filemon invoque cet utilitaire, seul lutilisateur root ou un membre du groupe
system est habilit la lancer. La commande netpmon nest pas prvue pour fonctionner
avec NFS3(ONC+).
Sous AIX version 4.1, la commande netpmon est intgre la bote outils PTX
(Performance Toolbox for AIX). Pour dterminer si netpmon est disponible, entrez :
Si ce module est install, netpmon est disponible.
Le suivi, lanc par la commande netpmon, peut tre suspendu par trcoff, relanc par
trcon et arrt par trcstop. Ds que le suivi est termin, netpmon en envoie le compte
rendu stdout. Voici un exemple dutilisation de netpmon :
# netpmon o nm.test.out ; ping xactive 256 5 ; trcstop
Le compte rendu gnr (quelque peu rsum) par cette squence, dans un systme au
repos, est le suivant :
Wed Jan 12 14:33:25 1994
System: AIX alborz Node: 3 Machine: 000249573100
4.155 secs in measured interval
========================================================================
Process CPU Usage Statistics:
Network
Process (top 20)
PID CPU Time
CPU %
CPU %
ping
12699
0.0573
1.380
0.033
trcstop
12700
0.0150
0.360
0.000
ksh
13457
0.0150
0.360
0.000
rlogind
6321
0.0127
0.306
0.088
netpmon
12690
0.0064
0.153
0.000
netw
771
0.0047
0.113
0.113
netpmon
10650
0.0037
0.090
0.000
trace
10643
0.0023
0.055
0.000
swapper
0
0.0022
0.053
0.000
writesrv
1632
0.0009
0.021
0.000
Total (all processes)

0.1201
2.891
0.234
Idle time
3.8904 93.639
========================================================================
First Level Interrupt Handler CPU Usage Statistics:
Network
FLIH
CPU Time
CPU %
CPU %
external device
0.0573
1.379
0.890
data page fault
0.0368
0.887
0.000
floating point
0.0001
0.003
0.000
Total (all FLIHs)

0.0943
2.269
0.890
========================================================================
Second Level Interrupt Handler CPU Usage Statistics:
Network
SLIH
CPU Time
CPU %
CPU %
clock
0.0415
0.998
0.000
tokdd
0.0064
0.154
0.154
<addr=0x00022140>
0.0008
0.019
0.000
Total (all SLIHs)

0.0486
1.171
0.154
9-59
========================================================================
Network DeviceDriver Statistics (by Device):
Xmit
Recv
Device
Pkts/s Bytes/s Util QLen
Pkts/s Bytes/s
/dev/tok0
3.37
629 0.005 0.005
16.85
1900
========================================================================
Network DeviceDriver Transmit Statistics (by Destination Host):
Host
Pkts/s Bytes/s
xactive.austin.ibm.com
1.44
390
========================================================================
Detailed Second Level Interrupt Handler CPU Usage Statistics:
SLIH: tokdd
count:
84
cpu time (msec):
avg 0.076
min 0.058
max 0.097
sdev 0.009
========================================================================
Detailed Network DeviceDriver Statistics:
DEVICE: /dev/tok0
recv packets:
70
recv sizes (bytes):
avg
112,8 min
68 max
324 sdev
75,2
recv times (msec):
avg
0,226 min
0,158 max
0,449 sdev
0,056
xmit packets:
14
xmit sizes (bytes):
avg
186,6 min
52 max
314 sdev
100,0
xmit times (msec):
avg
1,552 min
1,127 max
2,532 sdev
0,380
========================================================================
Detailed Network DeviceDriver Transmit Statistics (by Host):
HOST: xactive.austin.ibm.com
xmit packets:
6
xmit sizes (bytes):
avg
270,3 min
52 max
314 sdev
97,6
xmit times (msec):
avg
1,772 min
1,516 max
2,532 sdev
0,346
9-60
Analyse des problmes de performance avec iptrace

Il existe de nombreux outils de suivi de lactivit, normale ou anormale, sur le rseau.
Certains sont oprationnels sous AIX, dautres requirent un matriel spcifique. Un des
outils permettant dobtenir une description prcise, paquet par paquet, de lactivit du LAN
gnre par une charge de travail, est la combinaison du dmon iptrace et de la
commande ipreport. Seul lutilisateur root est habilit lancer le dmon iptrace.
Par dfaut, iptrace assure le suivi de tous les paquets. Une option (a) permet dexclure les
paquets du protocole ARP (Address Resolution Protocol). Dautres options permettent de
resteindre lobjet du suivi un hte source (s), un hte destinataire (d) ou un protocole
(p) donn. Reportez-vous au manuel AIX Commands Reference. La consommation
iptrace de temps processeur tant non ngligeable, ciblez bien les paquets dont vous
souhaitez le suivi.
iptrace tant un dmon, mieux vaut le lancer via une commande startsrc et non partir de
la ligne de commande : il sera plus facile de le contrler et de larrter proprement.
Voici un exemple dappel classique :
# startsrc s iptrace a i tr0 /home/user/iptrace/log1
Cette commande lance le dmon iptrace avec mission dassurer le suivi de toutes les
activits sur linterface en anneau jeton, tr0, et de placer les donnes de suivi dans
/home/user/iptrace/log1. Pour arrter le dmon, entrez :
# stopsrc s iptrace
Si vous ne laviez pas lanc avec startsrc, vous auriez d rechercher son ID processus via
ps et le tuer (kill).
La commande ipreport est une commande de formatage pour le fichier journal. Sa sortie
est crite sur stdout. Des options permettent de reconnatre et de formater les paquets
RPC (r), didentifier chaque paquet par un numro (n) et de prfixer chaque ligne par une
chane de 3 caractres identifiant le protocole (s). Voici une commande ipreport formatant
le fichier log1 juste cr (appartenant lutilisateur root) :
# ipreport ns log1 >log1-format
Il en rsulte une squence de comptes rendus de paquet semblable aux exemples ci-aprs.
Le premier paquet est la premire moiti dun ping. Les champs les plus intressants sont :
les adresses des htes source (SRC) et destination (DST) (en dcimal avec point
sparateur et en ASCII), la longueur du paquet IP (ip_len), et lindication du protocole de
plus haut niveau en cours (ip_p).
Packet Number 131
TOK: =====( packet transmitted on interface tr0 )=====Fri Dec 10 08:42:07 1993
TOK : 802.5 packet
TOK: 802.5 MAC header:
TOK: access control field = 0, frame control field = 40
TOK: [ src = 90:00:5a:a8:88:81, dst = 10:00:5a:4f:35:82]
TOK: routing control field = 0830, 3 routing segments
TOK: routing segments [ ef31 ce61 ba30 ]
TOK: 802.2 LLC header:
TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP:
< SRC = 129.35.145.140 > (alborz.austin.ibm.com)
IP:
< DST = 129.35.145.135 > (xactive.austin.ibm.com)
IP:
ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=38892, ip_off=0
IP:
ip_ttl=255, ip_sum=fe61, ip_p = 1 (ICMP)
ICMP:
icmp_type=8 (ECHO_REQUEST) icmp_id=5923 icmp_seq=0
ICMP: 00000000
2d088abf 00054599 08090a0b 0c0d0e0f
|.....E.........|
ICMP: 00000010
10111213 14151617 18191a1b 1c1d1e1f
|................|
ICMP: 00000020
20212223 24252627 28292a2b 2c2d2e2f
| !#$%&()*+,./|
ICMP: 00000030
30313233 34353637
|01234567
|
9-61
Lexemple suivant est une trame rsultant dune opration ftp. Notez que le paquet IP est la
taille du MTU pour ce rseau (1 492 octets).
Packet Number 501
TOK: =====( packet received on interface tr0 )=====Fri Dec 10 08:42:51 1993
TOK: 802.5 packet
TOK: 802.5 MAC header:
TOK: access control field = 18, frame control field = 40
TOK: [ src = 90:00:5a:4f:35:82, dst = 10:00:5a:a8:88:81]
TOK: routing control field = 08b0, 3 routing segments
TOK: routing segments [ ef31 ce61 ba30 ]
TOK: 802.2 LLC header:
TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP:
< SRC = 129.35.145.135 > (xactive.austin.ibm.com)
IP:
< DST = 129.35.145.140 > (alborz.austin.ibm.com)
IP:
ip_v=4, ip_hl=20, ip_tos=0, ip_len=1492, ip_id=34233, ip_off=0
IP:
ip_ttl=60, ip_sum=5ac, ip_p = 6 (TCP)
TCP:
<source port=20(ftpdata), destination port=1032 >
TCP:
th_seq=445e4e02, th_ack=ed8aae02
TCP:
th_off=5, flags<ACK |>
TCP:
th_win=15972, th_sum=0, th_urp=0
TCP: 00000000
01df0007 2cd6c07c 00004635 000002c2
|....,..|..F5....|
TCP: 00000010
00481002 010b0001 000021b4 00000d60
|.H........!....|
Lots of uninteresting data omitted
TCP: 00000590
63e40000 3860000f 4800177d 80410014
|c...8..H..}.A..|
TCP: 000005a0
82220008 30610038 30910020
|...0a.80..
|
9-62
Chapitre 10. Optimisation des performances DFS
Remarque : Les recommandations qui suivent sappuient sur des essais effectus sous
AIX version 4.1. Au moment o nous crivons, nous ne savons pas dans quelle mesure
elles sappliquent galement AIX version 4.1.
Du point de vue des performances, la diffrence essentielle entre DCE DFS et NFS est la
capacit du client de mise en cache de DFS. Il nest donc pas tonnant que les principales
techniques doptimisation de DFS concernent les attributs du cache client. Les paramtres
client et serveur dcrits dans ce chapitre concernent :
Cache DFS sur disque ou en mmoire
Taille du cache DFS
Taille de la tranche de cache DFS
Nombre de tranches de cache DFS
Emplacement du cache disque DFS
Taille du tampon dtat du cache DFS
Taille des articles et lectures/critures
Paramtres de communication DFS
Optimisation du serveur de fichiers DFS
Optimisation LFS DCE pour les performances DFS.
Cache DFS sur disque ou en mmoire

Pour dterminer si, dans votre environnement, mieux vaut accder au disque ou la
mmoire, considrez ce qui suit :
Si le systme en cours doptimisation, ou un autre systme prsentant une charge de
travail similaire, exploite dj DFS avec un cache disque, vous pouvez estimer la taille de
cache mmoire requise, en lanant, lissue dune priode de pointe, la commande :
cm getcachesize
Divisez le nombre de blocs de 1 ko utiliss par 0,9 pour dterminer la taille de cache
mmoire requise pour la mme quantit de donnes. (Environ 10 % des blocs du cache
servent conserver les articles DFS.)
Si laccs ces donnes est frquent, optez pour un potentiel suprieur de cache disque.
Si la quantit de donnes gres est telle que le cache disque le plus grand risque dtre
submerg, ou que les donnes sont frquemment modifies par un autre client, optez de
prfrence pour un cache mmoire, plus efficace au niveau des performances RFC.
La taille dun cache mmoire ne doit pas excder 10 % de la taille de la mmoire relle
de la machine. La taille recommande est denviron 5 % de la mmoire relle. DFS
exploitant la capacit de mise en cache mmoire du VMM AIX, lessentiel du cache
mmoire DFS est occup par les informations sur les rpertoires et les points de
montage.
Si vous constatez un signe de limitation en mmoire du systme (valeur non nulle la
colonne pi ou po dun relev vmstat), nutilisez pas de cache mmoire pour DFS.
Optimisation des performances DFS
10-1
A titre de test de faisabilit, vous pouvez rduire temporairement, via rmss, la taille
effective de la mmoire en dduisant la quantit de mmoire que vous affecterez au
cache. Si vous constatez une activit de pagination ou une baisse de performances, ou
les deux, abandonnez lide de crer un cache mmoire. Reportez-vous Estimation de
la mmoire requise via rmss, page 7-6.
Taille du cache DFS

La dtermination de la taille adquate du cache DFS pour un systme donn se fait un peu
par ttonnement. Vous pouvez commencer par estimer la somme :
des tailles de lensemble des fichiers de donnes DFS rsidants lus au moins une fois
par jour,
des quantits de donnes DFS rsidantes gnres quotidiennement par les utilisateurs,
des tailles des programmes DFS rsidants excuts plus dune fois par jour.
Si les rpertoires personnels des utilisateurs se trouvent dans DFS, vous pouvez dfinir des
autorisations concernant la frquence daccs ces rpertoires, et tudier la raction du
systme.
La taille du cache client, spcifie dans le fichier CacheInfo, peut tre remplace via
loption dfsd blocks n, n tant le nombre de ko du cache. Ce paramtre sapplique aux
caches mmoire comme aux caches disque.
Taille de la tranche de mmoire cache DFS

La taille de tranche du cache DFS varie entre 8 et 256 ko. Pour les fichiers volumineux
(plusieurs Mo), les performances des lectures/critures squentielles augmentent avec
cette taille (jusqu environ 64 ko). Pour les fichiers encore plus importants (plus de
100 Mo), une tranche de 256 ko entrane la meilleure performance en lecture.
La taille de tranche est spcifie via loption dfsd chunksize n, n tant un entier compris
entre 13 et 18 (inclus). La taille du cache est de 2**n octets, et est dons comprise entre
8 (2**13) et 256 ko (2**18). Ce paramtre sapplique aux caches mmoire comme aux
caches disque. Taille par dfaut : ko (caches mmoire) et 64 ko (caches disque).
Nombre de tranches de cache DFS

Ce paramtre ne sapplique quaux caches disque. Pour les caches mmoire, le nombre de
tranches est dj spcifi par la combinaison de la taille de cache et de la taille de tranche.
Pour les caches disque, le nombre de tranches par dfaut est dfini comme tant le nombre
de blocs cache divis par 8. Si un du du rpertoire cache indique que lespace nest rempli
qu moins de 90 %, augmentez le nombre de tranches de cache via loption dfsd files n,
n tant le nombre de tranches adapter. Ce qui permet une meilleure utilisation de lespace
cache disponible pour les applications qui font appel de nombreux petits fichiers.
Plusieurs fichiers ne pouvant partager une tranche, le nombre de tranches dtermine le
nombre de fichiers susceptibles dtre pris en charge par le cache.
Emplacement du cache disque DFS

Le cache disque doit se trouver dans un volume logique qui :
se trouve dans la zone outer_edge, sil se trouve sur une unit de disque de 200 Mo,
540 Mo ou 1 Go,
se trouve dans la zone center, sur une unit de disque autre que celles prcites,
se trouve ailleurs que dans le groupe de volume rootvg,
10-2
se trouve sur un autre volume physique que lespace de pagination,

soit principalement ou exclusivement occup par le cache disque,
soit suffisamment vaste pour contenir le cache disque spcifi sans empiter sur le reste.
Taille du tampon dtat du cache DFS

La taille du tampon dtat limite le nombre maximal de fichiers susceptibles de se trouver
simultanment dans le cache. Une entre est requise pour chaque fichier. Si le tampon
dtat est satur, les nouveaux fichiers dplaceront les anciens dans le cache, mme si
lespace disque est suffisant. Si votre charge de travail concerne essentiellement des
fichiers dont la taille est infrieure ou gale celle de la tranche, le tampon dtat doit avoir
autant dentres quil y a de tranches dans le cache.
La taille du tampon dtat est spcifie via loption dfsd stat n, n tant le nombre dentres
du tampon dtat. Valeur par dfaut de n :
Taille des articles et lectures/critures

Les performances relatives aux lectures/critures squentielles sont affectes par la taille
des articles lus ou crits par lapplication. En gnral, le dbit des lectures crot avec des
articles dont la taille augmente jusqu 4 ko, puis dcrot au-del. Le dbit des critures
crot avec des articles dont la taille augmente jusqu 2 ko, puis se stabilise ou dcrot
lgrement au-del.
Paramtres de communication DFS

DFS se sert du protocole de communication UDP. Les recommandations pour optimiser les
communication DFS pour les systmes client multiutilisateur et les serveurs sont celles
indiques pour loptimisation des communications en gnral (voir Rcapitulatif des
paramtres doptimisation UDP, TCP/IP et mbuf, page 9-31) :
Donnez la taille des files dattente de rception et denvoi de la carte rseau la
valeur 150 (le maximum). Pour ce faire, faites appel smit commodev > (type carte)
> Adapter > Change / Show Characteristics of a (type carte) Adapter. Ces paramtres
ne peuvent tre modifis en cours dutilisation de la carte. SMIT permet de prciser que
la modification ne doit prendre effet qu lamorage suivant du systme.
Vous pouvez galement dfinir ces paramtres via chdev, si vous commencez par
dsactiver la carte. Par exemple, pour une carte en anneau jeton, la squence de
commande est :
# ifconfig tr0 detach
# chdev l tok0 a xmt_que_size=150 a rec_que_size=150
# ifconfig tr0 hostname up
Vous pouvez observer leffet de la modification via :
$ lsattr E l tok0
Si la commande netstat s gnre un nombre non nul dans udp : n socket buffer
overflows, augmenter la valeur des paramtres sb_max et udp_recvspace via la
commande no ne rsoud le problme que si une application autre que DFS subit un
dpassement. DFS dfinit ses propres valeurs (176 ko) pour sb_max et
udp_recvspace. Ces valeurs ne sont ni affiches ni modifies par la commande no.
Optimisation des performances DFS
10-3
Optimisation du serveur de fichiers DFS

Sur les serveurs haute vitesse, il peut tre souhaitable daugmenter le nombre de
mainprocs et de tokenprocs (dans la commande fxd), pour garantir lexploitation de
toute la capacit CPU disponible.
Commencez par spcifier mainprocs 10 tokenprocs 4.
Excutez vmstat en priode de pointe. Si vous constatez un niveau trs lev dE/S
CPU en attente, tentez daugmenter encore les valeurs de mainprocs et de
tokenprocs.
Optimisation LFS DCE pour les performances DFS

Lorsque vous configurez un agrgat LFS DCE (via la commande newaggr) sur un serveur
DFS, tenez compte de ce qui suit :
Si la plupart des fichiers sont volumineux, donnez au paramtre blocksize la valeur
maximale autorise qui soit infrieure la taille standard de fichier. La valeur de
blocksize peut tre une puissance de 2 quelconque comprise entre 4 et 64 ko.
Si la plupart des fichiers sont plusieurs fois plus grands que le paramtre blocksize,
donnez au paramtre fragsize la mme valeur que celle de blocksize. Vous utiliserez
sans doute plus despace disque, mais fluidifierez le traitement.
Si lagrgat est infrieur 100 Mo, utilisez le paramtre logsize pour vrifier que le
journal est plus grand que la valeur par dfaut (1 % de la taille de lagrgat). En gnral,
logsize ne doit jamais tre infrieur 1 000 blocs.
10-4
Chapitre 11. Analyse des performances avec lutilitaire

de suivi
Lutilitaire de suivi AIX est un puissant outil dobservation du systme. Il capture un flux
squentiel dvnements horodats, fournissant un niveau de dtail extrmement fin sur
lactivit du systme. Les vnements sont restitus dans lordre chronologique et dans leur
contexte. Lutilitaire est ainsi un outil privilgi dobservation du systme et de lexcution
des applications. Dautres outils sont axs sur les statistiques (taux dutilisation du CPU,
dlai dattente des E/S, etc.), lutilitaire de suivi est lui plus spcifiquement ddi lanalyse
du pourquoi et du comment.
Le systme dexploitation est conu pour offrir une visibilit gnrale des excutions sur le
systme. Les utilisateurs peuvent tendre la visibilit dans leurs applications en insrant
des vnements complmentaires et en fournissant des rgles de formatage.
Lors de la conception et de limplantation de cet outil, il a t pris grand soin de veiller
lefficacit de la collecte des donnes, de faon perturber au minimum lactivit systme.
De ce fait, lutilitaire est aussi adapt lanalyse des performances qu lidentification des
incidents.
Plus en savoir plus, reportez-vous aux rubriques :
Prsentation de lutilitaire de suivi
Exemple dutilisation de lutilitaire de suivi
Lancement et contrle du suivi depuis la ligne de commande
Lancement et contrle du suivi depuis un programme
Ajout dvnements de suivi
Syntaxe des strophes du fichier de format du suivi
Analyse des performances avec lutilitaire de suivi
11-1
Prsentation de lutilitaire de suivi

Lutilitaire de suivi est plus souple que les services classiques de surveillance du systme,
qui prsentent les statistiques tenues jour par le systme. Dans ces services en effet, la
rduction des donnes (conversion dvnements systme en statistiques) est largement
associe linstrumentation du systme. Ainsi, nombre de systmes tiennent jour le dlai
minimal, maximal et moyen, dexcution de la tche A et autorisent lextraction de cette
information.
Lutilitaire de suivi AIX nassocie pas fermement rduction des donnes et instrumentation,
mais fournit un flot darticles vnements de suivi (appels plus simplement vnements).
Il est inutile de dcider lavance des statistiques requises. La rduction des donnes est
dans une large mesure indpendante de linstrumentation. Lutilisateur peut dcider de
dterminer les dlais dexcution minimal, maximal et moyen de la tche A partir du flot
dvnements. Mais il est galement possible dextraire le dlai moyen dexcution de la
tche A lorsquelle est appele par le processus B ; ou encore le dlai dexcution de la
tche A lorsque les conditions XYZ sont remplies ; ou de calculer la dviation standard
lexcution de la tche A ; ou mme de dcider quune autre tche, reconnue par un flot
dvnements, est plus significative. Cette souplesse est sans prix lorsquil sagit de
diagnostiquer des problmes de performance ou de fonctionnement.
Outre les informations dtailles quil fournit sur lactivit du systme, lutilitaire de suivi
permet dinstrumenter les programmes dapplication et de collecter leurs vnements de
suivi linstar des vnements du systme. Le fichier de suivi contient un enregistrement
complet des activits du systme et des applications, horodates et prsentes
chronologiquement.
Limitation de la quantit de donnes collectes

Lutilitaire de suivi gnre dimportantes quantits de donnes. Il est donc impossible de les
capturer sur de longues priodes, sous peine de submerger lunit de stockage.
Pour utiliser efficacement lutilitaire, vous avez le choix :
Lutilitaire de suivi peut tre activ/dsactiv de plusieurs faons pour capturer des bribes
de lactivit systme. Il est pratique de capturer ainsi des secondes ou des minutes
dactivit en vue dun post-traitement. Une dure de cet ordre est suffisante pour
caractriser les transactions principales au niveau des applications ou les passages
intressants dune longue tche.
Lutilitaire de suivi peut tre configur pour acheminer le flot dvnements vers la sortie
standard. Ce qui permet un processus en temps rel de se connecter au flux
dvnements et deffectuer la rduction des donnes au fur et mesure de la
consignation des vnements, crant ainsi une possibilit de surveillance long terme.
Une extension logique pour linstrumentation spcialise est de diriger le flot de donnes
vers une unit auxiliaire susceptible soit de stocker dimportantes quantits de donnes,
soit dassurer la rduction dynamique des donnes. Cette technique est utilise par les
outils de performance tprof, netpmon et filemon.
Lancement et contrle du suivi

Vous pouvez exploiter lutilitaire de suivi selon trois modes :
Mode sous-commande. Le suivi est lanc par une commande shell (trace) et prolong
par un dialogue avec lutilisateur via des sous-commandes. Le travail objet du suivi doit
tre fourni par dautres processus, car le processus shell dorigine est en cours
dutilisation.
Mode commande. Le suivi est lanc par une commande shell (trace a) qui comporte un
indicateur spcifiant que lutilitaire doit tre excut en mode asynchrone. Le processus
shell dorigine est disponible pour excuter des commandes standard, entrecoupes de
commandes de contrle de suivi.
11-2
Mode contrl par application. Le suivi est lanc (avec trcstart()) et contrl par des
appels de sous-routines (telles que trcon(), trcoff()), partir dun programme
dapplication.
Formatage des donnes de suivi

Un utilitaire passe-partout de compte rendu de suivi est fourni par la commande trcrpt.
Cet utilitaire offre peu de rduction de donnes, mais convertit le flot brut dvnements
binaires en listing ASCII lisible. Les donnes peuvent tre visuellement extraites par un
lecteur, mais vous pouvez galement dvelopper des outils pour une meilleure rduction
des donnes.
Lutilitaire affiche texte et donnes pour chaque vnement en fonction des rgles
spcifies dans le fichier de format du suivi. Le fichier de format du suivi par dfaut est
/etc/trcfmt. Ce fichier contient une strophe par ID vnement, qui indique lutilitaire de
compte rendu les rgles de formatage pour cet vnement. Cette technique permet aux
utilisateurs dajouter leurs propres vnements aux programmes et dinsrer les strophes
correspondantes dans le fichier de format pour prciser le format souhait pour ces
nouveaux vnements.
Consultation des donnes de suivi

Lors du formatage des donnes de suivi, toutes les donnes relatives un vnement sont
gnralement places sur une seule ligne. Des complments dinformation se trouvent
ventuellement sur dautres lignes. Selon les champs inclus, les lignes formates peuvent
facilement dpasser 80 caractres : mieux vaut prvoir une unit de sortie 132 colonnes.
11-3
Exemple dutilisation de lutilitaire de suivi

Obtention dun fichier de suivi chantillon
Les donnes de suivi saccumulent rapidement. Nous souhaitons restreindre la collecte aux
donnes qui prsentent un rel intrt. Une technique possible consiste mettre plusieurs
commandes sur la mme ligne de commande. Par exemple :
$ trace a k 20e,20f o ./trc_raw ; cp ../bin/track /tmp/junk ; trcstop
capture lexcution de la commande cp. Nous avons utilis deux caractristiques de la

commande de suivi. Loption k 20e,20f limine la collecte des vnements issus des
fonctions lockl et unlockl. Ces appels sont nombreux et augmentent la taille du compte
rendu sans apporter dinformations au niveau qui nous intresse. Loption o ./trc_raw
entrane lcriture du fichier brut de sortie du suivi dans notre rpertoire local.
Remarque : Cet exemple est plus parlant si le fichier dentre ne se trouve pas dj
dans la mmoire cache du systme. Choisissez comme fichier source un fichier
denviron 50 ko qui na fait lobjet daucun accs rcent.
Formatage de lchantillon de suivi

Pour notre compte rendu, nous avons utilis la commande trcrpt sous la forme :
$ trcrpt O exec=on,pid=on trc_raw > cp.rpt
Cette commande gnre la fois le nom complet qualifi du fichier excut (via exec) et
lID processus qui lui est affect.
Un coup dil sur le compte rendu indique la prsence de nombreuses affectations de
pages VMM et de suppressions dvnements dans le suivi, telle la squence :
1B1 ksh
8525
00.150E ppage=1F7F
0.003109888
0.162816
VMM page delete:
V.S=00
delete_in_progress
process_private working_storage
1B0 ksh
8525
00.2F33 ppage=1F7F
0.003141376
0.031488
VMM page assign:
V.S=00
delete_in_progress
process_private working_storage
Lactivit VMM ne nous intressant pas ce niveau, nous avons reformat le suivi via :
$ trcrpt k 1b0,1b1 O exec=on,pid=on trc_raw > cp.rpt2
Loption k 1b0,1b1 supprime les vnements VMM superflus de la sortie formate.
Elle vite de relancer le suivi du travail pour liminer les vnements non souhaits. Nous
aurions pu faire appel la fonction k de trcrpt au lieu de celle de la commande trace pour
liminer les vnements lockl et unlockl, si nous avions eu besoin de consulter lactivit de
verrouillage un moment donn. Si notre intrt ne portait que sur un petit nombre
dvnements, nous aurions spcifi d id-ancre1,id-ancre2 pour gnrer un compte
rendu ne portant que sur ces vnements. LID ancre tant la premire colonne du compte
rendu, il est trs rapide de compiler une liste dancres inclure ou exclure.
Une liste complte des ID dancre de suivi se trouve dans /usr/include/sys/trchkid.h.
11-4
Interprtation dun compte rendu de suivi

Len-tte du compte rendu de suivi indique la date et le lieu o a t effectu le suivi, ainsi
que la commande utilise pour le gnrer :
Fri Nov 19 12:12:49 1993
System: AIX ptool Node: 3
Machine: 000168281000
Internet Address: 00000000 0.0.0.0
trace ak 20e 20f o o ./trc_raw
Le corps du compte rendu, si affich en caractres suffisamment petits, est semblable :
ID PROCESS NAME
PID
ELAPSED_SEC
101 ksh
101 ksh
134 cp
8525
7214
7214
0.005833472
0.012820224
0.014451456
DELTA_MSEC
APPL SYSCALL KERNEL INTERRUPT
0.107008
0.031744
0.030464
kfork
execve
execcp../bin/trk/junk
Dans cp.rpt, vous pouvez observer :

Les activits fork, exec et dfaut de page du processus cp.
Louverture du fichier dentre pour la lecture et la cration du fichier /tmp/junk.
Les appels systme read/write successifs pour effectuer la copie.
Le blocage du processus cp dans lattente de la fin des E/S et de la distribution du
processus wait.
Les translations des requtes de volume logique en requtes de volume physique.
Le mappage des fichiers (et non leur stockage dans les tampons classiques du noyau) et
les accs en lecture provoquant des dfauts de page qui doivent tre rsolus par VMM
(Virtual Memory Manager).
La dtection des accs squentiels par le gestionnaire de mmoire virtuelle (VMM),
lequel dclenche un accs anticip aux pages de fichier.
La taille des donnes lues par anticipation qui augmente avec la poursuite de laccs
squentiel.
Lorsque possible, la fusion par le pilote dunit de disque des requtes de fichier
multiples en une seule requte dE/S destination du pilote.
La sortie du suivi semble au dpart quelque peu surcharge. Cest un bon exercice
dapprentissage : si vous parvenez discerner les activits dcrites, vous tes sur la bonne
voie, et vous pourrez bientt suffisamment matriser lutilitaire de suivi et lexploiter pour
diagnostiquer les problmes de performance du systme.
Filtrage du compte rendu de suivi

Lintgralit des donnes de suivi nest pas forcment utile. Vous pouvez dcider des
vnements quil vous semble intressant de suivre. Il est parfois utile, par exemple, de
dterminer le nombre doccurrences dun vnement donn. Pour rpondre la question
Combien de open se sont produits dans lexemple de copie ?, recherchez dabord lID
vnement de lappel systme open. Procdez comme suit :
$ trcrpt j | grep i open
Vous constatez que lID 15b correspond lvnement open. Traitez maintenant les
donnes de lexemple :
$ trcrpt d 15b O exec=on trc_raw
Le compte rendu est inscrit sur la sortie standard et vous pouvez dterminer le nombre de
sous-routines open excutes. Si vous souhaitez vous limiter aux sous-routines open
excutes par le processus cp, relancez la commande comme suit :
$ trcrpt d 15b p cp O exec=on trc_raw
11-5
Lancement et contrle du suivi depuis la ligne de commande

Lutilitaire de suivi est configur et la collecte des donnes est ventuellement lance par la
commande trace, dont la syntaxe est dcrite dans le manuel AIX Commands Reference.
Une fois le suivi configur par la commande trace, des contrles permettent dactiver et de
dsactiver la collecte des donnes, et darrter le suivi (larrt dconfigure le suivi et libre
les tampons). Ces contrles sont appels par : des sous-commandes, des commandes, des
sous-routines ou des appels ioctl. La sous-routine et les interfaces ioctl sont dcrites
Lancement et contrle du suivi depuis un programme, page 11-7.
Contrle du suivi en mode sous-commande

Si la routine de suivi est configure sans option a, elle est excute en mode
sous-commande. Une invite > remplace linvite habituelle. Dans ce mode, sont reconnues
les sous-commandes :
trcon
Lance ou relance la collecte des donnes dvnements.
trcoff
Suspend la collecte des donnes dvnements.
q ou quit
Arrte la collecte des donnes dvnements et met fin la routine de

suivi.
!commande
Excute la commande shell spcifie.
Contrle du suivi par commandes

Si la routine de suivi est configure pour une excution asynchrone (trace a), le suivi peut
tre contrl par les commandes :
11-6
trcon
Lance ou relance la collecte des donnes dvnements.
trcoff
Suspend la collecte des donnes dvnements.
trcstop
Arrte la collecte des donnes dvnements et met fin la routine de

suivi.
Lancement et contrle du suivi depuis un programme

Lutilitaire de suivi AIX peut tre lanc partir dun programme, via un appel de
sous-routine. Cette sous-routine, trcstart, se trouve dans la bibliothque librts.a.
La syntaxe de la sous-routine trcstart est :
int trcstart(char *args)
args tant la liste des options que vous auriez associes la commande trace. Par dfaut,
le suivi systme (canal 0) est lanc. Pour lancer un suivi gnrique, spcifiez loption g
dans la chane args. Lexcution termine, la sousroutinetrcstart renvoie lID canal. Pour
les suivis gnriques, cet ID canal permet denregistrer dans le canal gnrique priv.
Si vous compilez un programme via cette sous-routine, le lien la bibliothque librts.a doit
tre explicitement demand (spcifiez l rts comme option de compilation).
Contrle du suivi via les sous-routines de suivi

Le contrle de la routine de suivi seffectue via des sous-routines de la bibliothque librts.a.
Ces sous-routines renvoient zro lorsque la commande aboutit. Il sagit des sous-routines :
int trcon()
Lance ou relance la collecte des donnes de suivi.
int trcoff()
Suspend la collecte des donnes de suivi.
int trcstop()
Arrte la collecte des donnes de suivi et met fin la routine de suivi.
Contrle du suivi via des appels ioctl

Chacune des sous-routines de contrle de suivi ci-dessus :
ouvre (open) lunit de contrle de suivi (/dev/systrctl),
met lioctl appropri,
ferme (close) lunit de contrle,
revient au programme appelant.
Pour activer/dsactiver le suivi de portions individuelles de code, il peut tre plus efficace
pour le programme dmettre directement les contrles ioctl. Ce qui vite la succession
douvertures et de fermetures de lunit de contrle du suivi. Pour utiliser linterface ioctl
dans un programme, ajoutez <sys/trcctl.h> pour dfinir les commandes ioctl. La syntaxe
de ioctl est la suivante :
ioctl (fd,CMD,Canal)
o :
fd
est le descripteur de fichier obtenu par l ouverture de /dev/systrctl
CMD
est : TRCON, TRCOFF ou TRCSTOP
canal
est le canal de suivi (0 pour le suivi systme).
11-7
Lexemple suivant illustre comment lancer le suivi partir dun programme, le suivi ne
portant que sur une portion spcifie du code :
#include <fcntl.h>
#include <sys/trcctl.h>
extern int trcstart(char *arg);
char *ctl_dev =/dev/systrctl;
int ctl_fd;
main()
{
printf(configuring trace collection \n);
if (trcstart(ad)){
perror(trcstart);
exit(1);
}
printf(opening the trace device \n);
if((ctl_fd =open (ctl_dev,O_RDWR))<0){
perror(open ctl_dev);
exit(1);
}
printf(turning data collection on \n);
if(ioctl(ctl_fd,TRCON,0)){
perror(TRCON);
exit(1);
}
/* *** code here will be traced *** */
printf(The code to print this line will be traced.);
printf(turning data collection off\n);
if (ioctl(ctl_fd,TRCOFF,0)){
perror(TRCOFF);
exit(1);
}
printf(stopping the trace daemon \n);
if (trcstop(0)){
perror(trcstop);
exit(1);
}
exit(0);
}
Aucun fichier de sortie ntant spcifi dans le paramtre pour la sous-routine trcstart(), la
sortie du suivi se trouvera dans /var/adm/ras/trcfile, qui est galement le fichier dentre
par dfaut de la commande trcrpt.
11-8
Ajout dvnements de suivi

Le systme dexploitation est livr avec des vnements cls. Il suffit lutilisateur dactiver
le suivi pour capturer le flux dvnements systme. Les dveloppeurs peuvent
instrumenter leur code application au cours du dveloppement, des fins doptimisation.
Ils disposent ainsi dune vision claire des interactions entre leurs applications et le systme.
Pour ajouter un vnement de suivi, il vous faut dfinir les articles de suivi gnrs par
votre programme, en fonction des conventions de linterface de suivi. Insrez ensuite des
macros dancrage de suivi aux endroits souhaits dans votre programme. Le suivi peut tre
lanc par nimporte lequel des moyens dappel et de contrle standard (commandes,
sous-commandes ou appels de sous-routines). Pour formater le suivi via le programme
trcrpt, insrez, dans le fichier de format de suivi, des strophes pour dcrire chaque nouvel
article de suivi et prciser son formatage.
Formes dun article vnement de suivi

Un vnement de suivi peut prendre diverses formes. Un vnement est constitu dun mot
dancrage, de mots de donnes (facultatifs) et dune horodate (facultatif), comme illustr
la figure Format dun article de suivi. Un type 4 bits est dfini pour chaque forme que peut
prendre un article. Le champ type est impos par la routine denregistrement pour que
lutilitaire de compte rendu puisse toujours passer dun vnement lautre pendant le
traitement des donnes, mme si les rgles de formatage du fichier de format de suivi sont
incorrectes ou absentes pour cet vnement.
ID ancre
12 bits
Type
4 bits
mot de donnes 1
Champ de donnes
16 bits
mot de donnes 2
mot de donnes 3
mot de donnes 4
mot de donnes 5
Horodate 32 bits
mot
dancrage
(obligatoire)
D1
(en option)
D2
(en option)
D3
(en option)
D4
(en option)
D5
(en option)
T
(en option)
Format dun article de suivi

Un article de suivi doit tre le plus court possible. Nombre dvnements systme se
contentent du mot dancrage et de lhorodate. Un autre vnement cit doit tre utilis avec
parcimonie car moins efficace et plus gnant : il sagit dun format long permettant
denregistrer des donnes de longueur variable. Dans cette forme, le champ de donnes
16 bits du mot dancrage est converti en un champ longueur qui dcrit la longueur de
lenregistrement de lvnement.
Canaux de suivi
Lutilitaire de suivi peut prendre en charge simultanment jusqu huit canaux dactivit
dancrage de suivi, numrots de 0 7. Le canal 0, toujours utilis pour les vnements
systme, ne leur est nanmoins pas rserv : des applications peuvent y faire appel. Les
sept autres canaux, appels canaux gnriques, sont destins au suivi des activits des
applications.
11-9
Au lancement du suivi, le canal 0 est utilis par dfaut. Une commande trace n (n tant le
numro de canal) lance le suivi vers un canal gnrique. Lusage des canaux gnriques
souffre quelques restrictions :
Linterface vers les canaux gnriques consomme plus de temps CPU que linterface
vers le canal 0 : dune part, il faut distinguer entre les canaux et, dautre part, les canaux
gnriques enregistrent des articles de longueur variable.
Les vnements enregistrs sur le canal 0 et sur les canaux gnriques ne peuvent tre
corrls que par le biais de lhorodate, et non squentiellement : il peut donc y avoir des
cas o il est impossible de dterminer lantriorit dun vnement.
Macros denregistrement des vnements de suivi

Il existe une macro pour chaque type possible denregistrement dvnement. Les macros
sont dfinies dans /usr/include/sys/trcmacros.h et les ID vnements, dans
/usr/include/sys/trchkid.h. Ces deux fichiers doivent tre inclus dans tout programme
enregistrant des vnements de suivi.
Les macros enregistrant les vnements sur le canal 0 avec horodate sont les suivantes :
TRCHKL0T(hw)
TRCHKL1T(hw,D1)
TRCHKL2T(hw,D1,D2)
TRCHKL3T(hw,D1,D2,D3)
TRCHKL4T(hw,D1,D2,D3,D4)
TRCHKL5T(hw,D1,D2,D3,D4,D5)
Pour enregistrer les vnements sur le canal 0 sans horodate, vous disposez de :
TRCHKL0(hw)
TRCHKL1(hw,D1)
TRCHKL2(hw,D1,D2)
TRCHKL3(hw,D1,D2,D3)
TRCHKL4(hw,D1,D2,D3,D4)
TRCHKL5(hw,D1,D2,D3,D4,D5)
Le champ type de lenregistrement de lvnement de suivi est dfini la valeur
correspondant la macro utilise, quelle que soit la valeur de ces 4 bits dans le
paramtre hw.
Il nexiste que deux macros pour enregistrer les vnements sur un des canaux gnriques
(1 7). Il sagit de :
TRCGEN(ch,hw,D1,len,buf)
TRCGENT(ch,hw,D1,len,buf)
Ces macros enregistrent, dans le flux dvnements spcifi par le paramtre canal (ch), un
mot dancrage (hw), un mot de donnes (D1) et len octets partir du segment de donnes
utilisateur commenant lemplacement spcifi par buf.
ID dvnements
LID vnement dun article de suivi identifie cet article comme appartenant une classe
dfinie. LID vnement est la base sur laquelle le mcanisme de suivi enregistre ou ignore
les ancrages de suivi, et sur laquelle la commande trcrpt inclut ou exclut les articles de
suivi dans le compte rendu format.
Les ID vnement sont sur 12 bits (trois chiffres hexadcimaux). Il en existe 4096 possibles.
Les ID qui sont maintenus en permanence et livrs avec le code sont affects de faon
11-10
permanente par BULL, pour viter toute duplication. Pour permettre aux utilisateurs de
dfinir des vnements dans leurs environnements ou au cours de dveloppements,
lintervalle dID compris entre 010 0FF (hexa) leur a t rserv : les utilisateurs en
disposent leur guise dans leur propre environnement (cest--dire, dans tout ensemble de
systmes dans lequel ils sont prts assurer quun mme ID vnement nest pas utilis de
faon ambigu).
Attention : Il est important que les utilisateurs qui se servent de cet intervalle
dvnements maintiennent le code dans leur environnement. Si vous livrez du code,
instrument avec des ID dancrage temporaires, dans un environnement dans lequel
vous ne contrlez pas lutilisation des ID, vous risquez des collisions avec dautres
programmes qui utilisent les mmes ID dans cet environnement.
Les ID vnement doivent tre conservs car peu nombreux, mais ils peuvent tre tendus
par le biais du champ de donnes 16 bits. Il existe donc 65536 vnements distincts
possibles pour chaque ID dancrage thorique. La seule raison davoir un ID unique est
quun ID est le niveau auquel la collecte et le rapport de filtrage sont disponibles dans
lutilitaire de suivi.
Un vnement ajout par lutilisateur peut tre format via la commande trcrpt sil existe
une strophe pour lvnement dans le fichier de format de suivi spcifi. Ce fichier est un
fichier ASCII modifiable : reportez-vous Syntaxe des strophes du fichier de format de
suivi, page 11-13.
Exemples de codage et de formatage dvnements

Lexemple suivant illustre lutilisation dvnements de suivi pour chronomtrer la dure
dexcution dune boucle :
#include <sys/trcctl.h>
#include <sys/trcmacros.h>
#include <sys/trchkid.h>
char *ctl_file = /dev/systrctl;
int ctlfd;
int i;
main()
{
printf(configuring trace collection \n);
if (trcstart(ad)){
perror(trcstart);
exit(1);
}
printf(opening the trace device \n);
if((ctlfd = open(ctl_file,0))<0){
perror(ctl_file);
exit(1);
}
printf(turning trace on \n);
if(ioctl(ctlfd,TRCON,0)){
perror(TRCON);
exit(1);
}
11-11
for(i=1;i<11;i++){
TRCHKL1T(HKWD_USER1,i);
/* The code being measured goes here. The interval */
/* between occurrences of HKWD_USER1 in the trace */
/* file is the total time for one iteration.
*/
}
printf(turning trace off\n);
if(ioctl(ctlfd,TRCSTOP,0)){
perror(TRCOFF);
exit(1);
}
printf(stopping the trace daemon \n);
if (trcstop(0)){
perror(trcstop);
exit(1);
}
exit(0);
}
Lorsque vous compilez ce programme, vous devez tablir un lien la bibliothque librts.a
comme suit :
$ xlc O3 sample.c o sample l rts
HKWD_USER1 a pour ID 010 (hexadcimal). Vous pouvez le vrifier en consultant
/usr/include/sys/trchkid.h.). Lutilitaire de compte rendu ignore comment formater
lvnement HKWD_USER1, sauf si des rgles sont indiques dans le fichier de format de
suivi. Lexemple de strophe suivante peut tre utilise :
# User event HKWD_USER1 Formatting Rules Stanza
# An example that will format the event usage of the sample program
010 1.0 L=APPL USER EVENT HKWD_USER1 O2.0
\n \
The # of loop iterations = U4
\n \
The elapsed time of the last loop = \
endtimer(0x010,0x010) starttimer(0x010,0x010)
Ninsrez pas cette strophe dans le fichier /etc/trcfmt original, mais faites une copie de
celui-ci dans votre rpertoire (mytrcfmt, par exemple). Lorsque vous excutez le
programme exemple, les donnes dvnement brutes sont captures dans le fichier journal
par dfaut, puisquaucun autre fichier na t spcifi la sous-routine trcstart. Vous
souhaitez probablement filtrer la sortie pour ne conserver que vos vnements. Pour ce
faire, lancez la commande trcrpt, comme suit :
trcrpt d 010 t mytrcfmt O exec=on > sample.rpt
Vous pouvez parcourir sample.rpt pour voir le rsultat.
11-12
Syntaxe des strophes du fichier de format de suivi

Lobjet du fichier de format de suivi est de fournir des rgles de prsentation et daffichage
des donnes attendues pour chaque ID dvnement. Ce qui permet de formater les
nouveaux vnements sans modifier lutilitaire de compte rendu. Des rgles sont
simplement ajoutes au fichier de format pour ces vnements. La syntaxe des rgles offre
une grande souplesse de prsentation des donnes.
La figure Syntaxe dune strophe dun fichier de format de suivi, page 11-13, illustre la
syntaxe pour un vnement donn. Une strophe de format peut tre aussi longue que
ncessaire pour dcrire les rgles applicables un vnement donn. Si elle se prolonge
sur plusieurs lignes, terminez les lignes intermdiaires par le caractre \. Les champs sont
les suivants :
ID-vn
L=
V.R
APPL
SVC
KERN
INT
label-vn
n
t
starttimer(#,#)
endtimer(#,#)
descrip-donnes
o descripteur-donnes a la syntaxe :
Format
label-donnes
label-corresp
, val-corresp
descripteur-donnes
descripteur-donnes
Syntaxe dune strophe dun fichier de format de suivi

ID-vn
Chaque strophe commence par lID (3 chiffres hexadcimaux) de

lvnement quelle dcrit, suivi dun espace.
V.R
Dcrit la version (V) et la release (R) dans lesquels lvnement a t

affect en premier. Vous pouvez indiquer nimporte quels entiers pour V
et R (un utilisateur peut vouloir conserver son propre mcanisme de
suivi).
L=
Spcifie le niveau dindentation du texte. La description textuelle dun

vnement peut commencer divers niveaux dindentation. Ceci pour
amliorer la lisibilit du compte rendu. Ces niveaux correspondent au
niveau dexcution du systme. Les niveaux reconnus sont : niveau
application (APPL), appel systme de transition (SVC), niveau noyau
(KERN) et interruption (INT).
label-vn
Chane de texte ASCII dcrivant lutilisation globale de lID vnement

utilise par loption j de la commande trcrpt pour fournir une liste
dvnements avec leur premier niveau de description. Le label-vn
apparat galement dans la sortie formate de lvnement, sauf si le
label-vn commence par le caractre @.
11-13
\n
La strophe vnement dcrit comment analyser, libeller et prsenter les

donnes dun enregistrement dvnement. La fonction \n (nouvelle
ligne) peut tre imbrique dans la strophe vnement pour forcer la
prsentation des donnes sur une nouvelle ligne. Les donnes peuvent
ainsi tre prsentes sur plusieurs lignes.
\t
Insre une tabulation lendroit o il se trouve dans lanalyse de la

description. Cette fonction est semblable la fonction \n. Des espaces
peuvent galement tre insrs via les champslabel_donnes ou
label_corresp.
starttimer(timerID), endtimer(timerID)
timerID est un identificateur unique qui associe un starttimer particulier
avec un endtimer ultrieur ayant le mme identificateur. Par convention
(non obligatoire), timerID est de la forme :
ID de lvnement de dpart, ID de lvnement final
Lorsque lutilitaire de compte rendu rencontre une directive starttimer
au cours de lanalyse dun vnement, il associe lheure de lvnement
de dpart au timerID spcifi. Lorsquil rencontre un endtimer avec le
mme timerID, il affiche lcart de temps (entre parenthses) entre les
deux vnements. Les vnements dbut et fin dappel systme font
appel cette fonction : au retour dun vnement appel systme, la
dure de cet appel est indique.
11-14
descripdonnes
Dcrit comment lutilitaire de compte rendu doit consommer, libeller et

prsenter les donnes. La syntaxe du champ descripteur-donnes est
dveloppe dans la seconde partie de la figure Syntaxe dune strophe
dun fichier de format de suivi. Les diffrents champs du descripteurdonnes sont dcrits ci-aprs :
format
Lutilisateur peut se reprsenter lutilitaire de compte
rendu comme dot dun pointeur sur la partie donnes
dun vnement. Ce pointeur est initialis pour pointer
sur le dbut des donnes dvnement (le champ de
donnes 16 bits dans le mot dancrage). Le champ
format dcrit la quantit de donnes consommes par
lutilitaire partir de ce point et comment considrer
ces donnes. Par exemple, un champ format de Bm.n
indique lutilitaire de consommer m octets et n bits de
donnes et de les considrer comme binaires. (Les
champs de format possibles sont dcrits plus avant.)
Si le champ de format nest pas suivi dune virgule,
lutilitaire gnre les donnes consommes dans le
format spcifi. Sil lest, cela signifie que les donnes
ne doivent pas tre affiches, mais compares aux
valeurs-corresp qui suivent. Le descripteur de donnes
associ avec la valeur-corresp correspondante tant
ensuite appliqu au reste des donnes.
label-donnes Le label-donnes est une chane ASCII prcdant
ventuellement la sortie des donnes consommes par
le champ de format.
valeur-corresp La valeur-corresp correspond des donnes dont le
format est identique celui dcrit par les champs de
format prcdents. Gnralement, plusieurs
valeurs-corresp suivent un champ de format en cours
de recherche de correspondance. Les champs
successifs de correspondance sont spars par des
virgules. La dernire valeur nest pas suivie dune
virgule. Un \* remplace nimporte quelle chane de
caractres. Un caractre gnrique est souvent utilis
comme dernier champ valeur-corresp pour spcifier les
rgles par dfaut, si aucune correspondance na t
trouve avec les champs valeur-corresp prcdents.
label-corresp
Le label-corresp est une chane ASCII, gnre pour la

correspondance concerne.
11-15
Tous les champs de format possibles sont dcrits dans les commentaires du fichier
/etc/trcfmt. En voici une brve prsentation.
Descriptions de champs de format
Am.n
Spcifie que m octets de donnes doivent tre consommes comme

texte ASCII et que le texte doit tre affich dans un champ de sortie de
n caractres. Le pointeur de donnes est dplac de m octets.
S1, S2, S4
Spcifie une chane aligne gauche. La longueur du champ est

dfinie comme gale 1 octet (S1), 2 octets (S2) ou 4 octets (S4). Le
pointeur de donnes est dplac en consquence.
Bm.n
Spcifie des donnes binaire de m octets et n bits. Le pointeur de

donnes est dplac en consquence.
Xm
Spcifie des donnes hexadcimales de m octets. Le pointeur de

donnes est dplac en consquence.
D2, D4
Spcifie un format dcimal sign. Des donnes de longueur 2 octets

(D2) ou 4 octets (D4) sont consommes.
U2, U4
Spcifie un format dcimal non sign. Des donnes de longueur 2 ou

4 octets sont consommes.
F4, F8
Virgule flottante de 4 ou 8 octets.
Gm.n
Positionne le pointeur de donnes m octets et n bits lintrieur des

donnes.
Om.n
Omet, partir de la position courante du pointeur de donnes,

les m octets et les n bits suivants.
Rm
Recule le pointeur de donnes de m octets.
Quelques macros peuvent servir de champs de format, pour un accs rapide aux donnes.
Par exemple :
$HD, $D1, $D2, $D3, $D4, $D5
Accde au champ de donnes 16 bits du mot dancrage et des mots de
donnes 1 5 de lenregistrement de lvnement, respectivement.
Le pointeur de donnes nest pas dplac. Les donnes auxquelles
accde une macro sont hexadcimales par dfaut. Une macro peut tre
associe un autre type de donnes (X, D, U, B) par le biais du
caractre % suivi du nouveau code de format. Par exemple :
$D1%B2.3
Cette macro entrane laccs au mot de donnes 1, mais en le
considrant comme 2 octets et 3 bits de donnes binaires.
Les commentaires intgrs au fichier /etc/trcfmt dcrivent les autres possibilits de macros
et de formats, et expliquent comment crer des macros personnalises.
11-16
Chapitre 12. Outil de diagnostic PDT
PDT value ltat dun systme et surveille les modifications intervenant sur la charge de
travail et les performances. Il tente didentifier les problmes leur naissance, proposant
des solutions avant quils ne deviennent critiques. PDT est disponible partir dAIX
version 4.1.
Pour lessentiel, PDT ne requiert aucune entre utilisateur. La collecte et le report des
donnes PDT sont facilement activs et aucune intervention ultrieure de ladministrateur
nest requise. Les donnes sont rgulirement collectes et enregistres en vue dune
analyse historique, et un rapport est gnr et adress lID utilisateur adm. Normalement,
seuls les problmes apparents les plus significatifs sont consigns sur le rapport. Labsence
de problme significatif est galement signale, le cas chant. Vous pouvez personnaliser
PDT pour que les rapports soient achemins vers un autre utilisateur ou que les problmes
de gravit moindre soient galement consigns.
Cette rubrique traite des points suivants :
Structure de PDT
Porte de lanalyse PDT
Exemple de compte rendu PDT
Installation et activation de PDT
Personnalisation de PDT
Rponse aux messages PDT
Structure de PDT
Comme illustr la figure Structure des composants de PDT, lapplication PDT est
constitue de trois composants :
cron
contrle
collecte
contrle
rapport
contrle
retenue
PDT
historique
collecteurs
fichier,
mail
rapporteur
donnes
courantes
donnes
courantes
et
historiques
rapport
priodique
limination des
donnes obsoltes
Structure des composants de PDT
Outil de diagnostic PDT
12-1
Llment de collecte, compos dun ensemble de programmes qui collectent et

enregistrent rgulirement les donnes.
Llment de validation qui passe rgulirement en revue les donnes collectes et
limine les donnes obsoltes.
Llment de consignation qui produit rgulirement un diagnostic partir de lensemble
courant des donnes historiques.
PDT prend en compte diffrents aspects de la configuration dun systme, sa disponibilt et
ses performances, lors de de son estimation. Les zones de dsquilibre potentiel sont
notamment mises en vidence (configuration des E/S, de la pagination, etc.), ainsi que
dautres problmes de configuration (disques non affects des groupes de volume, par
exemple). Il est procd une large valuation, portant aussi bien sur la taille des fichiers et
systmes de fichiers, que sur lutilisation de la zone de pagination, les dlais imposs par le
rseau ou ceux relatifs la charge de travail, etc.
Porte de lanalyse PDT

PDT collecte quotidiennement les donnes relatives la configuration, la disponibilit, la
charge de travail et les performances. Ces donnes sont maintenues dans un
enregistrement historique. Environ un mois de donnes sont ainsi conserves. PDT gnre
galement quotidiennement un rapport de diagnostic. Le rapport est envoy lutilisateur
adm.
Une copie de ce rapport est en outre stocke dans /var/perf/tmp/PDT_REPORT. Au
pralable, lancien rapport est renomm /var/perf/tmp/PDT_REPORT.last.
Bien que nombre de problmes de performances soient de nature spcifique (mmoire
insuffisante sur un systme, par exemple), PDT tente dappliquer quelques principes
gnraux dans sa recherche. En voici quelques-uns.
Exploitation quilibre des ressources
Dune facon gnrale, sil existe plusieurs ressources de mme type, quilibrer leur
exploitation gnre une amlioration des performances.
Nombre comparable de volumes physiques (disques) sur chaque carte de disque
Espace de pagination rparti sur plusieurs volumes physiques
Charge grosso modo quivalente sur les diffrents volumes physiques.
Circonscription des oprations
Lexploitation des ressources a ses limites. Toute tendance les outrepasser doit tre
dtecte et signale.
Une unit de disque ne peut tre utilise plus de 100 % du temps.
Fichiers et systmes de fichiers ne peuvent excder lespace qui leur est affect.
Identification de la tendance de la charge de travail
Les tendances peuvent indiquer un changement de la nature de la charge de travail ou une
augmentation de ressources utilises :
Nombre dutilisateurs connects.
Nombre total de processus.
Pourcentage de CPU disponible.
Oprations sans erreur
Les erreurs (matrielles et logicielles) ont souvent une incidence sur les performances :
Consultez les journaux derreurs matrielles et logicielles.
Signalez les pages VMM incorrectes.
12-2
Examen des modifications

De nouvelles charges de travail ou de nouveaux processus commenant consommer des
ressources sont parfois des signes avant-coureurs de problmes.
Apparence des processus consommant dimportantes ressources CPU ou mmoire.
Adquation des paramtres systme
Les paramtres systme sont nombreux. Sont-ils tous dfinis de faon approprie ?
maxuproc a-t-il une valeur suffisante ?
Quen est-il des paramtres de contrle de la charge mmoire ?
Le rapport PDT est constitu de plusieurs sections (voir ci-aprs). Aprs len-tte, la section
Alerts indique les violations identifies des principes nots ci-dessus. En labsence
dalertes, cette section ne figure pas dans le rapport. Les deux sections suivantes
concernent les tendances en amont et en aval : elles sont axes sur lanticipation des
problmes et non sur lidentification de problmes existants. Les mmes principes sont
gnralement appliqus mais dans loptique de prvoir les violations futures. Si aucune
tendance de ce type (en amont ou en aval) nest dtecte, ces sections ne figurent pas
dans le rapport.
12-3
Exemple de compte rendu PDT

___________________________________________________________________
Performance Diagnostic Facility 1.0
Report printed: Tue Aug 3 10:00:01 1993
Host name: test.austin.ibm.com
Range of analysis is from: Hour 16 on Monday, July 5th, 1993
to: Hour 9 on Tuesday, August 3rd, 1993.
[To disable/modify/enable collection or reporting, execute the
pdt_config script]
Alerts
I/O BALANCE
Phys. vol. hdisk0 is significantly busier than others
volume cd0, mean util. = 0.00
volume hdisk0, mean util. = 11.75
volume hdisk1, mean util. = 0.00
PAGE SPACE AND MEMORY
Mean page space used = 46.85 MB
System has 32MB memory; may be inadequate.
Consider further investigations to determine if memory is a
bottleneck
Upward Trends
FILE SYSTEMS
File system hd2 (/usr) PERCENTAGE FULL
now, 45.00 % full, and growing an avg. of 2.0 %/day
At this rate, hd2 will be full in about 15 days
PAGE SPACE
Page space hd6 USE
now, 44.80 MB and growing an avg. of 1.81 MB/day
At this rate, hd6 will be full in about 30 days
WORKLOAD TRACKING
Workload nusers indicator is increasing;
now 23, and growing an avg. of 1.2 per day
System Health
SYSTEM HEALTH
Current process state breakdown:
2.00 [ 3.0 %] : waiting for the cpu
64.00 [ 97.0 %] : sleeping
66.00 = TOTAL
[based on 1 measurement consisting of 10 2second samples]
Summary
This is a severity level 2 report
Further details are available at severity levels > 2
___________________________________________________________________
Dans cet exemple, la section den-tte indique le numro de version de PDT, la date du
rapport, lhte partir duquel ont t collectes les donnes et les dates de dbut et de fin
des donnes analyses.
La section suivante, Alerts, indique les conditions de configuration et de charge suspectes.
Dans lexemple, il apparat quun des trois disques systme rcupre lessentiel des
activits dE/S. Il est clair que la charge des E/S nest pas rpartie de faon tirer le
meilleur parti des ressources disponibles. Le message suivant,
PAGE SPACE AND MEMORY, suggre que le systme est peut-tre sous-configur
au niveau mmoire.
12-4
La section Upward Trends identifie deux tendances possibles. La premire est que le
systme de fichiers sur le volume logique hd2 (systme de fichiers /usr) crot au rythme
moyen de 2 % par jour. La date de saturation probable est indique, calcule sur la base
dune croissance linaire continue.
La seconde tendance est lapparente croissance systmatique du niveau dutilisation de
lune des zones de pagination. Des informations sur son taux de croissance et sur la date
prsume de saturation sont donnes. Savoir quels sont les systmes de fichiers et les
espaces de pagination qui frlent la saturation est de la plus haute importance (surtout si le
taux de croissance est lev ou que la date de saturation prvue est imminente), car leur
saturation peut provoquer un blocage du systme ou de lapplication.
La troisime tendance est une modification dun des indicateurs de charge de travail. Les
indicateurs surveills par PDT sont les suivants :
Mot-cl
Indicateur
nusers
Nombre total dutilisateurs connects.
loadavg
Moyenne de charge sur 15 minutes.
nprocesses
Nombre total de processus.
STAT_A
Nombre de processus actifs.
STAT_W
Nombre de processus permuts.
STAT_Z
Nombre de processus zombis.
STAT_I
Nombre de processus libres.
STAT_T
Nombre de processus arrts aprs rception dun signal.
STAT_x
Nombre de processus signals ltat x par la commande ps, x tant

un tat non rpertori ci-dessus.
cp
Dure requise pour copier un fichier de 40 ko.
idle_pct_cpu0
idle_pct_avg
La section suivante, System Health, se sert dun certain nombre dindicateurs de charge
pour dterminer lusage que font les processus de leur temps.
La dernire section du compte rendu (Summary) indique le niveau de gravit slectionn, et
si changer de niveau donne accs des informations supplmentaires. (Le niveau de
gravit le plus lev est 1, niveau par dfaut du compte rendu. Le niveau le plus bas est 3.)
Tout message ( lexclusion des informations de len-tte et du rcapitulatif) apparaissant
dans le compte rendu PDT doit tre examin. Vous devez remdier au problme signal ou
du moins trouver une explication lerreur. Les rponses possibles aux messages
spcifiques sont indiques Rponse aux messages PDT, page 12-10.
Installation et activation de PDT

PDT est install via installp comme option bos.perf.diag_tool du BOS sous licence dAIX
version 4.1.
Pour dmarrer la collecte et la consignation des donnes, PDT doit tre activ : excutez
cet effet le script /usr/sbin/perf/diag_tool/pdt_config. Seul lutilisateur root est habilit
excuter ce script. Lexcution termine, le message suivant saffiche :
12-5
# /usr/sbin/perf/diag_tool/pdt_config
________________PDT customization menu__________________
1) show current PDT report recipient and severity level
2) modify/enable PDT reporting
3) disable
PDT reporting
4) modify/enable PDT collection
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
Please enter a number:
Si vous rpondez 4, la collecte et la consignation par dfaut sont actives. Lentre crontab
de lutilisateur adm est mise jour pour intgrer les entres PDT. La collecte est effective
lorsque les travaux cron sont excuts par cron. Slectionnez 7 pour mettre fin au
programme pdt_config.
Pour dsactiver la collecte, slectionnez loption 5.
Personnalisation de PDT
Certains aspects de PDT peuvent tre personnaliss. Nimporte quel utilisateur peut, par
exemple, tre dsign comme destinataire rgulier des rapports PDT, et la dure de
conservation des donnes dans lenregistrement historique PDT peut tre modifie.
Toute personnalisation suppose de modifier un des fichiers PDT dans
/var/perf/cfg/diag_tool/ ou dexcuter le script /usr/sbin/perf/diag_tool/pdt_config.
Nous vous conseillons de ne rien modifier avant davoir obtenu et tudi quelques rapports
PDT et davoir acquis une certaine aisance dans la manipulation de cet outil.
Dsignation dun autre destinataire du rapport et modification du niveau de gravit

Par dfaut, les rapports sont gnrs avec un niveau de gravit de 1, ce qui signifie que
seuls les problmes les plus srieux sont identifis. Il existe deux autres niveaux (2, 3)
offrant gnralement plus de dtails. Par ailleurs, tout rapport PDT est expdi vers lID
utilisateur adm ; peut-tre souhaitez-vous ladresser un autre utilisateur ou ne pas
lenvoyer du tout.
Ces deux paramtres sont contrls par le script pdt_config. Le dialogue suivant dsigne
un nouvel utilisateur destinataire et modifie le niveau de gravit :
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
Please enter a number: 1
current PDT report recipient and severity level
adm 1
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
12-6
enter id@host for recipient of report : rsmith

enter severity level for report (13): 2
report recipient and severity level
rsmith 2
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
current PDT report recipient and severity level
rsmith 2
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
#
Dans cet exemple, lutilisateur rsmith devient le destinataire et le niveau de gravit passe
2. Ce qui signifie que lutilisateur rsmith recevra le rapport PDT et que les messages de
gravit 1 et 2 y seront inclus. Notez lutilisation de loption 1 pour dterminer le destinataire
actuel du rapport PDT ainsi que le niveau de gravit consign.
Pour mettre fin la consignation (sans interrompre la collecte), loption 3 est slectionne,
par exemple :
#/usr/sbin/perf/diag_tool
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
disable PDT reporting done
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
reporting has been disabled (file .reporting.list not found).
12-7

3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
#
Niveaux de gravit PDT

Les listes suivantes indiquent les problmes susceptibles de se poser chaque niveau de
gravit. Noubliez pas que slectionner une gravit n entrane la consignation de tous les
problmes de gravit infrieure ou gale n.
Problmes de gravit 1
Systme de fichiers JFS indisponible
Systme de fichiers JFS quasi-satur
Volume physique non affect un groupe de volumes
Espaces de pagination tous dfinis sur un seul volume physique
Mmoire systme apparemment insuffisante pour la charge de travail actuelle
Espace de pagination quasi-satur
Problme possible au niveau des paramtres de contrle de charge
Trames de mmoire dfectueuses dtectes par VMM
Hte de .nodes inaccessible
Problmes de gravit 2
Dsquilibre dans la configuration des E/S (disques par carte, par exemple)
Dsquilibre dans laffectation de lespace de pagination sur les volumes physiques
concerns
Fragmentation dun espace de pagination dans un groupe de volumes
Dsquilibre significatif de la charge des E/S sur les volumes physiques
Nouveau processus identifi comme gros consommateur de mmoire ou de CPU
Fichiers de .files prsentant une croissance (ou un dclin) de taille systmatique
Systme de fichiers ou espace de pagination prsentant une croissance (ou un dclin)
systmatique au niveau de lutilisation de lespace
Dgradation du temps de rponse ping ou du pourcentage de paquets perdus sur un
hte de .nodes
Processus getty consommant trop de temps CPU
Processus gros consommateur de CPU ou de mmoire prsentant une croissance
(ou un dclin) systmatique au niveau de lutilisation des ressources
Messages de gravit 3
Les messages de gravit 3 fournissent des complments aux messages de gravit 1
et 2, sur les problmes identifis aux niveaux 1 et 2 caractristiques de la collecte des
donnes, tel le nombre dchantillons, par exemple.
12-8
Obtention dun rapport PDT la demande

Outre le rapport priodique, un utilisateur quelconque peut demander un rapport partir des
donnes existantes via la commande /usr/sbin/perf/diag_tool/pdt_report [niveau-gravit].
Le rapport est produit avec le niveau de gravit spcifi (1 par dfaut) et crit dans stdout.
Gnrer un rapport de cette manire na aucune incidence sur les fichiers
/var/perf/tmp/PDT_REPORT ou /var/perf/tmp/PDT_REPORT.last.
Consignation derreurs PDT

Des erreurs peuvent advenir dans nimporte lequel des composants PDT. En gnral, une
erreur ne met pas fin PDT. Mais un message est envoy vers le fichier derreur standard
de PDT : /var/perf/tmp/.stderr, et cette phase de traitement se termine.
Les utilisateurs devant faire face des situations inattendues, telle que labsence de
rapport, trouveront de prcieuses indications dans le fichier /var/perf/tmp/.stderr.
Dsinstallation de PDT
Il est impossible de dsinstaller PDT directement via pdt_config, mais si loption 6 est
requise, un message explicite les tapes ncessaires au retrait de PDT du systme :
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
PDT is installed as package bos.perf.diag_tool in the bos lpp.
Use the installp facility to remove the package
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
#
Modification de la liste des fichiers contrls par PDT

PDT analyse fichiers et rpertoires la recherche daccroissement systmatique de taille. Il
nexamine que les fichiers et rpertoires figurant dans le fichier
/var/perf/cfg/diag_tool/.files. Le fichier .files comporte un nom de fichier/rpertoire par
ligne. Son contenu par dfaut est :
/usr/adm/wtmp
/var/spool/qdaemon/
/var/adm/ras/
/tmp/
Vous pouvez modifier ce fichier via un diteur pour surveiller des fichiers et rpertoires
importants pour votre systme.
Modification de la liste des htes contrls par PDT

PDT surveille le dlai ping moyen des htes lists dans /var/perf/cfg/diag_tool/.nodes.
Ce fichier nest pas livr avec PDT (ce qui signifie quaucune analyse dhte nest effectue
12-9
par dfaut), mais peut tre cr par ladministrateur. Le fichier .nodes comporte un nom
dhte par ligne.
Modification de la dure de conservation de lenregistrement historique

Rgulirement, un script shell de validation est excut, qui limine de lenregistrement
historique PDT les donnes primes. Toutes les donnes sont soumises la mme
politique de conservation. Cette politique est dcrite dans le fichier
/var/perf/cfg/diag_tool/.retention.list. Le contenu par dfaut de .retention.list est :
* * * 35
qui fixe 35 jours le dlai de conservation de toutes les donnes. Vous pouvez remplacer
35 par nimporte quel entier non sign.
PDT se sert de lenregistrement historique pour valuer les tendances et identifier les
modifications du systme. Augmenter le dlai de conservation tend la porte de lanalyse,
mais en augmente le cot en termes despace disque et de temps de traitement PDT.
Lenregistrement historique PDT est conserv dans /var/perf/tmp/.SM. Le script de
validation cre une copie de ce fichier dans /var/perf/tmp/.SM.last avant deffectuer
lopration de validation. Les donnes historiques limines sont par ailleurs ajoutes
/var/perf/tmp/.SM.discards.
Lexistence de /var/perf/tmp/.SM.last fournit une sauvegarde limite, mais ladministrateur
doit vrifier que le fichier /var/perf/tmp/.SM est rgulirement sauvegard. Si le fichier est
perdu, PDT continue fonctionner, mais sans informations dhistorique. Au fil du temps,
lhistorique se reconstruit avec les nouvelles donnes collectes.
Modification de lheure des collectes, des validations et de la gnration des

comptes rendus
La collecte, la consignation et la validation sont pilotes par trois entres de la table cron
de lutilisateur adm. La collecte a lieu 9 h tous les jours ouvrs, la consignation 10 h ces
mmes jours, tandis que la validation est effectue une fois par semaine, le samedi 21 h.
Les entres cron (cres par excution du script /usr/sbin/perf/diag_tool/pdt_config et
slection de loption 2) sont indiques ci-aprs :
0 9 * * 15
0 10 * * 15
0 21 * * 6
/usr/sbin/perf/diag_tool/Driver_ daily
/usr/sbin/perf/diag_tool/Driver_ daily2
/usr/sbin/perf/diag_tool/Driver_ offweekly
Il est possible de modifier ces heures en ditant la table cron de lutilisateur adm, mais nous
vous le dconseilllons fortement.
Rponse aux messages PDT

PDT identifie plusieurs types de problmes. Les rponses y apporter dpendent des
ressources disponibles et des priorits de chaque structure. En voici quelques exemples.
12-10
Problme :
Systme de fichiers JFS indisponible
Rponse :
Recherchez la cause de cette indisponibilit.
Comm. utiles :
lsfs (pour dterminer ltat du systme de fichiers).
Problme :
Systme de fichiers JFS quasi-satur
Rponse :
Recherchez des fichiers volumineux dans le systme de fichiers,

gnrs peut-tre par lemballement dun processus. Ce systme de
fichiers a-t-il prsent une tendance crotre sur une longue dure
(vrifiez ce point dans le reste du rapport PDT ou dans les anciens
rapports) ?
Comm. utiles :
du, ls
Problme :
Volume physique non affect un groupe de volumes
Rponse :
Un volume doit tre dfini dans un groupe de volumes, faute de quoi, il

est inaccessible AIX et, de ce fait, perdu.
Comm. utiles :
lspv (pour confirmer que le volume nest pas affect).

smit (pour manipuler les groupes de volume).
Problme :
Espaces de pagination tous dfinis sur un seul volume physique
Rponse :
Le systme dispose de plusieurs volumes physiques, mais tous les

espaces de pagination sont dfinis sur un seul volume. Si le systme
doit faire appel la pagination, cette configuration entrane une
diminution des performances.
Comm. utiles :
smit (pour modifier les espaces de pagination).
Problme :
Mmoire apparemment insuffisante pour la charge de travail

actuelle
Rponse :
Si le systme fait souvent appel la pagination, il convient sans doute

daugmenter la mmoire pour amliorer les performances.
Comm. utiles :
lsps a, vmstat
Problme :
Espace de pagination quasi-satur
Rponse :
Lespace de pagination du systme doit sans doute tre agrandi,

moins que le problme ne soit d un processus perte de mmoire
auquel cas ce processus doit tre identifi et lapplication corrige.
Comm. utiles :
ps aucg (pour examiner lactivit des processus).

smit (pour modifier les caractristiques de lespace de pagination).
Problme :
Problme possible au niveau des paramtres de contrle de

charge
Rponse :
Les paramtres de contrle de charge sont valus en fonction de

lactivit de pagination courante. Par exemple, si un emballement se
produit et que le contrle de charge est dsactiv, il convient sans
doute de lactiver.
Comm. utiles :
schedtune
Problme :
Trames de mmoire dfectueuses dtectes par VMM
Rponse :
Il est peut-tre ncessaire danalyser la mmoire. Comparez la quantit

de mmoire installe avec celle effectivement accessible ; si cette
dernire est moindre, de la mmoire dfectueuse a t identifie.
Vous pouvez utiliser /usr/sbin/perf/diag_tool/getvmparms et
consulter la valeur de numframes pour dterminer le nombre rel de
trames mmoire de 4 ko.
Comm. utiles :
lscfg | grep mem (pour connatre la taille (Mo) de la mmoire

installe).
Problme :
Hte de .nodes inaccessible
Rponse :
Dterminez si le problme provient de lhte courant (le fichier

/etc/hosts a-t-il t modifi ?), de lhte distant (est-il en panne ?) ou
du rseau (le serveur de noms est-il en panne ?).
Comm. utiles :
ping
12-11
Problme :
Dsquilibre dans la configuration E/S (nombre de disques par

carte)
Rponse :
Envisagez de dplacer les disques de faon ne pas surcharger une

seule carte SCSI.
Comm. utiles :
lscfg (pour tudier la configuration actuelle).

iostat (pour dterminer si la charge actuelle des cartes est
dsquilibre).
12-12
Problme :
Dsquilibre dans laffectation de lespace de pagination sur les

volumes physiques concerns
Rponse :
Envisagez dunifier la taille des espaces de pagination, sauf pour

quelques mga-octets (disons 4) sur lespace principal (hd6).
Un dsquilibre important entre les tailles de ces espaces peut
diminuer les performances.
Comm. utiles :
smit
Problme :
Fragmentation dun espace de pagination dans un groupe de

volumes
Rponse :
Les performances au niveau de la pagination sont meilleures si les

zones de pagination sont contigus sur un volume physique.
Si toutefois les zones sont agrandies, il est possible de crer des
fragments clats sur tout le disque.
Comm. utiles :
lspv p hdiskn pour chaque volume physique du groupe de volumes.

Recherchez plusieurs PP Range dots du mme LVNAME et du mme
TYPE de pagination.
Problme :
Dsquilibre significatif de la charge des E/S sur les volumes

physiques
Rponse :
Si un volume physique semble peu actif au niveau des E/S, envisagez

de dplacer les donnes des volumes les plus occups vers les
volumes les moins occups. Dune faon gnrale, plus les E/S sont
uniformment rparties, meilleures sont les performances.
Comm. utiles :
iostat d 2 20 (pour tudier la rpartition actuelle des E/S sur les

volumes physiques).
Problme :
Nouveau processus identifi comme gros consommateur de

mmoire ou de CPU
Rponse :
Les plus gros consommateurs de CPU et de mmoire sont

rgulirement identifis par PDT. Si un de ces processus na pas t
dtect auparavant, il est signal dans un rapport dincident. Il convient
dexaminer ces processus pour dceler dventuels
dysfonctionnements. PDT ne prend en compte que lID de processus.
Si un utilisateur gros consommateur connu sarrte, puis est relanc
(avec un id processus diffrent), il sera identifi comme NOUVEL
utilisateur gourmand.
Comm. utiles :
ps aucg (pour examiner tous les processus et leur activit).
Problme :
Fichier de .files prsentant une croissance (ou un dclin) de taille

systmatique
Rponse :
Examinez la taille actuelle. Considrez le taux de croissance prvisible.

Quel utilisateur (ou application) gnre les donnes ? Par exemple, le
fichier /var/adm/wtmp est susceptible de grandir inconsidrment.
Sil devient trop grand, les dlais de connexion peuvent sallonger.
Parfois, la solution est de supprimer le fichier. Mais lessentiel dans tous
les cas est didentifier lutilisateur lorigine de cette croissance et
dtudier avec lui le moyen de rsoudre le problme.
Comm. utiles :
ls al (pour examiner la taille des fichiers/rpertoires).
Problme :
Systme de fichiers ou espace de pagination prsentant une

croissance (ou un dclin) systmatique au niveau de lutilisation
de lespace
Rponse :
Evaluez le taux de croissance et le dlai de saturation prvus. Il peut

tre ncessaire dagrandir le systme de fichiers (ou lespace de
pagination). Mais cette opration peut induire des effets pervers
(processus perte de mmoire, par exemple).
Comm. utiles :
smit (pour manipuler systmes de fichiers/espaces de pagination)

ps aucg, svmon (pour tudier lactivit des processus en mmoire
virtuelle).
filemon (pour tudier lactivit du systme de fichiers).
Problme :
Dgradation du temps de rponse ping ou du pourcentage de

paquets perdus sur un hte de .nodes
Rponse :
Lhte en question est-il confront des problmes de performances ?

Le rseau est-il confront ce type de problme ?
Comm. utiles :
ping, rlogin, rsh (pour chronomtrer les charges de travail connues sur
lhte distant)
Problme :
Un processus getty consomme trop de temps CPU
Rponse :
Les processus getty utilisant plus quun faible pourcentage de CPU

peuvent tre en erreur. Dans certaines situations, ces processus
peuvent consommer du CPU systme alors quaucun utilisateur nest
effectivement connect. La solution est en gnral de mettre fin au
processus.
Comm. utiles :
ps aucg (pour dterminer le pourcentage de CPU utilis).
Problme :
Processus gros consommateur de CPU ou de mmoire prsentant

une croissance (ou un dclin) systmatique au niveau de
lutilisation des ressources
Rponse :
Les gros consommateurs connus de CPU et de mmoire sont

constamment surveills pour dceler si leur demande augmente. En
tant que gros consommateurs, une croissance linaire de leur demande
doit retenir lattention plusieurs niveaux. Si cette croissance est
normale, elle figure parmi les lments essentiels de planification de la
capacit. Si elle est excessive, il convient denvisager de modifier la
charge (ou de rsoudre un problme chronique, telle une insuffisance
de mmoire).
Comm. utiles :
ps aucg
12-13
Problme :
maxuproc signal probablement insuffisant pour un userid donn
Rponse :
Il est problable que cet utilisateur approche du seuil de maxuproc.

maxuproc est un paramtre systme qui limite le nombre de processus
que les utilisateurs non racine sont autoriss maintenir actifs
simultanment. Si la limite est trop basse, le travail de lutilisateur peut
tre diffr ou arrt. Mais un utilisateur peut galement, par accident,
crer plus de processus que ncessaire. Un supplment dinvestigation
simpose dans les deux cas : lutilisateur doit tre consult pour
dterminer prcisment ce qui se passe.
Comm. utiles :
lsattr E l sys0 | grep maxuproc

Pour dterminer la valeur actuelle de maxuproc (bien quelle soit
galement indique directement dans le message PDT).
chdev l sys0 a maxuproc=100
Pour passer 100 la valeur de maxuproc (par exemple). Vous devez
tre utilisateur racine.
Problme :
Un indicateur WORKLOAD TRACKING indique une tendance

ascendante
Rponse :
La rponse dpend de lindicateur concern :

loadavg charge moyenne sur 15 minutes
Le niveau de conflits sur le systme est en hausse. Examinez le reste
du rapport PDT la recherche dindicateurs de goulots dtranglement
systme (par exemple, une utilisation consquente despace de
pagination peut rvler une insuffisance de mmoire, un dsquilibre
des E/S un incident au niveau du sous-systme dE/S, etc.).
nusers nombre total dutilisateurs connects
Les utilisateurs sont en nombre croissant sur le systme. Cette
information est capitale pour planifier la capacit. Cette croissance
est-elle prvue ? Peut-elle tre explique ?
12-14
nprocesses nombre total de processus

Les processus sur le systme sont en nombre croissant. Les
utilisateurs butent-ils sur le seuil maxuproc ? Peut-tre y a-t-il des
applications qui semballent, gnrant trop de processus en parallle.
STAT_A nombre de processus actifs
Une volution indique que le dlai dattente de CPU par les processus
est de plus en plus long.
STAT_W nombre de processus permuts
Une volution indique que les conflits de processus pour laccs la
mmoire sont excessifs.
STAT_Z nombre de processus zombis
Lexistence des zombis doit tre phmre. Si leur nombre augmente
sur un systme, vous devez tudier le problme.
STAT_I nombre de processus libres
Cette indication nest pas forcment signe de problme.
STAT_T nombre de processus arrts aprs rception dun signal
Une volution peut indiquer une erreur de programmation.
STAT_x (x tant un caractre valide quelconque de la sortie de la
commande ps, indiquant un tat de processus non rpertori
ci-dessus)
Linterprtation dune volution dpend ici de la signification de x.
cp dlai requis pour la copie dun fichier de 40 ko
Un accroissement de ce dlai indique lvidence une dgradation du
sous-systme dE/S.
idle_pct_cpu0 pourcentage libre pour le processeur 0
Un accroissement peut indiquer une recrudescence des conflits au
niveau des ressources autres que CPU (pagination ou E/S, par
exemple). Cette tendance mrite attention car elle indique que les
ressources CPU ne sont pas correctement exploites.
idle_pct_avg pourcentage libre moyen pour tous les processeurs
Un accroissement peut indiquer une recrudescence des conflits au
niveau des ressources autres que CPU (pagination ou E/S, par
exemple). Cette tendance mrite attention car elle indique que les
ressources CPU ne sont pas correctement exploites.
12-15
Bote outils PTX

La bote outils PTX (Performance Toolbox for AIX) est un logiciel sous licence qui permet
dafficher graphiquement diverses mesures de performances. Laffichage graphique facilite
grandement la lecture des performances par rapport aux listings de chiffres proposs par
les programmes ASCII quivalents. PTX permet galement de combiner les informations
issues de diffrentes commandes de contrle de performances AIX.
PTX est dcrit en dtail dans Performance Toolbox 1.2 and 2.1 for AIX: Users Guide.
12-16
Diagnostics en fonction dun symptme particulier

Face une anomalie de performance, lanalyste pourra dterminer plus aisment les
causes du problme sil en connat la nature.
Ralentissement dun programme particulier
Ralentissement gnral un moment donn
Ralentissement gnral et imprvisible
Ralentissement des programmes dun utilisateur particulier
Ralentissement simultan de certains systmes du rseau local
En cas de ralentissement gnral intermittent sur une unit ou un service en particulier,
reportez-vous, selon le cas, :
Contrle et optimisation des E/S de communications.
Ralentissement dun programme particulier

Ce cas, apparemment banal, doit cependant tre clairement analys :
Le programme a-t-il toujours fonctionn lentement ?
Sil sagit dun ralentissement rcent, vous devez dterminez quel changement peut en
tre lorigine.
Le code source a-t-il t modifi ou une nouvelle version installe ?
Dans laffirmative, contactez le programmeur ou le fournisseur.
Lenvironnement a-t-il t modifi ?
Si un fichier utilis par le programme (y compris son propre excutable) a t dplac, il
se peut que le programme subisse les retards lis au rseau local ou que des fichiers
sollicitent simultanment un mcanisme daccs sur un seul disque et non sur plusieurs
comme auparavant.
Si ladministrateur systme a modifi les paramtres doptimisation du systme, le
programme peut subir des contraintes quil navait pas auparavant. Par exemple, si le
mode de calcul des priorits a t modifi via la commande schedtune r, les
programmes auparavant rapides en arrire-plan peuvent tre ralentis et ceux en
avant-plan acclrs.
Le programme est-il crit en awk, csh ou dans un autre langage interprtatif ?
Les langages interprtatifs, utiles pour crire rapidement un programme, ne sont pas
optimiss par un compilateur. Par ailleurs, avec un langage de type awk, quelques
caractres suffisent parfois pour demander lexcution doprations extrmement
lourdes en E/S ou en calcul. Il est souvent utile de vrifier ces programmes pas pas ou
de les faire rviser de faon informelle pour mettre en vidence le nombre ditrations
quimplique chaque opration.
Le programme est-il toujours aussi lent ?
Une partie de la mmoire est utilise par le systme de fichiers dAIX pour conserver des
pages de fichiers en vue dun usage ultrieur. Si un programme limit en disque est
excut deux fois de suite de faon trs rapproche, il doit normalement tre plus rapide
la seconde fois que la premire. Un phnomne similaire peut tre observ avec des
12-17
programme exploitant NFS et DFS. Il en est de mme avec de gros programmes, tels
que des compilateurs. Mme si lalgorithme du programme nest pas limit en disque, la
dure de chargement dun excutable volumineux sera plus leve la premire
excution quaux suivantes.
Si le programme a toujours t trs lent ou quaucune modification denvironnement ne
peut justifier son ralentissement, il faut tudier les ressources dont il dpend.
Reportez-vous Identification des ressources limitatives, page 12-23 pour connatre
les techniques de localisation des goulots dtranglement.
Ralentissement gnral un moment donn

Le ralentissement aux heures de pointe est un phnomne bien connu d larrive
massive et habituelle des utilisateurs dune entreprise sur un systme. Mais il ne sagit pas
toujours simplement dun problme de concentration de la charge de travail. Parfois, ce
phnomne peut trahir un dsquilibre qui ne se manifeste pour linstant que lors des
charges lourdes. Dautres sources de ralentissement priodique doivent galement tre
envisages.
Si vous excutez iostat et netstat sur une priode couvrant la dure du ralentissement
(ou que vous avez prcdemment extrait des donnes du dispositif de contrle),
avez-vous constat une utilisation plus intensive de certains disques ? Le pourcentage
de CPU libre est-il rgulirement proche de zro ? Le nombre de paquets envoys ou
reus est-il anormalement lev ?
Si un dsquilibre apparat au niveau des disques, reportez-vous Contrle et
optimisation des E/S disque, page 8-1.
Si la CPU est sature, lancez ps pour identifier les programmes excuts durant cette
priode. Le script prsent Commandes de contrle iostat, netstat et vmstat vous
aidera trouver les sources qui monopolisent la CPU.
Si le ralentissement semble aberrant (paralysie aux heures de repas, par exemple),
assurez-vous quil ne sagit pas dun programme pathologique (tel Graphic Xlock ou un
jeu informatique). Certaines versions de Xlock font un usage boulimique de temps CPU
pour afficher des graphiques sur un cran vide. Il se peut galement quun utilisateur
profite de ce moment opportun pour lancer un programme trs gourmand en CPU.
A moins que votre fichier /var/adm/cron/cron.allow ne soit vide, il nest pas inutile de
vrifier si le rpertoire /var/adm/cron/crontab contient des oprations trs lourdes.
Par exemple, il se peut que des utilisateurs aient demand la sauvegarde de tous les
fichiers de leur rpertoire personnel, toutes les heures, dans un rpertoire mont
sur NFS.
Sil savre que le problme provient dun conflit entre les activits davant-plan et des
programmes longs, trs consommateurs en CPU, excuts (ou appels ltre) en
arrire-plan, lancez schedtune r d pour donner priorit aux activits davant-plan.
Reportez-vous Optimisation du calcul de la priorit des processus avec schedtune,
page 6-23.
Ralentissement gnral et imprvisible

Loutil le mieux adapt ce problme est un dtecteur de surcharge, tel le programme filtd
de xmperf (composant de PTX). Ce programme peut tre configur pour excuter les
scripts shell ou recueillir des informations lorsque certaines conditions sont runies. Vous
pouvez crer votre propre outil selon le mme modle laide de scripts shell contenant les
commandes vmstat, netstat et ps.
Si lincident ne se produit que sur un seul systme dun environnement distribu, il sagit
sans doute dun programme pathologique ou de deux qui interagissent de faon alatoire.
12-18
Ralentissement des programmes dun utilisateur particulier

Parfois, un systme semble avoir dcid de harceler un utilisateur particulier.
Dans ce cas, vous devez tenter de quantifier le problme : demandez lutilisateur
quelles sont les commandes quil a lhabitude dutiliser et excutez-les en association
avec la commande time, comme suit :
$ time cp .profile testjunk
real
0m0.08s
user
0m0.00s
sys
0m0.01s
Puis excutez-les sous un ID utilisateur valide. Le temps rel indiqu sur la ligne real
est-il diffrent ?
Dune excution lautre, un programme consomme normalement peu prs le mme
temps CPU (user+sys), mais il se peut parfois que le temps rel (real) utilis soit
diffrent du fait des oprations E/S, plus nombreuses ou plus lentes. Les fichiers de
lutilisateur sont-il implants sur un rpertoire mont sur NFS ? Ou sur un disque
intensment utilis pour dautres raisons ?
Vrifiez le fichier .profile de lutilisateur : les spcifications $PATH sont peut-tre
tranges. Par exemple, si vous recherchez sans succs une paire de rpertoires monts
sur NFS avant dexplorer /usr/bin, tout sera plus long.
Ralentissement simultan de certains systmes du rseau local

Passer de systmes autonomes des systmes distribus se fait rarement sans difficults :
le peu de temps imparti reconfigurer les systmes et la mconnaissance du cot de
certaines fonctions en sont souvent la cause. Par ailleurs, en plus de loptimisation de la
configuration LAN des MTU et mbuf (voir le chapitre Contrle et optimisation des E/S de
communications), vous devez rechercher les pathologies propres au rseau local et les
lourdeurs rsultant de la combinaison de mesures individuelles, justifies en elles-mmes.
Certains dfauts de logiciels ou de micrologiciels peuvent saturer sporadiquement le
rseau local de paquets de diffusion ou autres.
Lorsque le rseau est inond de paquets de diffusion, mme les systmes qui le
sollicitent peu peuvent tre ralentis par les interruptions incessantes et le temps CPU
consomm par la rception et le traitement des paquets. Les dispositifs danalyse des
rseaux locaux sont plus mme de dtecter et localiser ces dfaillances que les outils
de performances AIX (PTX).
Deux rseaux locaux sont-ils connects via un systme AIX ?
Lutilisation dun systme AIX comme routeur monopolise beaucoup de temps CPU pour
le traitement et la copie des paquets. Des interfrences avec dautres travaux en cours
sur le systme AIX peuvent se produire. La connexion des rseaux locaux via des
ponts et des routeurs matriels ddis est gnralement plus rentable et durable.
Tous les montages NFS sont-ils justifis ?
A un certain stade de dveloppement des configurations distribues, les montages NFS
sont utiliss pour donner aux utilisateurs des nouveaux systmes accs leur rpertoire
personnel sur le systme dorigine. Cette opration simplifie la transition initiale mais
impose un cot de communication de donnes continue. Il arrive que des utilisateurs
dun systme A utilisent essentiellement les donnes dun systme B et vice versa.
Laccs des fichiers via NFS reprsente un cot considrable en terme de trafic LAN,
temps CPU serveur et client et temps de rponse pour lutilisateur final. En principe, il
faut autant que possible que les utilisateurs et les donnes rsident sur le mme
systme. Seule exception cette rgle, les cas o un impratif justifie le cot et le temps
supplmentaire pour des donnes distantes : par exemple, la ncessit de centraliser
12-19
les donnes pour assurer un contrle et une sauvegarde fiable ou encore de sassurer
que tous les utilisateurs travaillent sur la dernire version dun programme.
Si ces impratifs exigent un taux important dchanges client/serveur NFS, il est
prfrable de ddier un systme au rle de serveur plutt que de travailler avec
plusieurs systmes mi-serveurs, mi-clients.
Les programmes ont-ils t correctement ports pour utiliser les appels de procdure
distance RPC (et cela se justifiait-il) ?
Le plus simple pour porter un programme sur un environnement distribu est de
remplacer les appels de programmes par des RPC sur une base 1:1. Mais il faut savoir
que lcart de performances entre des appels de programme locaux et des appels RPC
est encore plus lev que lcart entre les E/S disque locales et les E/S NFS. Ds lors
que les RPC se rvlent indispensables, il est prfrable de les traiter par lots chaque
fois que possible.
Ralentissement gnral intermittent sur une unit ou un service

Assurez-vous que vous avez suivi les recommandations de configuration du guide relatif au
sous-systme en cause et/ou au chapitre Contrle et optimisation concern dans le
prsent manuel.
12-20
Diagnostics laide de PerfPMR

La fonction du module PerfPMR est de complter les comptes rendus danomalies de
performances sous AIX, jusqu ce quils contiennent suffisamment de donnes pour que
BULL puisse tablir un diagnostic. De ce fait, les scripts shell de PermPMR peuvent tre
utiles dautres analystes. PerfPMR est un module en option du BOS (Base Operating
System) dAIX version 4.1. Il se trouve dans /usr/sbin/perf/pmr. Reportez-vous
Installation de PerfPMR dAIX version 4.1. Une version de PerfPMR pour AIX version 3.2.5
est galement disponible (reportez-vous Obtention et installation de PerfPMR (AIX
version 3.2.5)).
perfpmr est le script de plus haut niveau du module, mais les donnes quil collecte (telles
que des informations de configuration) sont gnralement dj connues de lanalyste local.
Le script de plus bas niveau, monitor, se charge de recueillir un ensemble dinformations
coordonnes pendant un intervalle donn (en secondes) et de rsumer ces donnes.
La syntaxe de monitor est :
monitor secondes [n] [p]
Le paramtre secondes doit tre suprieur ou gal 60. Si secondes est infrieur ou gal
600, le compte rendu priodique est gnr toutes les 10 secondes ; sinon, lintervalle est
de 60 secondes. Lindicateur n limine la collecte des donnes netstat et nfsstat.
Lindicateur p limine la collecte des donnes du profil du processus (voir ci-dessous).
Il est dconseill dexcuter le script monitor en mme temps quune opration qui sollicite
lutilitaire de suivi du systme.
Chaque requte monitor cre :
Un fichier monitor.int contenant le rsultat :
des commandes ps elk et ps gv excutes au dbut et la fin de la priode de
contrle (sorties combines),
dune commande sar A avec lintervalle appropri,
dune commande iostat avec lintervalle appropri. Le rapport initial, cumul, est omis.
dune commande vmstat avec lintervalle appropri. Le rapport initial, cumul, est
omis.
Un fichier monitor.sum contenant :
pour les processus actifs en dbut et fin du contrle, les carts entre les valeurs
initiales et finales des statistiques dutilisation des ressources,
les lignes Average issues de la sortie de la commande sar A,
la moyenne des statistiques de lintervalle iostat,
la moyenne des statistiques de lintervalle vmstat,
lcart entre les statistiques avant/aprs gnres par la commande vmstat s.
Si loption n nest pas spcifie, un fichier netstat.int contenant :
la sortie en dbut de contrle des commandes :
netstat v
netstat m
netstat rs
netstat s
la sortie dune commande netstat avec lintervalle appropri,
la sortie en fin de contrle des commandes :
12-21
netstat v
netstat m
netstat rs
netstat s
Si loption n nest pas spcifie, un fichier nfsstat.int contenant :
la sortie en dbut et fin de contrle dune commande nfsstat csnr.
Si loption p nest pas spcifie, deux fichiers, Pprof.stt et Pprof.flow. Pprof.stt,
contiennent les heures de dbut et de fin de lexcution. Pprof.flow contient les donnes
du profil du processus. Les colonnes du fichier Pprof.flow sont :
a. Nom du processus
b. ID processus
c. Heure de la premire occurrence du processus dans lintervalle de mesure
d. Heure de la dernire occurrence du processus
e. Temps dexcution total du processus
f. Indicateurs Begin/End (la somme des deux est donne plus loin). Indique ltat du
processus en dbut et fin dexcution :
Begin:
execed:
forked:
Alive at Start:
End:
Alive at end:
execed away:
Exited:
0
1
2
0
4
8
g. ID processus parent
Contrle avant modification

Une des fonctions les plus utiles de PerfPMR est de crer une ligne de base de la
configuration et des performances avant toute modification logicielle ou matrielle
significative. Comme vous le faites pour les fichiers critiques, vous devez sauvegarder les
configurations et leurs performances : si vous constatez une dgradation des performances,
vous disposez alors de toutes les donnes utiles pour analyser prcisment la situation
avant et aprs modification.
Pour obtenir les donnes les plus compltes possibles, excutez :
$ perfpmr 3600
au cours de lheure la plus charge de la journe. Les fichiers rsultants de cette mesure se
trouvent dans le rpertoire /var/perf/tmp. (Si vous exploitez un systme antrieur la
version 4, les fichiers rsultants se trouvent dans le rpertoire de travail courant.) Veillez
placer ces fichiers dans un endroit sr avant toute modification.
12-22
Identification des ressources limitatives

Aperu des performances du systme
Dtermination du facteur limitatif sur un programme
Disque ou mmoire
Aperu des performances du systme

Le meilleur outil pour avoir une vue densemble de lutilisation des ressources dans un
environnement multi-utilisateur est sans doute la commande vmstat. La commande vmstat
rend compte de lactivit de la CPU et des E/S disque, ainsi que les donnes dutilisation de
la mmoire. La commande
$ vmstat 5
commande vmstat dcrire une ligne de rapport sur lactivit du systme toutes les
5 secondes. Aucun compte nayant t spcifi la suite de cet intervalle, la gnration des
rapports se poursuit jusqu annulation de la commande.
Le relev vmstat ci-dessous concerne un systme excutant AIXwindows et plusieurs
applications associes (certains intervalles de faible activit ont t supprims) :
procs
r b
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 1
0 1
0 0
memory
page
faults

avm
fre re pi po fr
sr cy in
sy cs
8793
81
0
0
0
1
7
0 125
42 30
8793
80
0
0
0
0
0
0 155 113 79
8793
57
0
3
0
0
0
0 178
28 69
9192
66
0
0 16 81 167
0 151
32 34
9193
65
0
0
0
0
0
0 117
29 26
9193
65
0
0
0
0
0
0 120
30 31
9693
69
0
0 53 100 216
0 168
27 57
9693
69
0
0
0
0
0
0 134
96 60
10193
57
0
0
0
0
0
0 124
29 32
11194
64
0
0 38 201 1080
0 168
29 57
11194
63
0
0
0
0
0
0 141 111 65
5480
755
3
1
0
0
0
0 154 107 71
5467 5747
0
3
0
0
0
0 167
39 68
4797 5821
0 21
0
0
0
0 191 192 125
3778 6119
0 24
0
0
0
0 188 170 98
3751 6139
0
0
0
0
0
0 145
24 54
cpu
us sy id wa
1 2 95 2
14 8 78 0
1 12 81 6
1 6 77 16
1 3 96 0
1 3 95 0
1 4 63 33
12 4 84 0
1 3 94 2
2 8 62 29
12 7 81 0
13 8 78 2
1 16 79 5
20 5 42 33
5 8 41 46
1 10 89 0
Les colonnes pertinentes pour lvaluation initiale sont les colonnes pi et po dans page et
les quatre colonnes de la rubrique cpu.
Les entres pi et po correspondent respectivement aux chargements et aux
dchargements de page dans lespace de pagination. Si une E/S dans lespace de
pagination se produit, la charge de travail approche (voire dpasse) les limites de
mmoire du systme.
Si la somme des taux dutilisation de CPU us et sy (utilisateur et systme) excde 80 %
dans un intervalle donn de 5 secondes, la charge de travail sapproche des limites CPU
du systme pendant cet intervalle.
Un pourcentage dattente des E/S (wa) non nul (colonnes pi et po zro) signifie quun
certain temps dattente est marqu sur les E/S de fichiers non coordonnes et quune
partie de la charge de travail est limite en E/S.
Sapprocher des limites signifie quune partie de la charge subit un ralentissement du fait
dune ressource critique. Lallongement des temps de rponse nest peut-tre pas
subjectivement significatif, mais tout supplment de charge ce niveau entranera une
dtrioration rapide des performances.
12-23
Si vmstat signale un temps dattente des E/S important, excutez iostat pour disposer
dinformations plus dtailles. La commande
$ iostat 5 3
commande iostat dtablir toutes les 5 secondes un bref relev des E/S et de lactivit de
la CPU. Le chiffre 3 final indique de gnrer trois relevs.
Le relev iostat ci-dessous concerne un systme dot de la mme charge de travail que
dans lexemple prcdent (vmstat), mais un autre moment. Le premier relev fournit le
cumul dactivit depuis le dernier amorage, et les suivants, lactivit au cours de lintervalle
de 5 secondes qui prcde :
tty:
tin
0.0
Disks:
hdisk0
hdisk1
hdisk2
cd0
tty:
% tm_act
0.0
0.0
0.4
0.0
tin
0.0
Disks:
hdisk0
hdisk1
hdisk2
cd0
tty:
tout
4.3
tout
30.3
% tm_act
0.2
0.0
0.0
0.0
tin
0.0
Disks:
hdisk0
hdisk1
hdisk2
cd0
cpu:
% user
0.2
Kbps
0.2
0.0
1.5
0.0
cpu:
Kbps
0.8
0.0
0.0
0.0
tout
8.4
cpu:
% tm_act
0.0
0.0
98.4
0.0
Kbps
0.0
0.0
575.6
0.0
% sys
% idle
% iowait
0.6
98.8
0.4
tps
0.0
0.0
0.3
0.0
% user
8.8
tps
0.2
0.0
0.0
0.0
% user
0.2
tps
0.0
0.0
61.9
0.0
msps
% sys
7.2
msps
% sys
5.8
msps
Kb_read
7993
2179
67548
0
% idle
83.9
Kb_read
4
0
0
0
Kb_wrtn
4408
1692
59151
0
%iowait
0.2
Kb_wrtn
0
0
0
0
% idle
% iowait
0.0
93.8
Kb_read
0
0
396
0
Kb_wrtn
0
0
2488
0
Le premier relev rvle un dsquilibre au niveau des E/S : la plupart (86,9 % de kilooctets
en lecture contre 90,7 % en criture) concernent le disque hdisk2 qui contient le systme
dexploitation et lespace de pagination. Lutilisation cumule de la CPU depuis le dernier
amorage nest gnralement significative que sur un systme exploit 24 h sur 24.
La second relev indique un faible volume de lecture sur le disque hdisk0, qui contient un
systme de fichiers distinct, rserv lutilisateur principal du systme. Lactivit CPU
provient de deux programmes dapplication et de la commande iostat elle-mme. La sortie
de iostat, bien que non volumineuse, est rachemine vers un fichier, le systme ntant
pas suffisamment limit en mmoire pour forcer une sortie pendant cet intervalle.
Dans le troisime relev, des conditions proches de lemballement ont t cres, par
lexcution dun programme qui affecte et remplit un volume important de mmoire
(ici, environ 26 Mo). hdisk2 est actif 98,4 % du temps, ce qui entrane une attente E/S de
93,8 %. Le fait quun seul programme monopolise plus des trois-quarts de la mmoire
systme (32 Mo) et provoque lemballement du systme met en vidence les limites du
contrle de charge mmoire VMM, page 2-10. Mme dans le cas dune charge plus
homogne, la capacit mmoire requise pour chaque lment doit tre bien analyse.
Si vmstat indique quune quantit importante de temps CPU est disponible alors que le
systme donne des signes de ralentissement, il se peut que vous soyez confront des
retards causs par des conflits de verrouillage dans le noyau. Sous AIX version 4.1, ce
phnomne peut tre tudi laide de la commande lockstat si Performance Toolbox est
install sur votre systme.
12-24
Dtermination du facteur limitatif sur un programme

Si vous tes lunique utilisateur dun systme, vous pouvez, via la commande time,
dterminer si un programme est ou non dpendant des E/S et de lutilisation de la CPU :
$ time cp foo.in foo.out
real
user
sys
0m0.13s
0m0.01s
0m0.02s
Remarque : Les exemples de commande time proposs dans ce manuel utilisent la

version intgre au shell Korn. La commande time officielle (/usr/bin/time) gnre,
entre autres inconvnients, un relev moins dtaill.
Dans cet exemple, le fait que le temps rellement coul pour lexcution de cp
(0,13 seconde) soit bien suprieur la somme (0,03 seconde) des temps dutilisation CPU
utilisateur et systme, indique que le programme est limit en E/S. Ceci se produit
principalement parce que foo.in na pas fait lobjet dune lecture rcente. La mme
commande, excute sur le mme fichier quelques secondes plus tard, indique :
real
user
sys
0m0.06s
0m0.01s
0m0.03s
La plupart (voire la totalit) des pages de foo.in sont encore en mmoire car aucun
processus nest intervenu pour les rclamer et, par ailleurs, la taille du fichier est minime,
compare la capacit RAM du systme. Un petit fichier foo.out serait galement plac
en mmoire et un programme qui lutiliserait en entre serait peu dpendant du disque.
Pour dterminer la dpendance dun programme vis--vis du disque, vrifiez ltat de
donnes en entre : si le programme doit normalement tre excut sur un fichier qui na
pas t rcemment utilis, assurez-vous que le fichier test ne se trouve pas en mmoire.
Sil sagit, linverse, dun programme normalement excut dans une squence standard,
et quil prend en entre la sortie du programme prcdent, il vous faut prparer la mmoire
pour garantir lexactitude de la mesure. Par exemple :
$ cp foo.in /dev/null
prpare la mmoire en lui intgrant les pages de foo.in.
La situation est plus complexe si la taille du fichier est grande par rapport la capacit
RAM. Si la sortie dun programme est reprise en entre par le suivant et que la totalit du
fichier ne loge pas dans la RAM, le second programme terminera la lecture des pages en
dbut de fichier, dplaant les pages la fin. Ces conditions, trs difficiles reproduire
artificiellement, quivalent grosso modo une situation dans laquelle aucune mise en
cache na lieu sur le disque.
Le cas particulier dun fichier de taille suprieure celle de la RAM est trait dans la section
suivante.
Disque ou mmoire ?
De mme quune part importante de la mmoire relle est rserve la mise en tampon
des fichiers, lespace de pagination du systme est utilis comme mmoire temporaire pour
les donnes actives dun programme qui ont t expulses de la RAM. Supposons quun
programme lise peu ou pas de donnes et prsente nanmoins des symptmes de
dpendance visvis des E/S. Pire, le ratio de temps rel par rapport au temps utilisateur
+ systme ne samliore pas au cours des excutions successives. On peut en conclure
que ce programme est probablement limit en mmoire et que ses E/S sont destines
lespace de pagination (do elles proviennent probablement). Pour le vrifier, vous pouvez
utiliser le script shell vmstatit ci-dessous. Le script shell vmstatit rsume le
volumineux compte rendu gnr par vmstat s, qui indique les dcomptes cumuls de
certaines activits systme depuis son lancement :
12-25
vmstat s >temp.file
# cumulative counts before the command
time $1
# command under test
vmstat s >>temp.file # cumulative counts after execution
grep pagi.*ins temp.file >>results
# extract only the data
grep pagi.*outs temp.file >>results # of interest
Si le script shell est excut comme suit :

$ vmstatit cp file1 file2
2>results
le rsultat donn dans results est :

real
user
sys
0m0.03s
0m0.01s
0m0.02s
2323 paging
2323 paging
4850 paging
4850 paging
space
space
space
space
page
page
page
page
ins
ins
outs
outs
Le fait que les donnes statistiques de pagination avant/aprs soient identiques nous
conforte dans lide que la commande cp nest pas limite en pagination. Une variante plus
complte du script shell vmstatit peut tre utilise pour reflter la situation relle :
vmstat s >temp.file
time $1
vmstat s >>temp.file
echo Ordinary Input:
grep ^[ 09]*page ins
echo Ordinary Output:
grep ^[ 09]*page outs
echo True Paging Output:
grep pagi.*outs
echo True Paging Input:
grep pagi.*ins
>>results
temp.file >>results
>>results
temp.file >>results
>>results
temp.file >>results
>>results
temp.file >>results
Toutes les E/S ordinaires effectues sous AIX tant traites via VMM, la commande
vmstat s rend compte des E/S ordinaires de programmes en termes de chargement/
dchargement de pages. La version ci-dessus du script shell vmstatit applique la
commande cp sur un gros fichier qui na pas t rcemment utilis, gnre :
real
0m2.09s
user
0m0.03s
sys
0m0.74s
Ordinary Input:
46416 page ins
47132 page ins
Ordinary Output:
146483 page outs
147012 page outs
True Paging Output:
4854 paging space
4854 paging space
True Paging Input:
2527 paging space
2527 paging space
page outs
page outs
page ins
page ins
La sortie de la commande time confirme lexistence dune dpendance visvis des E/S.
Laccroissement des page ins indique les E/S requises pour satisfaire la commande cp.
Laccroissement des page outs indique que le fichier est suffisamment volumineux pour
forcer lcriture des pages modifies (pas ncessairement les siennes) partir de la
mmoire. La constance du nombre cumul dE/S dans lespace de pagination confirme que
les structures de donnes construites par la commande cp ne sont pas suffisamment
tendues pour surcharger la mmoire de la machine test.
Lordre des E/S dans cette version du script shell vmstatit a son importance. En gnral,
les programmes lisent les entres dun fichier puis en crivent la sortie. Mais dans le
12-26
processus de pagination, la page de segment actif qui ne peut tre accueillie est dabord
dcharge (crite lextrieur) : elle nest charge (lue) que lorsque le programme tente dy
accder. Sur le systme test, le dsquilibre entre le nombre de dchargements
(paging space page outs) et le nombre presque deux fois moindre de chargements
(paging space page ins) depuis le dernier amorage rvle que certains programmes
ont stock en mmoire des donnes qui nont pas t rutilises jusqu la fin du
programme. programmes CPU limite, page 4-20 donne davantage dinformations.
Reportez-vous galement Contrle et optimisation de la mmoire, page 7-1.
Lexemple ci-dessous illustre limpact de la limitation de mmoire sur les statistiques : une
commande donne est excute dans un environnement dot de suffisamment de mmoire
(32 Mo), puis la taille du systme est rduite via une commande rmss (reportez-vous
Estimation de la mmoire requise via rmss, page 7-6). La squence de commandes :
$ cc c ed.c
$ vmstatit cc c ed.c 2>results
prpare dans un premier temps la mmoire en lui intgrant le fichier source de 7 944 lignes
et lexcutable du compilateur C puis mesure lactivit E/S de la seconde excution :
real
0m7.76s
user
0m7.44s
sys
0m0.15s
Ordinary Input:
57192 page ins
57192 page ins
Ordinary Output:
165516 page outs
165553 page outs
True Paging Output:
10846 paging space
10846 paging space
True Paging Input:
6409 paging space
6409 paging space
page outs
page outs
page ins
page ins
Il ny a visiblement pas de limitation au niveau des E/S. Mme pour lire le code source,
aucune E/S nest requise. Si vous excutez la commande :
# rmss c 8
pour ramener 8 Mo la taille effective de la machine et que vous rptez la mme
squence de commandes, vous obtenez :
real
0m9.87s
user
0m7.70s
sys
0m0.18s
Ordinary Input:
57625 page ins
57809 page ins
Ordinary Output:
165811 page outs
165882 page outs
True Paging Output:
11010 paging space
11061 paging space
True Paging Input:
6623 paging space
6701 paging space
page outs
page outs
page ins
page ins
Cette fois, les symptmes dE/S limites apparaissent :

le temps coul est suprieur au temps CPU total,
le nombre dE/S ordinaires la nime excution est considrable.
12-27
Ces deux symptmes signalent que le manque de mmoire entrave lexcution du

compilateur.
Remarque : Cet exemple illustre les effets dune insuffisance de mmoire. Aucun effort
particulier na t fait pour minimiser lutilisation de la mmoire par les autres processus,
la taille absolue impose au compilateur pour charger cet environnement nest donc pas
une mesure pertinente.
Pour ne pas tre contraint de travailler sur une machine artificiellement rduite en taille
jusqu la prochaine relance, excutez :
# rmss r
Cette commande restitue au systme dexploitation la mmoire confisque par la
commande rmss et redonne ainsi au systme sa capacit normale.
12-28
Gestion de la charge de travail

Si vous avez puis toutes les possibilits doptimisation du systme et des programmes
sans parvenir un niveau de performances satisfaisant, il vous reste trois solutions :
vous contenter de ce niveau de performances,
mettre niveau la ressource limitative,
prendre des mesures de gestion de la charge.
Si vous optez pour la premire solution, vous risquez de dmotiver vos utilisateurs les
moins stoques force de frustration. Si vous optez pour la seconde solution, il y aura
toujours quelquun pour vous demander des comptes sur cette dpense supplmentaire.
Et il vous faudra prouver que vous avez puis toutes les autres possibilits sur le systme
courant. Bref, il ne vous reste plus que la troisime solution : la gestion de la charge.
Grer la charge de travail signifie simplement en analyser les lments pour valuer leur
degr durgence. Tous les travaux nont en effet pas la mme priorit : ce rapport est utile
quil soit excut 3 heures du matin ou 16 heures la veille. La diffrence est qu
3 heures du matin, les cycles CPU quil utilise seraient sinon inexploits. Pour excuter un
programme une heure dtermine ou intervalles rguliers, vous disposez des
commandes at et crontab.
De mme, certains programmes devant tre excuts dans la journe peuvent tre assortis
dune priorit rduite : leur excution prendra plus de temps, mais la comptition avec les
processus rellement urgents sera moindre.
Une autre mthode, drive de la premire, consiste transfrer le travail dune machine
une autre, pour excuter, par exemple, une compilation sur la machine o rside le code
source. Cet quilibrage de la charge exige davantage de planification et de contrle :
rduire la charge sur le rseau et augmenter la charge CPU sur un serveur est une
opration qui, mal matrise, peut se solder par une perte nette.
12-29
12-30
Chapitre 13. Gestion dun possible dfaut de

performance AIX
Si vous pensez avoir dtect un dfaut au niveau des performances dAIX, vous disposez
doutils et de procdures pour faire part du problme et fournir les donnes permettant de
lanalyser. Outils et procdures sont conus pour vous donner une solution aussi prcise et
rapide que possible avec un minimum deffort et de temps de votre part.
Cette rubrique traite des points suivants :
Base de mesure
Compte rendu du problme
Obtention et installation de PerfPMR (AIX version 3.2.5)
Installation de PerfPMR partir du Web (inclut la version 4)
Donnes danalyse
Base de mesure
Les problmes de performance apparaissent souvent immdiatement aprs une
modification du systme, matrielle ou logicielle. A moins quune mesure pr-modification
nait t effectue, base possible de comparaison des performances avant/aprs,
quantifier le problme est impossible. Seule la collecte dinformations exhaustives sur la
configuration et les performances via le module PerfPMR permet une analyse efficace.
Reportez-vous Contrle avant modification.
Disposer de loutil PDT (Performance Diagnostic Tool) install et oprationnel est galement
utile pour tudier lensemble des performances du systme.
Compte rendu du problme

Vous devez rendre compte des problmes suspects au niveau des performances AIX au
service BULL comptent. Pour ce faire, passez par votre canal habituel. Si vous ntes pas
familier de ce type dopration, consultez votre reprsentant BULL.
Au moment de ce rapport, vous devez fournir les informations suivantes :
Une description du problme qui permette dexplorer la base dincidents pour dterminer
si un problme de ce type a dj t signal.
Quel aspect de votre analyse vous a conduit penser quAIX tait en cause ?
Dans quelle configuration matrielle/logicielle avez-vous rencontr ce problme ?
Le problme est-il limit un seul systme, ou en affecte-t-il plusieurs ?
Quels sont le modle, la taille mmoire et le nombre et la taille des disques des
systmes en cause ?
Quels types de rseaux locaux et de supports de communications sont connects
au(x) systme(s) ?
La configuration comporte-t-elle des systmes non-AIX ? Non-UNIX ?
Quelles sont les caractristiques du programme ou du travail rencontrant le problme ?
Gestion dun possible dfaut de performance AIX
13-1
Une analyse avec time, iostat et vmstat indique-t-elle une limitation de CPU ou
dE/S ?
Les travaux sont-ils excuts sur : station de travail, serveur, multi-utilisateur ou un
panachage de ces types de systme ?
Quels sont les objectifs non atteints ?
Lobjectif principal est-il dfini en termes de temps de rponse du terminal ou de la
console, du dbit ou des rponses en temps rel ?
Les objectifs ont-ils t fixs sur la base de mesures effectues sur un autre systme
AIX ? Si oui, quelle en est la configuration ?
Si lincident est signal pour la premire fois, vous vous verrez attribuer un numro de
rfrence PMR ( indiquer lors de tout renseignement complmentaire).
Vous serez probablement invit fournir des donnes pour aider BULL analyser le
problme. Pour les collecter, BULL fournit un module doutils, appel PerfPMR.
Sous AIX version 3.2.5, il sagit dun outil informel disponible auprs de votre reprsentant
BULL. Sous AIX version 4.1, PerfPMR est un module installable en option, fourni sur le
support du systme dexploitation de base (BOS) AIX.
Obtention et installation de PerfPMR (AIX version 3.2.5)

Procurez-vous une copie de PerfPMR AIX version 3.2.5 auprs de votre reprsentant
BULL.
Pour installer PerfPMR :
1. Connectez-vous en tant quutilisateur root ou passez par la commande su pour en
obtenir les droits.
2. Crez le rpertoire perfpmr et passez-y (cet exemple suppose que le rpertoire est cr
sous /tmp).
# cd /tmp
# mkdir perfpmr
# cd perfpmr
3. Copiez le fichier tar compress partir de la disquette (cet exemple suppose que lunit
de disque utilise est fd0) :
# tar xvf/dev/fd0 perfpmr.tarbinz
4. Renommez le fichier tar :
# mv perfpmr.tarbinz perfpmr.tarbin.Z
5. Dcompressez le fichier tar :
# uncompress perfpmr.tarbin.Z
6. Rcuprez les scripts shell du fichier tar :
# tar xvf perfpmr.tarbin
7. Installez les scripts shell :
# ./Install
13-2
Installation de PerfPMR partir du Web (inclut la version 4)

Pour obtenir la bonne version de PerfPMR, visitez notre site Web ladresse
www.ibm.com. Saisissez perfpmr dans la zone de texte Search et appliquez la recherche
lensemble du site (All of IBM). Le rsultat de la recherche apparat dans une fentre
ayant pour titre AIX Performance PMR Data Collection Scripts perfpmr. Cliquez sur le
bouton de tlchargement pour tranfrer les fichiers depuis le site FTP contenant PerfPMR.
Plusieurs versions de PerfPMR sont rpertories (perf32, perf41, perf42 et perf43 par
exemple).
Chaque dossier contient :
fichier perfxx.tar.Z
Fichier tar compress contenant PerfPMR
message
Description du contenu
license.agreement
Accord de licence international BULL
readme
Instructions sur lobtention et linstallation de PerfPMR, la

collecte des donnes et lenvoi de ces donnes BULL
Pour installer PerfPMR partir du Web :

1. Tlchargez la bonne version de PerfPMR dans le rpetoire /tmp
2. Connectez-vous en tant quutilisateur root ou utilisez la commande su pour en obtenir
les droits.
3. Crez le rpertoire perf41 (par exemple) et passezy
# mkdir /tmp/perf41
# cd /tmp/perf41
4. Rcuprez les scripts shell du fichier tar compress :
# zcat /tmp/perf41.tar.Z | tar xvf
5. Installez les scripts shell :

# sh ./Install
Le processus dinstallation place le module PerfPMR dans le rpertoire /usr/sbin/perf/pmr.

Le module occupe environ 200 ko despace disque.
Donnes danalyse
Tous les lments suivants doivent tre intgrs aux informations fournies au service de
maintenance, lors de la premire collecte :
Un moyen de reproduire le problme
Si possible, joignez un programme ou un script shell illustrant le problme
A dfaut, dcrivez prcisment les conditions sous lesquelles a eu lieu le problme.
Les donnes collectes par les outils PerfPMR
Sur chaque systme concern
Au mme moment
Pendant loccurrence du problme.
13-3
Lapplication mise en cause par le problme

Si lapplication est un produit logiciel (ou en dpend), indiquez-en la version et la
rvision exactes, mme sil ne sagit pas dun produit BULL.
Si le code source de lapplication a t cr par un utilisateur, indiquez lensemble
complet des paramtres du compilateur ayant servi crer lexcutable.
Capture des donnes

Pour capturer et conditionner les donnes sous une forme exploitable, excutez les tapes
suivantes sur chacun des systmes concerns. Si possible, excutez ltape 6
simultanment (ou presque) sur tous les systmes.
1. Connectez-vous en tant quutilisateur root ou utilisez la commande su pour en obtenir
les droits.
2. PerfPMR capture davantage dinformations si les outils tprof, filemon et netpmon sont
disponibles. Sous AIX version 4.1, ils sont fournis comme lment de la bote outils
Performance Toolbox for AIX. Pour dterminer si ces outils ont t installs, entrez :
$ lslpp lI perfagent.tools
Si ce module est install, les outils sont disponibles.
3. Vrifiez que la variable PATH inclut le rpertoire contenant les excutables PerfPMR.
Sous AIX version 4.1, ajoutez /usr/sbin/perf/pmr PATH. Par exemple :
# echo $PATH
/usr/bin:/etc:/usr/local/bin:/usr/ucb:.:
# PATH=$PATH:/usr/sbin/perf/pmr:
# export PATH
Sous la version 3, ajoutez PATH le rpertoire sous lequel vous avez install PerfPMR
( la place de /usr/sbin/perf/pmr) et le rpertoire des outils de performance,
/usr/lpp/bosperf.
4. Sous la version 4, la sortie de perfpmr est crite dans /var/perf/tmp. Sous la version 3,
vous devez :
a. Passer (via cd) un rpertoire adquat, tel /tmp, dans un systme de fichiers
disposant dau moins 5 Mo despace libre.
b. Crer un sous-rpertoire pour les donnes et y passer :
# mkdir perfdata
# cd perfdata
13-4
5. Surveillez lactivit systme pendant 1 heure :

# perfpmr 3600
(dans la version 3, perfpmr sappelle perfpmr.sh.)
6. Fusionnez les fichiers en un seul fichier tar compress :
# cd ..
# tar cvf numro-pmr.tarbin.perfdata
# compress numro-pmr.tarbin
numro-pmr tant le numro affect au PMR par le service logiciel.
7. Transfrez le fichier sur une disquette (ou un autre volume portable) via, par exemple :
# tar cvf /dev/fd0 numro-pmr.tarbin.Z
8. tiquetez le volume portable en indiquant :
le numro PMR
la date de collecte des informations
la commande et les indicateurs requis pour extraire les donnes du volume portable,
par exemple :
# tar xvf /dev/fd0
Envoyez les donnes au service de maintenance logicielle.
13-5
13-6
Annexe A. Commandes de contrle et doptimisation

des performances AIX
Les outils relatifs aux performances dans lenvironnement AIX relvent de lune des deux
catgories suivantes : informations sur le cours des vnements ou moyens daction sur
ces vnements. Peu participent des deux catgories. Cette annexe rcapitule les
commandes relatives aux performances. Nombre dentre elles sont dcrites dans les
chapitres traitant de loptimisation daspects spcifiques du systme. Pour la majorit, vous
trouverez le dtail de leur fonction et leur syntaxe dans le manuel AIX Commands
Reference. Les commandes schedtune, pdt_config, pdt_report et vmtune sont dcrites
plus avant dans cette annexe.
Certaines des commandes relatives aux performances sont fournies comme partie de la
bote outils Performance Toolbox for AIX (PTX), et non du systme dexploitation de base
AIX. Ces commandes sont identifies par (PTX). Pour dterminer si les outils PTX sont
installs, entrez :
$ lslpp lI perfagent.tools
Si le module est affich AVAILABLE, les outils PTX sont exploitables.
Les listes suivantes rcapitulent les commandes relatives aux performances :
Commandes de compte rendu et danalyse des performances
Commandes doptimisation, page A-3
Commandes de compte rendu et danalyse des performances

Ces outils donnent des indications sur les performances dun ou plusieurs lments du
systme, ou sur un ou plusieurs des paramtres ayant une incidence sur les performances.
Commande
Fonction
bf, bfrpt
Fournit des rapports dtaills sur les trames daccs mmoire des
applications.
emstat
Rend compte des comptes dinstructions dmulation.
filemon
Consigne, via lutilitaire de suivi, lactivit E/S des volumes physiques,

des volumes logiques, des fichiers individuels et du gestionnaire VMM
fileplace
Affiche lemplacement physique ou logique des blocs constitutifs dun

fichier, lintrieur du volume physique ou logique dans lequel ils
rsident.
gprof
Rend compte du flux de contrle au travers des sous-routines dun

programme et du temps CPU consomm par chaque sous-routine.
iostat
Affiche lutilisation des donnes par :

Terminaux
CPU
Disques
lockstat
Affiche des informations relatives aux confits de verrouillage du noyau.
Commandes de contrle et doptimisation des performances AIX
A-1
lsattr
Affiche les attributs ayant une incidence sur les performances, tels que :
La taille des caches
La taille de la mmoire relle
Le nombre maximal de pages dans le cache tampon dE/S bloc
Le nombre maximal de kilo-octets de mmoire autoriss pour les
mbuf
Les niveaux haut et bas de la rgulation des E/S disque.
lslv
Affiche des informations sur un volume logique.
netpmon
Rend compte de lactivit rseau via lutilitaire de suivi :

Consommation CPU
Dbits de donnes
Dlais de rponse.
netstat
Affiche des informations et des statistiques diverses sur les

communications, telles que :
Ltat actuel du pool mbuf
Les tables de routage
Des statistiques cumules sur lactivit du rseau.
nfso
Affiche (ou modifie) les valeurs des option NFS.
nfsstat
Affiche des statistiques sur lactivit client et serveur NFS (Network File
System) et RPC (Remote Procedure Call).
no
Affiche (ou modifie) les valeurs des options rseau, telles que :
Tailles par dfaut des tampons socket denvoi et de rception
Quantit maximale de mmoire utilise dans le pool mbuf et les
pools de grappe.
pdt_config
Lance, arrte ou modifie les paramtres de PDT (Performance

Diagnostic Tool).
pdt_report
Gnre un rapport PDT sur la base des donnes historiques actuelles.
ps
Affiche des statistiques et des informations dtat sur les processus du

systme :
ID processus
Activit E/S
Utilisation de CPU
sar
Affiche des statistiques sur les activits du systme dexploitation :

Accs aux rpertoires
Appels systme de lecture et dcriture
Duplications et excutions
Pagination.
schedtune
A-2
Affiche (ou modifie) la valeur des paramtres de contrle de charge de

la mmoire VMM, la dure des tranches horaires CPU et lintervalle de
ressai dune opration nayant pas abouti suite une insuffisance
despace de pagination.
smit
Affiche (ou modifie) les paramtres de gestion du systme.
stem
Prend en charge linstrumentation des entres et sorties des

programmes excutables, sans accs au code source de lexcutable.
svmon
Indique ltat de la mmoire aux niveaux systme, processus et

segment.
syscalls
Enregistre et compte les appels systme.
time
Imprime le dlai coul et le temps CPU utilis par lexcution dune

commande.
tprof
Consigne, via lutilitaire de suivi, la consommation de CPU par les

services de noyau, les sous-routines de bibliothque, les modules de
programmes dapplication et des lignes isoles de code source du
programme dapplication.
trace
Ecrit un fichier qui retrace la squence exacte des activits du systme.
vmstat
Affiche des donnes VMM :

Nombre de processus en attente ou susceptibles dtre diffuss
Taille de la liste de trames de page disponibles
Activit de dfaut de page
Utilisation de CPU.
vmtune
Affiche (ou modifie) les paramtres de lalgorithme de remplacement de

page VMM (Virtual Memory Manager).
Commandes doptimisation
Les outils suivants permettent de modifier un ou plusieurs lments lis aux performances
du systme.
Commande
Fonction
fdpr
Optimise des fichiers excutables pour une charge de travail donne.
nfso
Affiche (ou modifie) les valeurs des option NFS.
nice
Excute une commande selon une priorit spcifie.
no
Affiche (ou modifie) les valeurs des options rseau.
renice
Modifie la priorit des processus en cours.
reorgvg
Rorganise les lments dun groupe de volume.
rmss
Rduit temporairement la taille de RAM effective dun systme pour

valuer les performances probables dun travail sur une machine plus
petite ou pour vrifier la taille de mmoire requise par un lment dun
travail.
schedtune
Affiche (ou modifie) la valeur des paramtres de contrle de charge de

la mmoire VMM, la dure des tranches horaires CPU et lintervalle de
ressai dune opration nayant pas abouti suite une insuffisance
A-3
smit
Affiche (ou modifie) les paramtres de gestion du systme.
vmtune
Affiche (ou modifie) les paramtres de lalgorithme de remplacement de

page VMM (Virtual Memory Manager).
Voir aussi
Commandes : gnralits dans AIX 4.3 Guide de lutilisateur : systme dexploitation et
units explique comment interprter les diagrammes de syntaxe.
A-4
Commande emstat
Objet
Rend compte des comptes des instructions mules.
Syntaxe
emstat [ Interval ] [ Count ]
Description
La commande emstat fournit des statistiques sur le nombre dinstructions que le systme
doit muler. Ce dcompte est utilis pour dterminer si une application doit tre recompile
pour liminer les instructions qui doivent tre mules sur les processeurs PowerPC 601 ou
PowerPC 604. Une instruction qui doit tre mule requiert davantage de cycles CPU
quune instruction qui ne doit pas ltre.
Si une application a t compile sous AIX version 3, elle peut contenir des instructions non
disponibles sur les processeurs 601 ou 604. Le 601 est dots de la majorit des instructions
POWER ; il lui en manque environ cinq, rarement excutes : les problmes sont donc
exceptionnels. Par contre, il manque environ 35 instructions POWER au processeur 604 :
les chances dmulation sont plus leves.
Ce phnomne dinstruction mule se produit avec des applications qui nont t
compiles en mode commun sous AIX version 3 et sont excutes sur un processeur 601
ou 604 sans recompilation pralable. Si lapplication a t compile sous AIX version 4.1,
loption de compilation par dfaut est common, aussi seules des instructions communes
tous les processeurs sont intgrs lexcutable. Les instructions mules peuvent
galement apparatre sur un processeur 601 ou 604 si une application a t compile pour
une architecture spcifique, POWER ou POWER2, par exemple.
La solution est de recompiler lapplication, sous AIX version 4.1 ou sous AIX version 3.2.5,
en spcifiant loption qarch=com. Pour effectuer une compilation en mode commun sous
AIX version 3.2.5, il vous faut un APAR qui introduise ce code commun.
Le paramtre Interval spcifie le dlai (en secondes) entre chaque compte rendu. Le
premier compte rendu contient des statistiques concernant la dure coule depuis le
lancement du systme. Les comptes rendus suivants contiennent des statistiques
collectes au cours de lintervalle coul depuis le compte rendu prcdent. Si vous ne
spcifiez pas le paramtre Interval, la commande emstat gnre un seul rapport, puis
quitte.
Le paramtre Count ne peut tre spcifi quassoci au paramtre Interval. Sil est spcifi,
le paramtre Count dtermine le nombre de rapports gnrs. Si le paramtre Interval est
spcifi sans le paramtre Count, les rapports sont gnrs en continu. Le paramtre
Count ne peut tre affect de la valeur 0.
Sortie
La premire colonne est le nombre total dinstructions mules depuis le dernier
ramorage du systme. La deuxime colonne est le nombre dinstructions mules
pendant lintervalle spcifi.
A-5
Commande schedtune
Objet
Dfinit les paramtres de traitement du programmateur de CPU et du gestionnaire VMM
Syntaxe
schedtune
D
d n
e n
f n
h n
m n
p n
r n
t n
w n
schedtune [ D | { [ d n ] [ e n ] [ f n ] [ h n ] [ m n ] [ p n ] [ r n ] [ t n ] [ w n ] } ]
Description
Paramtres de calcul de priorit
La priorit de la plupart des processus utilisateur varie en fonction du temps CPU
rcemment utilis par le processus. Les calculs de priorit du programmateur de CPU sont
bass sur deux paramtres dfinis via schedtune : r et d. Les valeurs de r et de d sont
exprimes en units de trente secondes (1/32) ; cest--dire que la formule utilise par le
programmateur pour calculer la quantit ajouter la priorit dun processus pour pnaliser
un usage rcent de CPU est la suivante :
pnalit CPU = (valeur de CPU rcemment utilise par le processus) * (r/32)
et le recalcul une fois par seconde de la valeur de CPU rcemment utilise par chaque
processus est effectu selon la formule :
nouvelle valeur de CPU rcemment utilise = (ancienne valeur) * (d/32)
Par dfaut, r et d ont tous deux la valeur 16 qui assure la comptabilit de la planification
de CPU avec les versions antrieures dAIX. Avant de tester ces valeurs, consultez la
section Optimisation du calcul de la priorit dun processus via schedtune, page 6-23.
Paramtres de contrle de charge mmoire

Le programmateur AIX excute un contrle de charge mmoire en suspendant les
processus lorsque la mmoire est sur-sollicite. Le systme njecte pas les processus,
mais vole les pages au fur et mesure quelles sont requises par la mmoire courante.
Normalement, les pages sont voles aux processus suspendus. La mmoire est considre
sur-sollicite si :
p*h>s
p tant le nombre de pages crites dans lespace de pagination au
cours de la dernire seconde, h un entier dfini par lindicateur h, et s
le nombre de vols de pages commis pendant la dernire seconde.
A-6
Un processus est suspendu lorsque la mmoire est sur-sollicite et que :

r*p>f
r tant le nombre de repages accumules par le processus au cours

de la dernire seconde, p un entier dfini par lindicateur p, et f le
nombre de dfauts de page rencontrs par le processus au cours de la
dernire seconde.
Les processus priorit fixe de mme que les processus noyau ne peuvent tre
suspendus.
Le terme repages fait rfrence au nombre de pages appartenant au processus qui ont
t rclames et qui, trs vite, ont nouveau t rfrences par le processus.
Lutilisateur peut galement spcifier un niveau minimal de multiprogrammation via
lindicateur m. Ceci garantit lactivit dun minimum de processus pendant la priode de
suspension. Les processus sont dits actifs lorsquils sont excutables et quils sont en
attente dune E/S de page. Les processus en attente dvnements et les processus
suspendus ne sont pas considrs actifs, pas plus que le processus dattente.
Les processus suspendus peuvent tre rintgrs lorsque le systme est rest en de du
seuil de surcharge pendant n secondes, n tant spcifi par lindicateur w. Les processus
sont rintgrs au systme sur la base de leur priorit, puis de la dure de leur suspension.
Avant de tester ces valeurs, consultez la section Optimisation du contrle de charge de la
mmoire VMM, page 7-14.
Paramtre dincrment de tranche horaire

La commande schedtune permet galement de modifier la dure (tranche horaire) pendant
laquelle le systme dexploitation autorise lexcution dun processus, avant dappeler le
rpartiteur pour choisir un autre processus excuter. Par dfaut, cette dure est celle
dune seule impulsion dhorloge (10 millisecondes). Le cas chant, indiquez le nombre
dimpulsions supplmentaires souhaites via lindicateur t de la commande schedtune.
Sous AIX version 4.1, ce paramtre ne sapplique quaux routines assorties de la politique
de planification SCHED_RR. Reportez-vous Planification des routines de porte
concurrentielle globale ou locale, page 2-2.
Paramtre dintervalle de ressai fork()

Si un appel de sous-routine fork() choue suite un espace de pagination insuffisant pour
crer un nouveau processus, le systme relance lappel au bout dun certain dlai. Ce dlai
est dfini par lindicateur schedtune f.
Restrictions sur schedtune

Seul lutilisateur root est habilit excuter schedtune. Les modifications effectues par
le biais de la commande schedtune ne restent en vigueur que jusqu la rinitialisation
suivante du systme. Pour modifier des paramtres de tranche horaire ou VMM de faon
permanente, placez la commande schedtune approprie dans /etc/inittab.
Attention : Mal utilise, cette commande peut induire une dtrioration des
performances ou une panne du systme dexploitation. Assimilez bien les sections
concernes avant de modifier des paramtres systme via schedtune.
A-7
Indicateurs
A dfaut dindicateurs, les valeurs courantes sont imprimes.
D
Restaure les valeurs par dfaut (d=16, e=2, f=10, h=6, m=2, p=4,
r=16, t=0, w=1).
d n
La quantit de CPU rcemment utilise par chaque processus est

multiplie par d/32 une fois par seconde.
e n
Indique quun processus suspendu rcemment puis rintgr peut tre

nouveau suspendu sil a t actif pendant au moins n secondes.
f n
Nombre dimpulsions dhorloge (de 10 millisecondes) dfinissant le

dlai avant relance dun appel fork inabouti par insuffisance despace
de pagination. Le systme effectue jusqu cinq tentatives de relance
de fork.
h n
Spcifie le critre systme global de dclenchement et darrt de la

suspension des processus. La valeur zro dsactive effectivement le
contrle de charge de la mmoire.
m n
Dfinit le niveau minimal de multiprogrammation.
p n
Spcifie le critre par processus de dtermination du processus

suspendre.
r n
La quantit de CPU rcemment utilise par un processus est multiplie

par r/32 lorsque la priorit du processus est recalcule.
t n
Accrot la dure dune tranche horaire dlai maximal au bout duquel

est planifie lexcution dun autre processus. La dure par dfaut est
de 10 millisecondes. Le paramtre n est exprim en units de
10 millisecondes. Si n = 0, la dure de la tranche horaire est de
10 millisecondes. Si n = 2, elle est de 30 millisecondes. Sous AIX
version 4.1, ce paramtre ne sapplique quaux routines assorties de la
politique de planification SCHED_RR.
w n
Dlai (en secondes) respecter aprs la fin dun emballement, avant

ractivation des processus suspendus.
Affiche une brve description de la commande et de ses paramtres.
Voir aussi
La sous-routine fork.
Gestion de la mmoire relle.
Optimisation du calcul de la priorit des processus avec schedtune, page 6-23.
Optimisation du contrle de charge de la mmoire VMM, page 7-14.
A-8
Commande vmtune
Objet
Modifie les paramtres dexploitation du gestionnaire de mmoire virtuel (VMM) et dautres
composants dAIX.
Syntaxe
vmtune [ b numfsbuf ] [ B numpbuf ] [ c numclust ] [ f minfree ] [ F maxfree ] [ k

npskill ] [ l lrubucket ] [ M maxpin ] [ N pd_npages ] [ p minperm ] [ P maxperm ] [ r
minpgahead ] [ R maxpgahead ] [u lvm_budcnt] [ w npswarn ] [W maxrandwrt]
Description
Le gestionnaire de mmoire virtuelle (VMM) tient jour la liste de trames de page libres de
la mmoire relle. Ces trames sont disponibles pour les pages de mmoire virtuelle,
requises pour pallier un dfaut de page. Lorsque le nombre de pages de la liste des
disponibilits passe en dessous du seuil spcifi par le paramtre minfree, VMM commence
voler des pages pour les ajouter la liste des disponibilits. VMM continue voler des
pages jusqu ce la liste des disponibilits ait au moins le nombre de pages spcifi par le
paramtre maxfree.
Si le nombre de pages de fichier (pages permanentes) en mmoire est infrieur au nombre
spcifi par le paramtre minperm, VMM vole des trames aux pages de fichier ou calcules,
quels que soient les taux de pages dj rfrences (repages). Si ce nombre est
suprieur maxperm, VMM ne vole que des pages de fichier. Entre les deux, VMM ne vole
normalement que des trames de pages de fichier, mais si le taux de pages de fichier dj
rfrences est suprieur celui des pages calcules, les pages calcules sont galement
voles.
Si un processus lit un fichier squentiellement, la valeur de minpgahead dtermine le
nombre de pages lire par anticipation ds dtection de la condition. La valeur de
maxpgahead dfinit le nombre maximal de pages lues par anticipation, quel que soit le
nombre de lectures squentielles antrieures.
Sous la version 3.2.5, il est impossible de fixer plus de 80 % de la mmoire relle. Sous AIX
version 4.1, le paramtre maxpin permet de fixer le pourcentage limite de mmoire fixe.
AIX version 4.1 permet doptimiser le nombre de systmes de fichiers bufstructs
(numfsbuf) et la quantit de donnes traites par lalgorithme dcriture diffre (numclust).
Sous AIX version 4.1, vous pouvez galement modifier les seuils dterminant linsuffisance
despace de pagination. Le paramtre npswarn spcifie le nombre de pages de lespace de
pagination disponibles, partir duquel le systme commence avertir les processus que
lespace de pagination est presque satur. Le paramtre npskill spcifie le nombre de
A-9
pages de lespace de pagination partir duquel le systme commence tuer les processus
pour librer de lespace.
Seul lutilisateur root est habilit excuter vmune. Les modifications effectues par le
biais de la commande vmune ne restent en vigueur que jusqu la rinitialisation suivante
du systme. Pour modifier des paramtres VMM de faon permanente, placez la
commande vmune approprie dans inittab.
Attention : Mal utilise, cette commande peut induire une dtrioration des
performances ou une panne du systme dexploitation. Avant de modifier des
paramtres systme via vmtune, reportez-vous Performances du gestionnaire de
mmoire virtuelle (VMM), page 2-5 et Optimisation du remplacement de page VMM,
page 7-16.
Indicateurs
A-10
b numfsbuf
Nombre de systmes de fichiers bufstruct. Valeur par

dfaut :
B numpbuf
Nombre de pbufs utiliss par LVM. Valeur maximale :

Sous AIX version 3, le nombre de pbufs doit parfois tre
augment sur les systmes effectuant souvent de vastes
oprations dE/S squentielles.
c numclust
Nombre de grappes de 16 ko traites en criture diffre.

Valeur par dfaut :
f minfree
Nombre minimal de trames de la liste de disponibilits.

Valeur comprise entre 8 et 204 800.
F maxfree
Nombre de trames sur la liste de disponibilits partir

duquel le vol de pages est interrompu. Sa valeur est
comprise entre 16 et 204 800, mais doit tre suprieure au
nombre spcifi par minfree dune valeur au moins gale
maxpgahead.
k npskill
Nombre de pages disponibles dans lespace de pagination,

partir duquel AIX commence tuer les processus. Valeur
par dfaut :
l lrubucket
Taille (en pages de 4 ko) du compartiment de

repositionnement de page le moins rcemment utilis (lru).
Il sagit du nombre de trames de page qui pourront tre
examines en une seule opration en vue de
dchargements possibles lorsquune trame libre est
requise. Un nombre peu lev se traduit par un temps de
latence faible, mais engendre cependant un comportement
quelque peut diffrent de celui dun vritable algorithme lru.
La valeur par dfaut est de 512 Mo et le minimum est de
256 Mo. Loptimisation de cette option nest pas conseille.
M maxpin
Pourcentage maximal de mmoire relle susceptible dtre

fixe. Valeur par dfaut : Si vous modifiez cette valeur,
veillez conserver au moins 4 Mo de mmoire non fixe
pour le noyau.
N pd_npages
Nombre de pages supprimer dun coup de la RAM

lorsquun fichier est supprim. Valeur par dfaut : la plus
grande taille de fichier possible divis par la taille de page
(actuellement 4096). Si la taille maximale de fichier est 2
Go, la valeur par dfaut de pd_npages est 524288.
Optimiser cette option ne prsente dintrt que pour les
applications en temps rel.
p minperm
Point en-de duquel les pages de fichier sont protges

de lalgorithme de page dj rfrences. Cette valeur est
un pourcentage du total de trames de pages de mmoire
relle du systme. La valeur spcifie doit tre suprieure
ou gale 5.
P maxperm
Point au-del duquel lalgorithme de vol de pages ne vole

que des pages de fichier. Cette valeur est un pourcentage
du total de trames de pages de mmoire relle du systme.
La valeur spcifie doit tre suprieure ou gale 5.
r minpgahead
Nombre de pages partir duquel commence la lecture

squentielle anticipe. Cette valeur doit tre une puissance
de 2, comprise entre 0 et 4 096.
R maxpgahead
Nombre maximal de pages lire par anticipation. Cette

valeur doit tre une puissance de 2, comprise entre 0 et
4 096, suprieure ou gale minpgahead.
u lvm_bufcnt
Nombre de tampons LVM pour les E/S physiques brutes.

Valeur par dfaut : Valeurs possibles comprises entre 1 et
64. Cette option nest disponible que sous AIX version 4.1.
w npswarn
Nombre de pages libres de lespace de pagination partir

duquel AIX commence envoyer le signal SIGDANGER
aux processus. Valeur par dfaut :
W maxrandwrt
Seuil (en pages de 4 ko) dcritures alatoires accumuler

en RAM avant quelles soient synchronises sur disque via
un algorithme dcriture diffre. Ce seuil est dfini sur la
base des fichiers.
Loption W maxrandwrt nest disponible que sous AIX
version 4.1.3 et ultrieures. La valeur par dfaut de
maxrandwrt est 0 (dsactivation de lcriture diffre
alatoire).
Voir aussi
Performances du gestionnaire de la mmoire virtuelle (VMM), page 2-5.
A-11
Script pdt_config
Objet
Contrle les oprations de loutil PDT (Performance Diagnostic Tool).
Syntaxe
pdt_config
Description
Le script pdt_config est interactif. Appel, il affiche le menu :
3) disable
PDT reporting
5) disable
PDT collection
6) deinstall
PDT
7) exit pdt_config
Please enter a number:
Pour slectionner une option, tapez son numro et appuyez sur Entre.
Si le rpertoire /usr/sbin/perf/diag_tool ne se trouve pas dans le chemin de recherche, le
script peut tre appel par /usr/sbin/perf/diag_tool/pdt_config.
Seul lutilisateur root est habilit excuter le script pdt_config.
Indicateurs
Aucun.
Voir aussi
Chapitre 12. Outil de diagnostic PDT.
A-12
Script pdt_report
Objet
Gnre un compte rendu PDT (Performance Diagnostic Tool) sur la base des informations
historiques actuelles.
Syntaxe
pdt_report
gravit
pdt_report [ severity ]
Description
PDT contrle rgulirement les performances du systme et ajoute les donnes une base
de donnes historique. Normalement, PDT gnre un rapport par jour, une heure dfinie.
Le script pdt_report cre ce compte rendu sur demande. Le compte rendu est crit sur
stdout. Les messages derreur sont dirigs vers stderr.
Les messages issus de PDT peuvent tre de gravit 1 3 (1 tant le niveau le plus lev).
Par dfaut, seuls les messages de gravit 1 sont intgrs au compte rendu. Mais vous
pouvez commander pdt_report dinclude des messages de moindre gravit.
Si le rpertoire /usr/sbin/perf/diag_tool ne se trouve pas dans le chemin de recherche, le
script peut tre appel par /usr/sbin/perf/diag_tool/pdt_report.
Indicateurs
gravit
Niveau de gravit partir duquel les messages sont intgrs au

rapport. Valeur : de 1 3.
Voir aussi
Chapitre 12. Outil de diagnostic PDT.
A-13
A-14
Annexe B. Sous-routines lies aux performances
Voici les routines susceptibles daider au contrle et loptimisation des performances :

Sous-routines
Fonction
getpri
Dtermine la priorit de programmation dun processus en cours

dexcution.
getpriority
Dtermine la valeur nice dun processus en cours dexcution.
getrusage
Extrait des informations sur lutilisation de ressources systme.
nice
Incrmente la valeur nice du processus courant.
psdanger
Extrait des informations sur lutilisation de lespace de pagination.
setpri
Attribue une priorit fixe un processus en cours dexcution.
setpriority
Dfinit la valeur nice dun processus en cours dexcution.
Voir aussi
Sous-routines lies aux performances
B-1
B-2
Annexe C. Mmoire cache et adressage

Une exploitation efficace des caches constituant un lment essentiel des performances
dun processeur, les dveloppeurs de logiciels ont intrt bien matriser les techniques de
codage, envisages sous langle de lutilisation du cache. Bien comprendre cet aspect du
problme suppose quelques connaissances sur les architectures de cache ESCALA.
Prliminaire
Les sections qui suivent sadressent aux programmeurs soucieux de connatre limpact de
la mise en mmoire cache et de ladressage virtuel sur les performances de leurs
programmes. Les ingnieurs intresss par la logique lectronique et la conception prcise
du ESCALA ny trouveront sans doute pas leur compte : cette prsentation ne prtend pas
lexhaustivit et la distinction entre les architectures POWER, PowerPC et POWER2 en
est quasiment absente.
Adressage
La figure Transformations successives dune adresse mmoire (section Consultation du
cache) illustre les tapes par lesquelles une adresse 32 bits en mmoire virtuelle, gnre
par un programme, se transforme en adresse mmoire relle. Le nombre exact de bits varie
selon le modle. Les modles diffrent dans leurs dtails, mais pas dans le principe de leur
conception.
Mmoire cache et adressage
C-1
adresse 32 bits gnre par le programme
registre de segment 15
.
.
.
.
4 bits
(numro registre segment)
28 bits
(dcalage
dans
segment)
24 bits
(ID segment)
registre de segment 0
8 bits
adresse
virtuelle 52 bits
Consultation
cache de
donnes
N ligne tiquette
tiquette
8 bits
37 bits
7 bits
absence en
cache D
Consultation
cache L2
adresse virtuelle 52 bits

tiquette
32 bits
Accs
mmoire
relle
tiquette
N ligne
13 bits
7 bits
absence en
cache L2
tiquette TLB
32 bits
N TLB dcalage page

8 bits
40 bits en
entre
12 bits
Consultation
du TLB
translation
dadresse
20 bits en
sortie
adresse relle 32 bits
Adresse relle de page dcalage page

20 bits
12 bits
Transformations successives dune adresse mmoire

Lorsquun programme demande le chargement dun registre avec le contenu dune portion
de la mmoire, lemplacement mmoire est spcifi par le biais dune adresse virtuelle de
32 bits. Les 4 bits suprieurs de cette adresse servent indexer le bloc de registres de
16 segments. Les registres de segment, maintenus par le systme dexploitation,
contiennent tout moment lID segment de 24 bits affect au processus en cours
dexcution. Ces ID segment sont uniques, moins quun processus ne partage un
segment avec un ou plusieurs autres processus. LID segment 24 bits du registre de
segment slectionn est combin avec les 28 bits infrieurs de ladresse des donnes pour
former ladresse virtuelle 52 bits de llment de donnes charger. Le dcalage dans le
segment tant de 28 bits, chaque segment a une longueur de 256 Mo.
C-2
Consultation du cache
Ladresse virtuelle 52 bits est utilise pour la consultation du cache de donnes, comme
illustr la figure Consultation dun cache de donnes. Les lignes du cache ayant une
longueur de 128 octets, les 7 bits infrieurs de ladresse reprsentent le dcalage
lintrieur de la ligne du cache. Le cache de donnes, qui contient 128 ko despace, est
associatif quatre voies. Chaque bloc du cache contient ainsi 256 lignes de 128 octets
(128 ko/(128*4) = 256), et les 8 bits suprieurs suivants reprsentent le numro de
ligne (0-255). Chaque bloc du cache possde une ligne portant ce numro, et les quatre
lignes dotes du mme numro forment une classe de congruence, cest--dire les quatre
emplacements possibles des donnes cherches. Il sagit dun cache associatif quatre
voies. Si la classe de congruence comportait deux membres, nous aurions parl dun cache
associatif deux voies. Sil y avait exactement une ligne de cache par adresse, le cache
serait dit en mappage direct.
tiquette
N ligne tiquette
37 bits
8 bits
7 bits
bloc 0
bloc 1
bloc 2
bloc 3
tiquette
tiquette
tiquette
tiquette
donnes
donnes
donnes
donnes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ligne 0
ligne 1
ligne 2
.
.
.
.
Classe de
congruence
ligne 253
ligne 254
ligne 255
consultation cache donnes
A chaque ligne du cache est associe une tiquette de 37 bits, constitue des bits
suprieurs de ladresse 52 bits partir de laquelle la ligne cache a t charge lorigine.
Si une des tiquettes des quatre lignes de lensemble de congruence correspond aux
37 bits suprieurs de ladresse virtuelle 52 bits qui vient dtre gnre, il y a prsence en
cache. Les donnes de la ligne sont charges dans le registre, et aucun accs RAM
(et donc aucune adresse relle) nest requis.
Si aucune des tiquettes de lensemble de congruence ne correspond ltiquette des
donnes charger, il y a absence de donnes en cache. Cette machine comporte un cache
L2 : la consultation dun cache est semblable celle effectue dans un cache de donnes.
La principale diffrence entre les deux consultations de caches est que le cache L2 est en
mappage direct. Les lignes ont une longueur de 128 octets, et le cache offre une capacit
de 1 Mo : il y a donc 8192 lignes. Les 7 bits infrieurs de ladresse 52 bits constituent
toujours le dcalage dans la ligne. Les 13 bits suivants constituent le numro de la ligne du
cache. A chaque ligne est associe une tiquette 32 bits unique. Si cette tiquette
correspond aux 32 bits suprieurs de ladresse 52 bits, il y a prsence en cache L2. Sinon,
ladresse relle des donnes doit tre dtermine et les donnes extraites de la RAM.
Diffrentes implantations des architectures POWER prsentent des caches de taille et de
gomtrie variables ; certaines sont dpourvues de cache L2, dautres sont dotes de
caches combinant instructions et donnes, dautres encore ont des longueurs de lignes
diffrentes. Taille et position des champs de ladresse 52 bits peuvent diffrer quelque peu,
mais les principes de consultation du cache restent les mmes.
C-3
Consultation du TLB
Le tampon de donnes TLB (translation lookaside buffer) est un cache dadresses.
Ltiquette TLB est constitue des 32 bits suprieurs de ladresse virtuelle 52 bits. Les 8 bits
suivants de cette adresse indiquent le numro de ligne dans le TLB, qui a 512 entres et
constitue un ensemble associatif deux voies (chaque bloc est ainsi constitu de
256 entres). Les 12 bits infrieurs de ladresse 52 bits dfinissent le dcalage dans la page
de 4096 octets. La partie donnes de chaque ligne du TLB constitue les 20 bits suprieurs
de ladresse de page relle 32 bits (voir la figure Consultation du TLB de donnes). Sil y a
prsence en TLB, les 20 bits suprieurs de lentre TLB sont combins avec les 12 bits
infrieurs du dcalage de page, pour former ladresse relle 32 bits des donnes.
N ligne
tiquette
32 bits
tiq0
page relle
adresse
tiq1
8 bits
dcal.
page
12 bits
page relle
adresse
.
Classe de
congruence
32 bits
20 bits
32 bits
20 bits
Consultation du TLB de donnes

En cas dabsence en TLB, le matriel dtermine ladresse relle des donnes en faisant
appel aux tableaux de pages, via un algorithme (qui nentre pas dans le cadre de ce
manuel). Cette opration consomme plusieurs dizaines de cycles processeur. Une fois
calcule ladresse relle 32 bits, la portion adresse de page (20 bits) est mise en mmoire
cache dans lentre TLB ad hoc, et ltiquette de cette entre, mise jour en consquence.
Accs RAM
Quel que soit le moyen utilis pour lobtenir, ladresse 32 bits relle des donnes sert
mettre une requte la RAM. Normalement, un dlai de latence dau moins huit cycles
processeur intervient entre lmission de la requte et le renvoi des 16 premiers octets de
donnes (128 bits, correspondant la largeur du bus mmoire), incluant les donnes en
cours de chargement. A ce stade, le processeur peut reprendre ses oprations. Laccs
RAM se poursuit pendant encore sept cycles processeur, pour charger la ligne complte de
cache (128 octets, par tranches de 16 octets). Ainsi, une absence en cache mobilise au
moins 16 cycles processeur. Ltiquette de la ligne de cache est mise jour via les 37 bits
suprieurs de ladresse des donnes. Le contenu initial de la ligne de cache est perdu.
C-4
Implications
Plusieurs types de schmas dadressage pathologique peuvent provoquer dincessantes
absences en cache ou en TLB, ralentissant notablement la vitesse dexcution. Si, par
exemple, le programme accde un tableau plus grand que le cache, lcart tant
dexactement 128 octets, une absence en cache aura lieu chaque accs. Si le programme
prsente au processeur une srie de requtes concernant le mme numro de ligne cache,
mais dans des pages diffrentes, une srie de collisions entre ensembles de congruence se
produiront, entranant de nombreuses absences en cache mme si celui-ci nest pas satur.
Le fait que le cache soit associatif quatre voies rend cette ventualit assez improbable,
mais il suffit dun choix malheureux de dcalages pour les lments de donnes pour
ralentir considrablement un programme.
Les grands tableaux peuvent galement tre lorigine de problmes. La figure
Stucture dun tableau en mmoire illustre le stockage de tableaux en C et en FORTRAN.
Les tableaux C sont bass sur les ranges, tandis que les tableaux FORTRAN le sont sur
les colonnes. Si une boucle interne dun programme C indexe par colonne (ou par range
pour un programme FORTRAN), un tableau assez grand (512 x 512 en virgule flottante
double prcision, par exemple) peut provoquer une absence en TLB sur chaque accs.
Pour en savoir plus sur ces phnomnes, reportez-vous Exemple thorique, page 6-10.
Tableau FORTRAN
colonne 1
colonne 2
colonne n
range n
Tableau C
range 1
range 2
Structure dun tableau en mmoire
C-5
C-6
Annexe D. Commande ld
Lditeur de liens AIX (appel ltape finale dune compilation ou directement via la
commande ld) offre des fonctions non proposes par lditeur de liens UNIX classique.
Il peut en rsulter un dlai ddition de liens plus long, si la puissance de lditeur AIX est
inexploite. Cette annexe prsente quelques techniques permettant de lexploiter au mieux.
Excutables rditables
La documentation de lditeur de liens fait rfrence sa capacit daccepter un excutable
(un module chargeable) comme entre. Cette fonction peut sensiblement amliorer les
performances dun systme o le dveloppement de logiciels constitue une part importante
de lactivit, ainsi que les temps de rponse des ld individuels.
Sur la majorit des systmes UNIX classiques, lentre de la commande ld est toujours
constitue dun ensemble de fichiers contenant du code objet, fichiers individuels .o ou
fichiers .o archivs en bibliothque. La commande ld rsout ensuite les rfrences externes
de ces fichiers et crit un excutable portant par dfaut le nom a.out. Le fichier a.out ne
peut tre quexcut. Si une erreur est dtecte dans lun des modules intgrs au fichier
a.out, il faut modifier et recompiler le code source dfectueux, puis rpter lintgralit du
processus ld, partir de lensemble complet de fichiers .o.
Sous AIX, lditeur de liens accepte en entre aussi bien les fichiers .o que les fichiers
a.out, car lditeur intgre les dictionnaires de rsolution ESD (External Symbol Dictionary)
et RLD (Relocation Dictionary), dans le fichier excutable. Ce qui signifie que lutilisateur
peut rditer les liens dun excutable existant pour remplacer un seul fichier .o modifi, au
lieu de reconstruire un nouvel excutable depuis le dbut. Le processus ddition
consommant des cycles processeur et de lespace de stockage en partie
proportionnellement au nombre de fichiers faisant lobjet dun accs et au nombre de
rfrences aux symboles rsoudre, rditer les liens dun excutable avec une nouvelle
version dun seul module est bien plus rapide que de repartir du dbut.
Bibliothques de sous-routines prdites

Dans certains environnements, la capacit de prditer les liens de lintgralit dune
bibliothque de sous-routines est tout aussi importante. Les bibliothque de
sous{TAG}routines du systme telles que libc.a sont, en effet, livres en format ddition de
sortie, et non sous forme dun fichier archive de fichiers .o . Lutilisateur gagne de ce fait un
temps considrable de traitement lorsquil dite les liens dune application avec les
bibliothques systme requises, dans la mesure o seules les rfrences de lapplication
aux sousroutines de la bibliothque doivent tre rsolues. Les rfrences entre routines de
bibliothques systme ont t dores et dj rsolues au cours du processus de constitution
du systme.
Nombre de bibliothques de sous-routines tierces sont toutefois souvent livres sous forme
darchive de fichiers .o bruts. Lorsquun utilisateur dite les liens dune application avec des
bibliothques de ce type, lditeur de liens doivent rsoudre les symboles de toute la
bibliothque chaque dition de liens de lapplication. Lopration est dautant plus longue
si les bibliothques sont volumineuses et les machines peu puissantes.
Lcart de performance entre des bibliothques prdites et non prdites est norme,
notamment sur de petites configurations. Avec prdition de la bibliothque de
sous-routines, ldition des liens du programme FORTRAN est tombe environ
1,7 minute. Lorsque le fichier a.out rsultat a t soumis une nouvelle dition de liens
Commande ld
D-1
avec un nouveau fichier FORTRAN .o, pour simuler une correction derreur, le dlai est
pass environ 4 secondes.
Exemples
1. Pour prditer les liens dune bibliothque, lancez la commande suivante sur le fichier
archive :
ld r libfoo.a o libfooa.o
2. Compiler et diter les liens du programme FORTRAN something.f revient alors :
xlf something.f libfooa.o
Notez que la bibliothque prdite est traite comme un fichier dentre normal, et non
avec la syntaxe habituelle didentification des bibliothques (lfoo).
3. Pour recompiler le module et rditer les liens de lexcutable aprs correction dune
erreur, lancez :
xlf something.f a.out
4. Si, toutefois, la correction de lerreur a conduit lappel dune autre sous-routine de la
bibliothque, ldition de liens naboutira pas. Le script shell Korn suivant teste le retour
dun code derreur et y remdie :
# !/usr/bin/ksh
# Shell script for source file replacement bind
#
xlf something.f a.out
rc=$?
if [ $rc != 0 ]
then
echo New function added ... using libfooa.o
xlf something.o libfooa.o
fi
Voir aussi
Commande ld.
Format de fichier Objet XCOFF (a.out).
D-2
Annexe E. Outils de performance
De temps en temps, le groupe Performance AIX se voit demander des prcisions sur la
surcharge occasionne par les outils de performance. Cest une question intressante,
dans la mesure o certains outils ont une rpercussion certaine sur la charge du systme.
Cest galement une question laquelle il est difficile de rpondre, car le cot induit par la
plupart des outils est souvent proportionnel un aspect particulier de la charge du systme.
Les sections suivantes proposent des considrations succintes et informelles sur la vitesse
et les ressources utilises par les principaux outils de contrle et doptimisation. Ces
considrations visent donner une ide du cot relatif des diffrents outils : elles ne
constituent pas une description rigoureuse des performances des outils.
filemon
Lessentiel de la charge de filemon sur le systme est contitue de temps

CPU. Dans un environnement satur au niveau de la CPU avec peu dE/S,
filemon a ralenti une longue compilation denviron 1 %. Dans un
environnement satur au niveau du CPU avec un fort taux de sorties
disque, filemon a ralenti le programme dcriture denviron 5 %.
fileplace
La plupart des variantes de cette commande utilisent moins de

0,3 seconde de temps CPU.
iostat
Cette commande utilise environ 20 millisecondes de temps CPU pour

chaque compte rendu priodique gnr.
lsattr
Cette commande est limite au niveau des E/S. A sa premire excution,

elle peut demander entre 2 et 4 secondes pour lire les donnes requises.
Les excutions suivantes, sur un systme peu charg, consomment
environ 0,5 seconde de temps CPU.
lslv
Cette commande est limite au niveau de la CPU. Par exemple, la

commande :
lslv p hdisk0 hd1
consomme environ 0,5 seconde de temps CPU.
netpmon
Avec une charge modre, oriente rseau, netpmon augmente la

consommation de CPU de 3 5 %. Dans un environnement satur au
niveau du CPU avec peu dE/S, netpmon a ralenti une longue compilation
denviron 3,5 %.
netstat

nfsstat

PDT
La collecte quotidienne des donnes prend plusieurs minutes, mais

lessentiel de ce temps est du temps de veille. La consommation relle
de CPU ne dpasse gnralement pas 30 secondes.
ps
Le temps CPU consomm par cette commande dpend du nombre de

processus afficher, mais ne dpasse gnralement pas 0,3 seconde.
svmon
La commande svmon G consomme environ 3,2 secondes de temps

CPU. Une commande svmon pour un seul processus (svmon P
id-processus) consomme environ 0,7 seconde de temps CPU.
Outils de performance
E-1
E-2
tprof
tprof utilisant trace, il peut quelque peu surcharger le systme. tprof

nactive toutefois quun point dancrage de suivi, la surcharge induite est
donc moindre que lors dun suivi complet. Par exemple, tprof a provoqu
une baisse de performance denviron 2 % pour une longue compilation.
trace
La surcharge induite par trace dpend largement de la charge du systme

et du nombre dID de points dancrage collects. A lextrme, un travail
long et trs mobilisateur de CPU, excut sur un systme libre par ailleurs,
est rallong denviron 3,2 % si trace est actif et que tous les points
dancrage le sont aussi.
vmstat
Cette commande utilise environ 40 millisecondes de temps CPU pour

chaque compte rendu gnr. La commande vmstat s consomme
environ 90 millisecondes de temps CPU.
Annexe F. Gestion de la mmoire des applications
AIX a t dot, partir de la version 3.2, dun nouvel algorithme de gestion de la mmoire,
qui est rest en vigueur avec la version 4. Lalgorithme prcdent, largement exploit sur
les systmes UNIX, arrondissait la taille de toutes les requtes malloc la puissance de 2
immdiatement suprieure. Il en rsultait une fragmentation considrable de la mmoire
relle et virtuelle et un faible regroupement rfrentiel. Le nouvel algorithme affecte la
quantit exacte despace requis et est plus efficace pour ce qui concerne la rcupration
des blocs mmoire prcdemment utiliss.
Malheureusement, un certain nombre de programmes dapplication existants dpendent du
prcdent algorithme au niveau de leurs performances ou mme de leur fonctionnement.
Par exemple, si un programme dpend de lespace supplmentaire fourni par lopration
darrondi, car il dborde en ralit de la fin dun tableau, il chouera probablement avec la
version 3.2 de malloc.
Autre exemple : du fait de linefficacit de la rcupration despace de la routine de la
version 3.1, le programme dapplication reoit presque toujours de lespace qui a t
rinitialis zro (lorsquun processus touche une page donne de son segment de travail
pour la premire fois, cette page est dfinie zro). Lexcution des applications peut
dpendre de cet effet secondaire. En fait, la mise zro de lespace affect nest pas une
fonction propre malloc et entrane une pnalit non justifie au niveau des performances,
pour les programmes qui ninitialisent que lorsque requis et peut-tre pas zro.
La version 3.2 de malloc tant plus efficace au niveau de la rutilisation de lespace, les
programmes dpendant de la rception de malloc despace mis zro choueront
probablement avec les versions 3.2 et ultrieures du systme.
De mme, si un programme raffecte (via realloc) continuellement une structure dans une
zone de taille lgrement suprieure, dans la version 3.1, realloc peut ne pas avoir besoin
de dplacer souvent la structure. Souvent, realloc peut faire usage de lespace
supplmentaire fourni par lopration darrondi. Sous la version 3.2, realloc aura
gnralement dplacer la structure vers une zone lgrement plus grande, parce que
quelque chose dautre a t affect (via malloc) juste au-dessus. Ceci explique lapparente
dgradation des performances de realloc, alors quil sagit en ralit de lmergence dun
cot implicite dans la structure du programme dapplication.
Nous avons bien entendu prvu le cas o des programmes AIX existants, ou ports partir
dautres systmes UNIX, dpendent deffets secondaires de la version 3.1 de la
sous-routine malloc. Dans ces cas, lalgorithme de la version 3.1 peut tre rappel via :
MALLOCTYPE=3.1; export MALLOCTYPE
A partir de l, tous les programmes excuts par le shell utiliseront la version antrieure de
la sous-routine malloc. Donner MALLOCTYPE une valeur autre que 3.1 provoque le
retour la version 3.2.
Voir aussi
Sous-routines malloc et realloc.
Gestion de la mmoire des applications
F-1
F-2
Annexe G. Bibliothques partages
Partager une bibliothque offre parfois loccasion de ngocier mmoire et temps de

traitement.
Avantages et inconvnients
Partager une bibliothque signifie disposer dune seule copie des routines les plus utilises
et maintenir cette copie dans un segment partag unique. Ce qui peut rduire de faon
significative la taille des excutables, et conomiser ainsi de lespace disque. En outre,
dans la mesure o ces routines sont exploites par plusieurs processus dans un
environnement multi-utilisateur, une routine que vous appelez pour la premire fois peut
dj se trouver en mmoire relle : vous gagnez ainsi le temps de chargement
correspondant et conomisez la trame de page requise. Autre avantage, les routines ne
sont pas lies lapplication de faon statique, mais dynamiquement au chargement de
lapplication. Ce qui permet aux applications dhriter automatiquement des modifications,
sans recompilation ou rdition des liens.
Partager une bibliothque peut nanmoins prsenter quelques inconvnients. Du point de
vue des performances, un code collant est requis dans lexcutable pour accder au
segment partag. Ce code ajoute un nombre de cycles par appel un segment de
bibliothque partage. Plus subtile est la rduction du regroupement rfrentiel. Si seul un
nombre restreint de routines vous intressent, vous risquez de les trouver disperses dans
lespace dadressage virtuel de la bibliothque : le nombre de pages auxquelles vous devez
alors accder pour appeler les routines est notablement suprieur ce qui aurait t le cas
si les routines avaient t directement lies lexcutable. Une des consquences est que,
si vous tes le seul utilisateur de ces routines, vous vous heurterez davantage de dfauts
de page pour les charger toutes en mmoire relle. En outre, dans la mesure o davantage
de pages sont touches, la probabilit dune absence dinstruction en TLB
(translation lookaside buffer) est plus grande.
Dfinition dexcutables partags ou non

Par dfaut, la commande cc est associe loption de bibliothque partage. Pour passer
outre cette valeur, spcifiez loption bnso comme suit :
cc xxx.c o xxx.noshr O bnso bI:/lib/syscalls.exp
Choix de loption approprie

A lvidence, le plus simple pour dterminer si une application est sensible au partage des
bibliothques est de recompiler lexcutable avec loption de non-partage. Si les
performances samliorent notablement, il vous appartient de dcider si cette amlioration
vaut dabandonner les autres avantages du partage des bibliothques. Veillez mesurer les
performances dans un environnement rel : un programme dit en mode non partag peut
tre excut plus rapidement comme instance simple sur une machine faiblement charge.
Ce mme programme, exploit simultanment par plusieurs utilisateurs, peut suffisamment
augmenter la consommation de mmoire relle pour ralentir lensemble de la charge de
travail.
Bibliothques partages
G-1
Voir aussi
Shared Libraries and Shared Memory dans AIX General Programming Concepts : Writing
and Debugging Programs.
G-2
Annexe H. Accs lhorloge du processeur
Les tentatives de mesure, sous AIX, dintervalles de temps minimes se heurtent souvent
lactivit darrire-plan intermittente du sytme dexploitation et la mobilisation de temps
de traitement par les routines du systme. Une solution ce problme consiste accder
directement lhorloge du processeur pour dterminer le dbut et la fin des mesures
interrompues, effectuer les mesures plusieurs fois et filtrer le rsultat pour liminer les
priodes coupes par des interruptions.
Dans les architectures POWER et POWER2, lhorloge du processeur est implante comme
paire de registres spciaux. Larchitecture PowerPC dfinit un registre 64 bits appel base
horaire. Ces registres ne sont accessibles quaux programmes en assembleur.
Attention : Les dures mesures par lhorloge du processeur correspondent des
temps absolus. Si une interruption se produit dans lintervalle, la dure calcule inclut
celle du traitement de cette interruption et, ventuellement, celle dautres processus,
avant que le contrle ne revienne au code chronomtr. Autrement dit, la dure issue de
lhorloge processeur est une dure brute, quil ne faut pas utiliser sans vrification.
Sous AIX version 4.1, une paire de sous-routines de bibliothque a t ajoute au systme
pour faciliter laccs ces registres et le rendre indpendant de larchitecture. Il sagit des
routines read_real_time et time_base_to_time. La sous-routine read_real_time extrait
lheure courante de la source ad hoc et la stocke sous forme de deux valeurs de 32 bits.
La sous-routine time_base_to_time vrifie que lheure est exprime en secondes et
nanosecondes, excutant au besoin les conversions ncessaires partir du format base
horaire. La sparation des deux fonctions (obtention de lheure et conversion) a pour but de
minimiser la charge dobtention de lheure.
Lexemple suivant illustre lutilisation de ces routines pour mesurer le dlai dexcution dune
portion spcifique de code :
#include <stdio.h>
#include <sys/time.h>
int main(void) {
timebasestruct_t start, finish;
int val = 3;
int w1, w2;
double time;
/* get the time before the operation begins */
read_real_time(&start, TIMEBASE_SZ);
/* begin code to be timed */
printf(This is a sample line %d \n, val);
/* end code to be timed
*/
/* get the time after the operation is complete
read_real_time(&finish, TIMEBASE_SZ);
/* call the conversion routines unconditionally, to ensure
*/
/* that both values are in seconds and nanoseconds regardless */
/* of the hardware platform.
*/
time_base_to_time(&start, TIMEBASE_SZ);
time_base_to_time(&finish, TIMEBASE_SZ);
/* subtract the starting time from the ending time */
w1 = finish.tb_high start.tb_high; /* probably zero */
w2 = finish.tb_low start.tb_low;
Accs lhorloge du processeur
H-1
/* if there was a carry from loworder to highorder during

/* the measurement, we may have to undo it.
if (w2 < 0) {
w1;
w2 += 1000000000;
}
*/
*/
/* convert the net elapsed time to floating point microseconds */

time = ((double) w2)/1000.0;
if (w1 > 0)
time += ((double) w1)*1000000.0;
printf(Time was %9.3f microseconds \n, time);
exit(0);
}
Pour rduire la charge dappel et de retour des routines dhorloge, lanalyste peut essayer
de lier les rfrences de jeux dessais non partages (voir Annexe G).
Sil sagit dvaluer des performances relles, vous pouvez excuter plusieurs fois le code
mesurer. Si vous avez chronomtr ensemble un certain nombre de rptitions
conscutives, vous pouvez calculer le temps moyen, sachant quil risque dinclure le temps
de traitement dinterruptions ou dautres activits. Si les rptitions ont t chronomtres
individuellement, tudiez les dlais pour valuer sil sont raisonnables, mais pensez que le
temps dexcution des routines de chronomtrage est inclus dans chaque mesure. Vous
pouvez utiliser les deux techniques et comparer les rsultats. En tout tat de cause, le choix
dune mthode dpend beaucoup de lobjectif des mesures.
Accs lhorloge unique dune architecture POWER

Attention : Les sections qui suivent ne sappliquent quaux architectures POWER et
POWER2 (et au microprocesseur 601). Les exemples de code fonctionnent
correctement sur un systme PowerPC (ils ne se planteront pas), mais certaines
instructions ne seront que simules. Dans la mesure o laccs lhorloge du
processeur a pour but de mesurer des dures trs prcises avec une faible charge, les
rsultats ainsi obtenus sont de peu dutilit.
Les architectures de processeur POWER et POWER2 comportent deux registres spciaux
(un registre suprieur et un registre infrieur) qui contiennent une horloge haute rsolution.
Le registre suprieur contient le temps en secondes et le registre infrieur, un dcompte
des fractions de seconde, en nanosecondes. La prcision relle du registre infrieur dpend
de la frquence de sa mise jour, qui est spcifique du modle.
Routines assembleur daccs aux registres dhorloge POWER

Le module en assembleur suivant (timer.s) fournit des routines (rtc_upper et
rtc_lower) daccs aux registres suprieur et infrieur de lhorloge.
H-2
.globl
.rtc_upper: mfspr
br
.rtc_upper
3,4
# copy RTCU to return register
.globl
.rtc_lower: mfspr
br
.rtc_lower
3,5
# copy RTCL to return register
Sous-routine C indiquant lheure en secondes

Le module ci-dessous (second.c) contient une routine C qui appelle les routines timer.s
pour accder au contenu des registres suprieur et infrieur, et qui retourne lheure en
secondes, sous forme dune valeur relle double prcision.
double second()
{
int ts, tl, tu;
ts
tl
tu
if
= rtc_upper();
/* seconds
= rtc_lower();
/* nanoseconds
= rtc_upper();
/* Check for a carry from
(ts != tu)
/* the lower reg to the upper.
tl = rtc_lower();
/* Recover from the race condition.
return ( tu + (double)tl/1000000000 );
*/
*/
*/
*/
*/
}
La sous-routine second peut tre appele par une routine C ou FORTRAN.
Remarque : La prcision de second.c peut varier en fonction du temps coul depuis la
dernire rinitialisation du systme. Plus long est ce dlai, plus lev est le nombre de
bits de prcision consomme par la partie secondes entires du nombre. La technique
indique au dbut de cette annexe vite le problme en effectuant la soustraction
requise pour obtenir le dlai coul avant conversion en virgule flottante.
Accs aux registres dhorloge dans les systmes PowerPC

Larchitecture du processeur PowerPC comporte un registre de base horaire de 64 bits,
logiquement divis en deux champs (suprieur et infrieur) de 32 bits (TBU et TBL).
La frquence dincrmentation de ce registre dpend de limplantation logicielle et
matrielle, et peut parfois varier. Convertir les valeurs de la base horaire en secondes est
une tche bien plus complexe que dans une architecture POWER. Nous vous conseillons
vivement dutiliser les interfaces read_real_time et time_base_to_time pour obtenir la
valeur dhorloge des systmes PowerPC.
Exemple dutilisation de la routine second

Voici un exemple (main.c) de programme C faisant appel la sousroutine second :
#include <stdio.h>
double second();
main()
{
double t1,t2;
t1 = second();
my_favorite_function();
t2 = second();
printf(my_favorite_function time: %7.9f\n,t2 t1);
exit();
}
Accs lhorloge du processeur
H-3
Voici un exemple (main.f) de programme FORTRAN faisant appel la sousroutine

second :
double precision t1
double precision t2
11
t1 = second()
my_favorite_subroutine()
t2 = second()
write(6,11) (t2 t1)
format(f20.12)
end
Pour compiler et exploiter main.c ou main.f, utilisez :

xlc O3 c second.c timer.s
xlf O3 o mainF main.f second.o timer.o
xlc O3 o mainC main.c second.o timer.o
H-4
Annexe I. Support NLS (National Language Support)
Le support AIX NLS (National Language Support) facilite lexploitation dAIX dans diffrents
environnements de langues. Lutilisation de NLS ntant pas sans consquence sur les
performances du systme, nous allons en prsenter les principales caractristiques.
NLS permet dadapter AIX en fonction de la langue et de lenvironnement culturel de
lutilisateur. Un environnement local, qui combine une langue et un ensemble de spcificits
gographiques ou culturelles, est identifi par un nom compos, tel que en_US
(anglais amricain). A chaque environnement local, sont associs un ensemble de
catalogues de messages, des tables de tri et dautres informations dfinissant les
spcificits de lenvironnement. A linstallation dAIX, ladministrateur systme dcide des
informations locales installer. Par la suite, les utilisateurs peuvent les adapter chaque
shell en modifiant les variables LANG et LC_ALL.
Le seul environnement local ne rpondant pas la structure ci-dessus est
lenvironnement C (ou POSIX). Il sagit de lenvironnement par dfaut (utilis si aucun autre
nest explicitement slectionn). Cest galement lenvironnement dans lequel est lanc
chaque processus nouvellement gnr. Une excution dans lenvironnement C quivaut
presque, sous AIX, une excution dans lenvironnement originel, unilingue, dUNIX.
Il nexiste pas de catalogues de messages C : les programmes qui tentent dobtenir un
message dun catalogue reoivent le message par dfaut compil dans le programme.
Certaines commandes, telle sort, reviennent leurs algorithmes dorigine, spcifiques de
leur jeu de caractres.
Selon nos mesures, les performances de NLS relvent de trois niveaux possibles.
Lenvironnement C est gnralement le plus rapide pour lexcution des commandes, suivi
des environnements mono-octets (alphabet latin), tels que en_US, les environnements
multioctets tant les plus lents.
Remarques sur la programmation

Historiquement, le langage C a souffert dune certaine confusion entre les mots octet et
caractre. Ainsi un tableau dclar comme char foo[10] est un tableau de 10 octets. Or,
toutes les langues ne sont pas composes de caractres transcriptibles par un seul octet.
Le japonais et le chinois, par exemple, requirent au moins deux octets par caractre. Cest
pourquoi, sous AIX, la distinction est faite entre un octet (8 bits de donnes) et un caractre
(quantit dinformations requises pour reprsenter un caractre).
Deux des caractristiques dun environnement local sont le nombre maximal doctets requis
pour reprsenter un caractre et le nombre maximal de positions affichables en sortie quun
caractre peut occuper. Ces valeurs peuvent tre obtenues via les macros MB_CUR_MAX
et MAX_DISP_WIDTH. Si ces deux valeurs sont gales 1, lquivalence entre octet et
caractre est pertinente dans cet environnement. Si lune des deux valeurs est suprieure
1, les programmes effectuant un traitement caractre par caractre, ou gardant trace du
nombre de positions daffichage, devront recourir aux fonctions dinternationalisation.
Dans la mesure o les codages multioctet comportent un nombre variable doctets par
caractre, ils ne peuvent tre traits comme des tableaux de caractres. Pour programmer
efficacement dans le cas o chaque caractre doit tre trait, un type de donnes taille
doctet fixe, wchar_t, a t dfini. Une donne de type wchar_t est suffisamment grande
pour contenir le format converti de nimporte quel caractre cod. Les programmeurs
peuvent ainsi dclarer des tableaux de wchar_t et les traiter de faon grosso modo
quivalente un tableau de type char, en utilisant les analogies avec les caractres
tendus des fonctions libc classiques. Malheureusement, la conversion du format multioctet
Support NLS (National Language Support)
I-1
(dans lequel le texte est rdig, enregistr sur disque ou saisi lcran) au format wchar_t,
est relativement coteuse. Il convient donc de ne recourir au type wchar_t que si lefficacit
du programme compense largement le cot de la conversion de et vers le format wchar_t.
Quelques rgles
Faute de connatre les quelques contraintes qui psent sur les jeux de caractres multioctet
et le minimum de fonctions dinternationalisation qui liminent le problme, vous risquez
dcrire un programme dune remarquable lenteur. Voici quelques conseils :
Dans tous les jeux de caractres pris en charge par BULL, les codes 0x00 0x3F sont
uniques et rservs aux caractres ASCII standard. Etre unique signifie ici que ces
combinaisons napparaissent jamais comme lment du codage dun caractre
multioctet. Le caractre nul faisant partie de ce jeu, les fonctions strlen, strcpy et strcat
sappliquent aux chanes multi- et mono-octet. Le programmeur ne doit pas oublier que la
fonction strlen renvoie le nombre doctets de la chane et non le nombre de caractres.
De mme, la fonction de chane standard strchr(foostr, /) fonctionne
correctement dans tous les environnements, dans la mesure o le signe / (barre oblique)
fait partie dun intervalle du code unique. En ralit, la plupart des dlimiteurs standard
appartiennent lintervalle 0x00 0x3F, et lessentiel de lanalyse peut tre effectu sans
recours aux fonctions dinternationalisation ou la conversion au format wchar_t.
La comparaison entre chanes conduit une de deux relations : galit ou ingalit. Pour
un test dgalit, optez pour la fonction standard strcmp. En crivant :
if (strcmp(foostr,a rose) == 0)
nous ne recherchons pas le nom rose, mais cette combinaison exacte de bits.
Si foostr contient ros, cela ne nous intresse pas.
Les relations dingalit sont testes lorsquil sagit dordonner des chanes selon lordre
de tri dfini pour lenvironnement local. Pour ce faire, nous utilisons :
if (strcoll(foostr,barstr) > 0)
en tant conscient du cot de lopration de tri sur chaque caractre.
Tout programme excut (via exec) est toujours dmarr dans lenvironnement local C.
Sil doit faire appel une ou plusieurs fonctions dinternationalisation, dont des accs aux
catalogues de message, il doit excuter :
setlocale(LC_ALL, );
pour passer lenvironnement local de son processus parent avant tout appel une
fonction dinternationalisation.
Contrle de lenvironnement local

La squence de commandes :
LANG=C
export LANG
dfinit lenvironnement local par dfaut C (C est utilis, sauf spcification autre explicite
via une autre variable, telle LC_COLLATE).
La squence :
LC_ALL=C
export LC_ALL
force toutes les variables C, quelles que soient les dfinitions antrieures.
Pour un relev des valeurs actuelles des variables locales, tapez locale.
I-2
Voir aussi
Gestion des ressources AIX : gnralits.
Commande sort.
Support NLS (National Language Support)
I-3
I-4
Annexe J. Rcapitulatif des paramtres AIX

optimisables
Cette annexe donne la liste des paramtres qui ont une incidence sur les performances.
Cette liste est classe dans lordre alphabtique.
Augmentation de la tranche horaire

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre dimpulsions dhorloge de 10 millisecondes duquel augmenter

la tranche horaire par dfaut (10 millisecondes).
Par dfaut : Intervalle : 0 nimporte quel entier positif.
schedtune
La modification est immdiate. La modification est effective jusqu
lamorage systme suivant. Pour un changement permanent, ajoutez
la commande schedtune /etc/inittab.
schedtune t nouvelle-valeur
N/A.
Ce paramtre ne doit normalement pas tre modifi. Si la charge de
travail est constitue essentiellement de programmes longs et
gourmands en CPU, une augmentation de ce paramtre peut avoir un
effet positif.
Modification de la tranche horaire du programmateur, page 6-25.
arpt_killc
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Dlai avant suppression dune entre ARP inactive et termine.

Par dfaut : 20 (minutes). Intervalle : N/A.
no a ou no o arpt_killc
no o arpt_killc=nouvellevaleur
la commande no /etc/rc.net.
N/A.
Pour rduire lactivit ARP dans un rseau stable, vous pouvez
augmenter arpt_killc. Leffet est peu significatif.
N/A.
Rcapitulatif des paramtres AIX optimisables
J-1
Calcul de la priorit dun processus

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie la valeur de laugmentation de la priorit dun processus en

fonction de son utilisation rcente de CPU, et le taux de dcroissance
du temps dutilisation de CPU rcente. Ces paramtres sont appels r
et d.
Par dfaut : Intervalle : 0 32 (Remarque : Lors du calcul, les valeurs
de r et d sont divises par 32. Lintervalle rel des facteurs va ainsi de 0
1 par incrments de 0,03125.)
schedtune
schedtune r ou schedtune d
ps al Si vous constatez que la colonne PRI indique des priorits pour
les processus davant-plan (ceux qui ont des valeurs NI de 20)
suprieures aux valeurs PRI de certains processus darrire-plan
(valeurs NI > 20), vous devez peut-tre diminuer la valeur de r.
Diminuer r rend plus comptitifs les processus davant-plan. Diminuer d
vite aux processus davant-plan dtre en conflit plus longtemps avec
les processus darrire-plan. schedtune r 2 assure chaque nouveau
processus davant-plan au moins 0,5 secondes de temps CPU, avant
de le laisser en concurrence avec les autres processus dont NI >= 24.
Reportez-vous Optimisation du calcul de la priorit des processus
avec schedtune, page 6-23.
Compte biod
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-2
Nombre de processus biod disponibles pour grer les requtes NFS

sur un client.
ps ef | grep biod
chnfs b nouvellevaleur
Le changement prend effet immdiatement et est permanent.
Lindicateur N entrane un changement immdiat, mais temporaire
(perdu lamorage suivant). Lindicateur I entrane un changement
diffr lamorage suivant.
netstat s pour examiner les dpassements du tampon de socket UDP.
Augmentez le nombre jusqu liminer les dpassements.
Nombre de biod et de nfsd requis, page 9-36.
Dcompte nfsd
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de processus nfsd disponibles pour grer les requtes NFS

sur un serveur.
Par dfaut : Intervalle : 1 n
ps ef | grep nfsd
chnfs n nouvelle-valeur.
Lindicateur N entrane un changement immdiat, mais temporaire
(perdu lamorage suivant). Lindicateur I entrane un changement
diffr lamorage suivant.
netstat s pour examiner les dpassements du tampon de socket UDP.
Augmentez le nombre jusqu liminer les dpassements.
Nombre de biod et de nfsd requis, page 9-36.
dog_ticks
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Granularit de lhorloge pour les routines IfWatchdog. Cette valeur nest

pas utilise sous AIX.
Par dfaut : 60
N/A.
N/A.
N/A.
N/A.
N/A.
Intervalle de ressai fork()

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Dlai dattente avant relance dun fork ayant chou par manque
Par dfaut : 10 (impulsions dhorloge de 10 millisecondes). Intervalle :
10 n impulsions dhorloge.
schedtune
schedtune f nouvelle-valeur.
Si des processus ont t tus par manque despace de pagination,
surveillez la situation laide de la sous-routine sigdanger().
Si le manque despace de pagination est d des surcharges brves et
sporadiques, augmenter le delai de ressai peut entraner un
allongement du dlai dattente des processus permettant une libration
despace de pagination. Sinon, il convient dagrandir ces espaces.
N/A.
J-3
Intervalle syncd
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Dlai entre deux appels sync() par syncd.

Par dfaut : 60 (secondes). Intervalle : 1 nimporte quel entier positif.
grep syncd /sbin/rc.boot
vi /sbin/rc.boot
Le changement est diffr lamorage suivant, mais permanent.
N/A.
A sa valeur par dfaut, leffet de ce paramtre sur les performances est
ngligeable. Aucune modification conseille. Une diminution
significative de lintervalle syncd pour prserver lintgrit des
donnes peut avoir leffet inverse.
Performances et sync/fsync, page 8-21.
ipforwarding
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie si le noyau fait suivre les paquets IP.

Par dfaut : 0 (non). Intervalle : 0 1
no a ou no o ipforwarding
no o ipforwarding=nouvelle-valeur
N/A.
ll sagit dune dcision de configuration ayant un impact sur les
performances.
N/A.
ipfragttl
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-4
Dure de vie des fragments de paquets IP.

Par dfaut : 60 (demi-secondes). Intervalle : 60 n
no a ou no o ipfragttl
no o ipfragttl=nouvelle-valeur
netstat s
Si la valeur de IP: fragments dropped after timeout est non
nulle, augmenter ipfragttl peut rduire les retransmissions.
N/A.
ipqmaxlen
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre maximal dentres de la file dentre IP.

Par dfaut : Intervalle : 50 n
no a ou no o ipqmaxlen
no o ipqmaxlen =nouvelle-valeur
Utilisez la commande crash pour accder au compteur de
dpassement de la file dentre IP.
Augmentez la taille.
Optimisation des performances du protocole IP, page 9-23.
ipsendredirects
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie si le noyau envoie les signaux de racheminement.

Par dfaut : 1 (oui). Intervalle : 0 1
no a ou no o ipsendredirects
no o ipsendredirects=nouvelle-valeur
N/A.
N/A. ll sagit dune dcision de configuration ayant un impact sur les
performances.
N/A.
Limites des requtes en sortie sur une carte disque

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre maximal de requtes en sortie sur un bus SCSI (ne sapplique

qu la carte SCSI2 Fast/Wide).
Par dfaut : Intervalle : 40 128
lsattr E l scsin a num_cmd_elems
chdev l scsin a num_cmd_elems=nouvellevaleur i
Lindicateur T entrane un changement immdiat, mais perdu
lamorage suivant. Lindicateur P entrane un changement diffr
lamorage suivant, mais permanent.
N/A.
La valeur doit tre gale au nombre dunits physiques (y compris
celles se trouvant dans des piles de disques) situes sur le bus SCSI,
multipli par la longueur des files dattente sur chaque unit.
Limites de la file dattente de lunit de disque et de la carte SCSI,
page 8-23.
J-5
Longueur de file dattente dunit disque

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre maximal de requtes pouvant se trouver dans la file dattente

de lunit de disque.
Par dfaut : disques BULL = 3. Intervalle : N/A.
Par dfaut : disques non BULL = 0. Intervalle : spcifi par le fabricant.
lsattr E l hdiskn.
chdev l hdiskn a q_type=simple a queue_depth=nouvelle-valeur.
N/A.
Si le disque non BULL gre la mise des requtes en file dattente, ce
changement doit tre effectu pour garantir que le systme exploite
bien cette capacit.
Limites de la file dattente de lunit de disque et de la carte SCSI,
page 8-23.
loop_check_sum (version 3.2.5 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie si les totaux de contrle sont effectus et vrifis sur une

interface en boucle. (Cette fonction nexiste pas sous AIX version 4.1.)
no a ou no o loop_check_sum
no o loop_check_sum=0
N/A.
Nous vous conseillons de dsactiver la vrification des totaux de
contrle (loop_check_sum=0).
N/A.
lowclust (version 3.2.5 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-6
Spcifie le niveau bas du pool de grappes mbuf.

Par dfaut : dpend de la configuration. Intervalle : 5 n
no a ou no o lowclust
no o lowclust=nouvelle-valeur
netstat m
Si requests for memory denied est non nul, augmentez lowclust.
lowmbuf (version 3.2.5 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie le niveau bas du pool mbuf.

Par dfaut : dpend de la configuration. Intervalle : 64 n
no a ou no o lowmbuf
no o lowmbuf=nouvelle-valeur
netstat m
Si requests for memory denied est non nul, augmentez lowmbuf.
lvm_bufcnt (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de tampons LVM pour les E/S physiques brutes.

vmtune
vmtune u nouvelle-valeur
la commande vmtune /etc/inittab.
Les applications qui effectuent de longues critures sur des volumes
logiques bruts rpartis natteignent pas le dbit souhait.
Si un systme est configur avec des volumes logiques bruts rpartis et
effectue des critures de plus de 1,125 Mo, augmenter cette valeur peut
amliorer le dbit de lapplication.
Commande vmtune, page A-9.
maxrandwrt (AIX version 4.1.3 et ultrieure)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de pages de fichier sales accumuler en RAM avant quelles

soient synchronises sur disque via un algorithme dcriture diffre. Le
seuil dcriture diffre alatoire est dfini sur la base des fichiers.
Par dfaut : Intervalle : 0 128 (pages de 4 ko).
vmtune
vmtune W nouvelle-valeur.
vmstat n affiche les manques de page et les pointes dattente dE/S
intervalles rguliers (gnralement lorsque le dmon sync crit des
pages sur disque).
Si vmstat n affiche des manques de page et des pointes dattente dE/S
intervalles rguliers (gnralement lorsque le dmon sync crit des
pages sur le disque), rgler la valeur de maxrandwrt aide mieux
rpartir les E/S. La valeur 0 dsactive lcriture alatoire diffre.
Gestion AIX du stockage sur disques fixes, page 2-13 et la
commande vmtune, page A-9.
J-7
maxbuf
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de pages (4 ko) dans le cache tampon dE/S bloc.

Par dfaut : Intervalle : x y
lsattr E l sys0 a maxbuf
chdev l sys0 a maxbuf=nouvelle-valeur.
N/A.
Ce paramtre a normalement un effet ngligeable sur les performances
dun systme AIX, dans la mesure o les E/S ordinaires ne passent pas
par le cache tampon des E/S bloc.
N/A.
max_coalesce
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie la taille maximale, en octets, des requtes fusionnes par le

pilote dunit SCSI dans sa file dattente.
Par dfaut : ko. Intervalle : 64 ko 2 Go
odmget
odmdelete, odmadd, bosboot
Le changement est diffr lamorage suivant, mais permanent.
N/A.
Augmentez si des volumes logiques rpartis ou des piles de disques
sont utiliss.
Modification du paramtre max_coalesce du pilote SCSI, page 8-22.
maxfree
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-8
Taille maximale partir de laquelle la liste de trames de page

disponibles VMM crot par vol de page.
Par dfaut : dpend de la configuration. Intervalle : 16 204800
(trames de 4 ko).
vmtune
vmtune F nouvelle-valeur.
Examinez les changements intervenus au niveau de la taille de la liste
des disponibilits, via vmstat n.
Si vmstat n indique que cette taille passe frquemment en dessous de
minfree par le fait de demandes mises par des applications,
augmentez maxfree de faon rduire les appels la liste de
disponibilits remplie. Dune faon gnrale, maintenez
maxfree minfree <= 100.
Optimisation du remplacement de page VMM, page 7-16.
maxperm
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Pourcentage de trames de page mmoire occupes par des pages

permanentes, au-del duquel seules les pages permanentes voient leur
trames voles.
Par dfaut : % de (taille mmoire 4 Mo). Intervalle : 5 100
vmtune
vmtune P nouvelle-valeur.
Surveillez les E/S disque via iostat n.
Si vous savez que des fichiers sont lus rptitivement, mais que les
taux dE/S ne baissent pas depuis le lancement, maxperm est sans
doute trop bas.
maxpgahead
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Limite suprieure du nombre de pages lues par anticipation par VMM

lors du traitement dun fichier accs squentiel.
vmtune
vmtune R nouvelle-valeur.
Observez la dure dexcution des applications critiques au niveau des
E/S squentielles, via la commande time.
Si la dure dexcution diminue lorsque maxpgahead est plus lev,
tudiez les autres applications pour vrifier que leurs performances
nont pas souffert.
Optimisation des lectures squentielles anticipes, page 8-11.
maxpin (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Pourcentage maximal de mmoire relle susceptible dtre fixe.

Par dfaut : 80 (% de RAM). Intervalle : au moins 4 Mo fixable au
moins 4 Mo non fixable.
vmtune
vmtune M nouvelle-valeur.
lamorage systme suivant.
N/A.
Neffectuez de modification que dans des cas extrmes, tels que
lvaluation de la charge maximale.
J-9
maxpout
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie le nombre maximal dE/S en attente dun fichier.

Par dfaut : 0 (pas de contrle). Intervalle : 0 n (n tant un multiple de
4, augment de 1).
lsattr E l sys0 a maxpout
chdev l sys0 a maxpout=nouvelle-valeur.
Si les temps de rponse en avant-plan de programmes gnrant de
lourdes sorties squentielles sur disque se dgradent, il convient sans
doute de rguler les sorties squentielles.
Dfinissez maxpout 33 et minpout 16. Si les performances en
mode squentiel se dgradent de faon inacceptable, augmentez lun
ou lautre de ces paramtres, ou les deux. Si les performances en
avant-plan restent inacceptables, diminuez les deux.
maxttl
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Dure de vie des paquets RIP (Routing Information Protocol).

Par dfaut : Intervalle : N/A.
no a or no o maxttl
no o maxttl=nouvelle-valeur
N/A.
N/A.
N/A.
mb_cl_hiwat (version 3.2.5 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-10
Spcifie le niveau haut du pool de grappes mbuf.

Par dfaut : dpend de la configuration. Intervalle : N/A.
no a or no o mb_cl_hiwat
no o mb_cl_hiwat=nouvelle-valeur
netstat m
Si le nombre de grappes mbuf (appeles pages mappes par netstat)
est rgulirement suprieur mb_cl_hiwat, augmentez mb_cl_hiwat.
minfree
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Taille de la liste de trames de page VMM disponibles partir de laquelle

commence voler des pages pour remplir la liste de disponibilits.
Valeurs :
Par dfaut : dpend de la configuration. Intervalle : x nimporte quel
entier positif.
vmtune
vmtune f nouvelle-valeur
vmstat n.
Si des processus sont diffrs par le vol de page, augmentez minfree
pour amliorer les temps de rponse. Augmentez maxfree de la mme
valeur ou dune valeur suprieure.
minperm
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Pourcentage de trames de page occupes par des pages permanentes,

en de duquel VMM vole les trames des pages permanentes et des
pages de travail, quel que soit le taux de repages.
Par dfaut : % de (taille mmoire 4 Mo). Intervalle : 5 100
vmtune
vmtune P nouvelle-valeur.
Surveillez les E/S disque via iostat n.
Si vous savez que des fichiers sont lus rptitivement, mais que les
taux dE/S ne baissent pas depuis le lancement, minperm est sans
doute trop bas.
minpgahead
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de pages lues par anticipation par VMM ds quil dtecte un

accs squentiel.
vmtune
vmtune r nouvelle-valeur.
Observez la dure dexcution des applications critiques au niveau des
E/S squentielles, via la commande time.
Si la dure dexcution diminue lorsque minpgahead est plus lev,
tudiez les autres applications pour vrifier que leurs performances
nont pas souffert.
Optimisation des lectures squentielles anticipes, page 8-11.
J-11
minpout
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie le point partir duquel les programmes ayant atteint maxpout

peuvent reprendre lcriture dans le fichier.
Par dfaut : 0 (pas de contrle). Intervalle : 0 n (n tant un multiple de
4 et infrieur dau moins 4 maxpout).
lsattr E l sys0 a minpout
chdev l sys0 a minpout=nouvelle-valeur.
Si les temps de rponse en avant-plan de programmes gnrant de
lourdes sorties squentielles sur disque se dgradent, il convient sans
doute de rguler les sorties squentielles.
Dfinissez maxpout 33 et minpout 16. Si les performances en
mode squentiel se dgradent de faon inacceptable, augmentez lun
ou lautre de ces paramtres, ou les deux. Si les performances en
avant-plan restent inacceptables, diminuez les deux.
MTU
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-12
Limite la taille des paquets transmis via le rseau.

trn (4 Mo) : Par dfaut : 1492, Intervalle : 60 3900
trn (16 Mo) : Par dfaut : 1492, Intervalle : 60 17960
enn: Par dfaut : 1500, Intervalle : 60 1500
fin: Par dfaut : 4352, Intervalle : 60 4352
hin: Par dfaut : 65536, Intervalle : 60 65536
son: Par dfaut : 61428, Intervalle : 60 61428
lon: Par dfaut : 1500 (version 3.2.5) 16896 (AIX version 4.1),
Intervalle : 60 65536
lsattr E l trn
chdev l trn a mtu=nouvelle-valeur.
Ne peut tre modifi en cours dexploitation de linterface. Tous les
systmes du rseau local (LAN) devant tre dots du mme MTU, ils
doivent tre modifis simultanment. Le changement reste effectif
mme aprs ramorage.
Statistiques de fragmentation de paquets
Augmentez la taille MTU pour les interfaces en anneau jeton :
trn (4 Mo) : 4056
trn (16 Mo) : 8500
Pour linterface en boucle lon sous la version 3.2.5, augmentez
16896.
Pour les autres interfaces, conservez la valeur par dfaut.
nfs_chars (version 3.2.5), nfs_socketsize (AIX version 4.1)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Taille du tampon de socket UDP NFS.

Par dfaut : Intervalle : 60000 (sb_max 128).
nfso a ou nfso o nfs_chars (sous AIX version 4.1, nfso o
nfs_socketsize).
nfso o nfs_chars=nouvelle-valeur.
(sous AIX version 4.1, nfso o nfs_socketsize=nouvelle-valeur)
stopsrc g nfs.
startsrc g nfs
la commande nfso /etc/rc.nfs ou /etc/rc.net. sb_max doit dabord
tre modifi en consquence.
netstat s
Si le compte UDP: socket buffer overflows est non nul, augmentez
sb_max et nfs_chars.
Optimisation de NFS, page 9-36.
nfs_gather_threshold (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Taille minimale dune criture en veille avant synchronisation. Utilis

pour dsactiver la fragmentation/assemblage des critures sur le mme
vnode.
Par dfaut : Intervalle : x y
nfso a ou nfso o nfs_gather_threshold
nfso o nfs_gather_threshold=nouvelle-valeur
N/A.
N/A.
N/A.
nfs_portmon (version 3.2.5), portcheck (AIX version 4.1)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie si NFS opre un contrle, que les requtes soient issues ou

non de ports privilgis.
nfso a ou nfso o nfs_portmon
nfso o nfs_portmon=nouvelle-valeur
la commande nfso /etc/rc.nfs.
N/A.
ll sagit dune dcision de configuration ayant un impact minimal sur les
performances.
N/A.
J-13
nfs_repeat_messages (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie si les messages crits par NFS doivent tre rpts.

nfso a ou nfso o nfs_repeat_messages
nfso o nfs_repeat_messages=nouvelle-valeur
N/A.
N/A.
N/A.
nfs_setattr_error (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Spcifie si NFS ignore les erreurs NFS dues des dfinitions dattributs
PC illgaux.
nfso a
nfso o nfs_setattr_error=nouvelle-valeur
N/A.
N/A.
N/A.
nfsudpcksum (version 3.2.5), udpchecksum (AIX version 4.1)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-14
Spcifie si NFS effectue le total de contrle UDP.

nfso a or nfso o nfsudpcksum
nfso o nfsudpcksum=nouvelle-valeur
la commande nfso /etc/rc.nfs.
N/A.
Dsactiver le calcul du total de contrle peut rduire le temps de
traitement, mais augmente le risque derreurs de donnes non
dtectes.
N/A.
nonlocsrcroute
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Indique que les paquets IP achemins strictement depuis la source

peuvent tre adresss des htes hors de lanneau local. (Le routage
depuis une source non stricte nest pas affect.)
no a or no o nonlocsrcroute
no o nonlocsrcroute=nouvelle-valeur
N/A.
performances.
N/A.
npskill (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de pages libres de lespace de pagination, partir duquel les

processus commencent tre tus.
Par dfaut : Intervalle : 0 au nombre de pages en mmoire relle.
vmtune
vmtune k nouvelle-valeur
N/A.
N/A.
npswarn (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de pages libres de lespace de pagination, partir duquel les

processus commencent recevoir SIGDANGER.
Par dfaut : Intervalle : au moins npskill pour le nombre de pages en
mmoire relle.
vmtune
vmtune w nouvelle-valeur
N/A.
Augmentez si vous constatez que des processus ont t tus par
insuffisance despace de pagination.
J-15
numclust (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de grappes de 16 ko traites en criture diffre.

vmtune
vmtune c nouvelle-valeur
N/A.
Augmentez ventuellement si des volumes logiques rpartis ou des
piles de disques sont utiliss.
numfsbuf (AIX version 4.1 seulement)

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de systmes de fichiers bufstruct.

vmtune
vmtune b nouvelle-valeur
N/A.
Augmentez ventuellement si des volumes logiques rpartis ou des
piles de disques sont utiliss.
Paramtres de contrle de charge mmoire

Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
J-16
Personnalise lutilitaire de contrle de la charge mmoire VMM pour

maximiser lutilisation du systme tout en vitant lemballement. Les
paramtres les plus utiliss sont :
h
seuil de surcharge de la mmoire haute.
p
seuil de surcharge mmoire par les processus.
m
niveau de multiprogrammation minimal.
h Valeur par dfaut : Intervalle : 0 nimporte quel entier positif.
p Valeur par dfaut : Intervalle : 0 nimporte quel entier positif.
m Valeur par dfaut : Intervalle : 0 nimporte quel entier positif.
schedtune
schedtune [h nouvelle-valeur] [p nouvelle-valeur] [m
nouvelle-valeur]
De lourdes charges mmoire peuvent induire dimportants carts au
niveau des temps de rponse.
Optimisation :
Voir :
schedtune h 0 dsactive le contrle de la charge mmoire.

schedtune p 2 requiert un niveau plus lev de repagination par un
processus donn, avant quil ne soit candidat tre suspendu par le
contrle de charge mmoire.
schedtune m 10 requiert que le contrle de charge mmoire
maintienne au moins 10 processus utilisateur actifs lorsquil suspend
des processus.
Utilitaire de contrle de charge mmoire, page 2-8 et Optimisation du
contrle de charge mmoire VMM, page 7-14.
pd_npages
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Nombre de pages supprimer dun coup de la RAM lorsquun fichier

est supprim.
Valeur par dfaut :taille du plus grand fichier / taille de page. Intervalle :
1 taille du plus grand fichier / taille de page
vmtune
vmtune N nouvelle-valeur
Cette option est utile si une application en temps rel voit son temps de
rponse singulirement ralenti pendant la suppression de gros fichiers.
Si le temps rel de rponse est un lment critique, rgler cette option
peut lamliorer en rpartissant la suppression des pages de fichier de
la RAM plus uniformment par rapport la charge de travail.
rec_que_size
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
(optimisable sous AIX version 3 exclusivement). Spcifie le nombre

maximal de tampons de rception qui peuvent tre en file dattente pour
linterface.
lsattr E l tokn a rec_que_size
ifconfig tr0 detach
chdev I tokn a rec_que_size=nouvelle-valeur.
Le changement reste effectif mme aprs ramorage.
N/A.
Augmentez la taille. Doit tre naturellement dfinie 150 sur les
systmes orients rseau, et notamment les serveurs.
rfc1122addrchk
Objet :
Valeurs :
Affichage :
Modification :
Spcifie si la validation dadresse est effectue entre les couches de

communication.
no a ou no o rfc1122addrchk
no o rfc1122addrchk=nouvelle-valeur
J-17
Diagnostics :
Optimisation :
Voir :
N/A.
Cette valeur ne doit pas tre modifie.
N/A.
Objet :
1 indique que tcp_sendspace et tcp_recvspace peuvent dpasser

64 ko.
Par dfaut : Intervalle : 0 ou 1
no a ou no o rfc1323
no o rfc1323=nouvelle-valeur
Aucun.
Effectuez la modification avant de tenter de donner tcp_sendspace
et tcp_recvspace une valeur suprieure 64 ko.
Couche TCP, page 9-6.
rfc1323
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
sb_max
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Limite suprieure absolue de la taille des tampons de socket TCP et

UDP. Limite setsockopt(), udp_sendspace, udp_recvspace,
tcp_sendspace et tcp_recvspace.
no a ou no o sb_max
no o sb_max=nouvelle-valeur
La modification est immdiate pour les nouvelles connexions. La
modification est effective jusqu lamorage systme suivant. Pour un
changement permanent, ajoutez la commande no /etc/rc.net.
Aucun.
Augmentez la taille, de prfrence un multiple de 4 096. Doit tre
environ double de la limite du plus grand tampon de socket.
subnetsarelocal
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
J-18
Spcifie que tous les sous-rseaux conformes ce masque doivent

tre considrs comme locaux, pour des oprations telles que
ltablissement, par exemple, de la taille maximale de segment TCP.
no a ou no o subnetsarelocal
no o subnetsarelocal=nouvelle-valeur
N/A.
Optimisation :
Voir :
ll sagit dune dcision de configuration ayant un impact sur les

performances. Si les sous-rseaux nont pas tous le mme MTU, la
fragmentation au niveau des ponts peut entraner une dgradation des
performances. Sils ont tous le mme MTU, et que subnetsarelocal
vaut 0, les sessions TCP risquent dutiliser inutilement un MSS trop
petit.
Optimisation de la taille maximum de segment (MSS) TCP, page 9-21.
Taille de lespace de pagination

Objet :
Quantit despace disque requise pour les pages de travail.
Valeurs :
Par dfaut : dpend de la configuration. Intervalle : 32 Mo n Mo pour

hd6, 16 Mo n Mo pour non hd6
lsps a
mkps ou chps ou smit pgsp
La modification est immdiate et est permanente. Lespace de
pagination nest toutefois pas forcment mis en service immdiatement.
lsps a. Si des processus ont t tus par insuffisance despace de
pagination, surveillez la situation laide de la sous-routine psdanger().
Sil apparat que lespace de pagination est insuffisant pour grer la
charge de travail normale, ajoutez un nouvel espace sur un autre
volume physique ou agrandissez lespace existant.
Position et taille des espaces de pagination, page 4-26.
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
tcp_keepidle
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Dlai total pendant lequel conserver active une connexion TCP

inoccupe.
Par dfaut : 14400 (demi-secondes) = 2 heures. Intervalle : tout entier
positif.
no a ou no o tcp_keepidle
no o tcp_keepidle=nouvelle-valeur
N/A.
performances. Aucune modification conseille.
N/A.
tcp_keepintvl
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Intervalle entre les paquets envoys pour valider la connexion TCP.

Par dfaut : 150 (demi-secondes) = 75 secondes. Intervalle : tout entier
positif.
no a ou no o tcp_keepintvl
no o tcp_keepintvl=nouvelle-valeur
N/A.
J-19
Optimisation :
Voir :

performances. Aucune modification conseille. Si lintervalle est
srieusement raccourci, les cots en matire de traitement et de largeur
de bande peuvent devenir significatifs.
N/A.
tcp_mssdflt
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Taille de segment maximale utilise par dfaut pour communiquer avec

les rseaux distants.
Par dfaut : Intervalle : 512 (MTU de rseau local 64).
no a ou no o tcp_mssdflt
no o tcp_mssdflt=nouvelle-valeur
N/A.
Augmentez, si vous le souhaitez.
Optimisation de la taille maximum de segment (MSS) TCP, page 9-21.
tcp_recvspace
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Valeur par dfaut de la taille du tampon de rception du socket TCP.

Par dfaut : Intervalle : 0 64 ko si rfc1323=0,
Doit tre gal tcp_sendspace et uniforme sur tous les systmes AIX
no a ou no o tcp_recvspace
no o tcp_recvspace=nouvelle-valeur
Dbit faible
Augmentez la taille, de prfrence un multiple de 4 096.
tcp_sendspace
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-20
Valeur par dfaut de la taille du tampon denvoi du socket TCP.

Par dfaut : Intervalle : 0 64 ko si rfc1323=0,
Doit tre gal tcp_recvspace et uniforme sur tous les systmes AIX
no a ou no o tcp_sendspace
no o tcp_sendspace=nouvelle-valeur
Dbit faible
tcp_ttl
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Dure de vie des paquets TCP.

Par dfaut : 60 (impulsions de processeur de 10 millisecondes). tout
entier positif.
Affichage : no a ou no o tcp_ttl
no o tcp_ttl=nouvelle-valeur
netstat s
Si le systme subit des dpassements de dlai TCP, augmenter tcp_ttl
peut rduire le nombre de retransmissions.
N/A.
thewall
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Limite suprieure absolue de la quantit de mmoire relle susceptible

dtre utilise par le sous-systme de communication.
Par dfaut : % de la mmoire relle. Intervalle : 0 50 % de la
mmoire relle.
no a ou no o thewall
no o thewall=nouvelle-valeur
nouvelle-valeur est en ko, et non en octets. La modification est
immdiate pour les nouvelles connexions. La modification est effective
jusqu lamorage systme suivant. Pour un changement permanent,
ajoutez la commande no /etc/rc.net.
Aucun.
Augmentez la taille, de prfrence un multiple de 4 ko.
udp_recvspace
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Valeur par dfaut de la taille du tampon de rception du socket UDP.

no a ou no o udp_recvspace
no o udp_recvspace=nouvelle-valeur
n non nul dans le compte rendu de netstat s de udp: n socket buffer
overflows
J-21
udp_sendspace
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Valeur par dfaut de la taille du tampon denvoi du socket UDP.

no a ou no o udp_sendspace
no o udp_sendspace=nouvelle-valeur
N/A.
udp_ttl
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
Dure de vie des paquets UDP.

Par dfaut : 30 (impulsions dhorloge de 10 millisecondes). Intervalle :
tout entier positif.
no a ou no o udp_ttl
no o udp_ttl=nouvelle-valeur
N/A.
N/A.
N/A.
xmt_que_size
Objet :
Valeurs :
Affichage :
Modification :
Diagnostics :
Optimisation :
Voir :
J-22
Spcifie le nombre maximal de tampons denvoi susceptibles dtre en

file dattente pour lunit.
lsattr E l tok0 a xmt_que_size
ifconfig tr0 detach
chdev I tok0 a xmt_que_size=nouvelle-valeur
Le changement reste effectif mme aprs ramorage.
netstat i
Oerr > 0
Augmentez la taille. Doit tre naturellement dfinie 150 sur les
systmes orients rseau, et notamment les serveurs.
Index
Symboles
#pragma isolated_call, 4-17
#pragma pour programme C, 4-16
A
activit systme, analyse avec lutilitaire de suivi,
11-1
affectation anticipe des emplacements despace
de pagination, 2-11
algorithme de remplacement de page, 2-8
optimisation, 7-16
anneau jeton
(16 Mo) conseils doptimisation, 9-24
(4 Mo) conseils doptimisation, 9-24
applications dpendantes du disque, 12-25
ATM, conseils doptimisation, 9-25
B
bibliothques, G-1
bibliothques de sousroutines, D-1
bibliothques partages, G-1
valuation de lutilisation de la CPU, 6-15
bote outils, disponibilit, A-1
Bote outils AIX, disponibilit, A-1
Bote outils Performance Toolbox (PTX), 12-16
disponibilit, A-1
C
cache
absence, 1-4
architecture, C-1
en mappage direct, C-3
prsence, 1-4
absence, C-3
utilisation efficace, 4-11
caractre, multioctet, I-1
cartes, conseils doptimisation, 9-13
charge dune station de travail, 1-7
charge de travail
multiutilisateur, 1-7
serveur, 1-7
charge de travail du serveur, 1-7
charge de travail multiutilisateur, 1-7
charge de travail., identification, 1-8
codage
prprocesseur et compilateur, 4-14
sousroutine string, 4-18
style C et C++ efficace, 4-19
style de code paginable, utilisation efficace,
4-21
utilisation efficace de la mmoire cache, 4-11
cohrence de lcriture miroir, 4-27
commande filemon, 8-8
disponibilit, 8-8
commande iostat
contrle des performances, 5-3
exemple de rapport rcapitulatif, 12-24
exemple du script shell, 8-2

commande ipreport, 9-61
commande lockstat, 12-24
commande netpmon, 9-59
disponibilit, 9-59
commande netstat
m (option pour rendre compte de lutilisation
des mbuf), 9-28
optimisation des pools mbuf, 9-27
commande nice, 2-3
clarification de la syntaxe, 6-22
exemple, 6-20
commande ou sousroutine sync, 8-21
commande ps
affichage de la priorit dun processus, 6-21
compterendu mmoire, 7-2
commande renice, 2-3
clarification de la syntaxe, 6-22
exemple, 6-22
commande rmss
changement de la taille effective de la
machine, 12-27
exemple, 7-6, 7-8
simulation de taille mmoire, 7-6
commande schedtune, 7-15, A-6
avertissement, 7-14
incrmentation de la tranche horaire, 2-4, 6-25
commande svmon, exemple, 7-3
commande time, mesure de lutilisation de la CPU,
6-3
commande tprof exemple, exemple dtaill, 6-10
commande vmstat
compte rendu des activits CPU et dE/S.,
12-23
compte rendu mmoire, 7-2, 12-25
contrle de lutilisation de la CPU, 6-2
commande vmtune, A-9
avertissement, 7-16
utilisation, 7-16
communications, 9-59
rcapitulatif des conseils dinstallation et
doptimisation, 9-31
compilation, propre une architecture, 4-15
compilation propre une architecture, 4-15
compression, systme de fichiers, 8-18
compte rendu de problme, 13-1
compte rendu de problme AIX, 13-1
conditions lies aux performances, 4-2
conditions requises
performances, 4-2
ressource, 4-3
configuration
conseils relatifs aux disques, 4-24
enregistrement des performances de base
avant modification, 12-22
Index
X-1
taille et position des espaces de pagination,

4-26
connexions async
optimisation des entres grande vitesse, 9-54
scipt fastport, 9-58
conseils doptimisation
anneau jeton (16 Mo), 9-24
anneau jeton (4 Mo), 9-24
ATM, 9-25
cartes, 9-13
Ethernet, 9-23
FDDI, 9-24
files dattente de rception, 9-14
files dattente de rception , 9-14
files dattente de transmission, 9-13
HIPPI, 9-25
IP, 9-23
SOCC, 9-25
TCP, UDP, 9-12
contrle
continu, 5-2
surcharge, E-1
via iostat, netstat et/ou vmstat, 5-3
contrle de charge mmoire
commande schedtune, A-6
description, 2-8
optimisation de grandes mmoires relles,
7-15
rcapitulatif des paramtres, J-16
contrle de charge mmoire VMM, 7-14
couche interface (IF)
flux denvoi, 9-11
flux de rception, 9-11
CPU, 2-4
cycles par instruction, 1-6
D
dbit, 1-2
dcharger, 2-7
dfaut de page
exemple, 1-4
nouvelle, 2-7
repagination, 2-7
dfaut de page dj rfrence, 2-7
dmon biod, 9-36, J-2
dmon nfsd, 9-36, J-3
directive #pragma disjoint, 4-16
disque fixe, 4-24
disques
affectation de fragment, 8-17
commande filemon, 8-8
compression de systme de fichiers, 8-18
criture diffre, 2-15
espace de pagination, 4-26
valuation des performances avec iostat, 8-2
extension et amlioration de la configuration,
8-10
fichiers mapps, 2-15
fragmentation, 2-14
rduction, 8-5
gnralits sur la gestion, 2-13
groupe de volumes (VG), 2-13
lecture anticipe, 2-14
X-2
limites des requtes en sortie sur une carte,

J-5
optimisation des lectures squentielles
anticipes, 8-11
partition logique (LP), 2-13
partition physique (PP), 2-13
placement physique dun fichier, 8-4
placement physique dun volume logique, 8-3
planification de la configuration physique et
logique, 4-24
profondeur de file dattente, J-6
rgulation des E/S, 2-16, 8-13
paramtre maxpout, J-10
paramtre minpout, J-12
rorganisation, 8-5, 8-6
rpartition, 8-15
sync/fsync, 8-21
systme de fichiers journalis (JFS), 2-14
taille de bloc, 2-14
unit brute, 8-20
vrification de lcriture, 4-27
vitesses relatives, 4-24
volume logique (LV)
cohrence de lcriture miroir, 4-27
dfinition, 2-13
volume physique (PV), 2-13
dog_ticks, J-3
E
criture diffre, 2-15
diteur de liens, D-1
dition de liens des bibliothques de
sousroutines, D-1
emballement, limination, 7-14
entre a.out vers la commande ld, D-1
environnement local, I-1
espace de pagination, 2-6
affectation anticipe des emplacements, 2-11
espace de pagination insuffisant paramtre
de ressai, A-8, J-3
postaffectation des emplacements, 2-11
sousroutine psdanger(), 4-26
taille, J-19
taille et position, 4-26
essai comparatif, standard de lindustrie, 1-2
Ethernet, conseils doptimisation, 9-23
excution de la commande cc, 4-20
excution de la commande xlc, temps de latence,
4-20
exploitation par blocs, 4-14
F
FDDI, conseils doptimisation, 9-24
fichier excutable, D-1
fichiers, 2-15
files dattente de rception, 9-14
files dattente de rception , 9-14
files dattente de transmission, 9-13
fork, intervalle de ressai, J-3
fragment, systme de fichiers, 8-17
fragmentation, disque, 8-5
G
gestion de la charge de travail, 12-29
gestionnaire de mmoire virtuelle (VMM)
dfinition, 2-5
description, 1-6
Gestionnaire des volumes logiques (LVM), 1-6
grappe
description, 9-26
lowclust, 9-26
mb_cl_hiwat, 9-27
mbuf, 9-3
grappe mbuf, 9-3, 9-26
groupe de volumes (VG), 2-13
H
HIPPI, conseils doptimisation, 9-25
horloge (matrielle), accs, H-1
I
identification des ressources limitatives, 12-23
ILS (International Language Support), I-1
astuces de codage, I-2
variable denvironnement
LANG, I-2
LC_ALL, I-2
installation
conseils de configuration dinstallation, 4-23
conseils relatifs aux disques, 4-24
Interphase Network Coprocessor, 9-40
intervalle de scurit, 2-9
intervalle syncd, J-4
intrusion, des outils de performance, E-1
IP
conseils doptimisation, 9-23
flux denvoi, 9-10
maxttl, J-10
paramtre ipforwarding, J-4
paramtre ipfragttl, J-4
paramtre ipqmaxlen, J-5
paramtre ipsendredirects, J-5
paramtre nonlocsrcroute, J-15
prsentation fonctionnelle, 9-10
ipqmaxlen, rcapitulatif, 9-33
iptrace
exemple de sortie, 9-61, 9-62
formatage du rapport, 9-61
lancement et arrt, 9-61
problmes de performances, 9-61
L
LANG, I-2
latence de recherche, 1-3
LC_ALL, I-2
ld (diteur de liens), D-1
lecture anticipe, 2-14, 8-11
lectures squentielles anticipes, 8-11
libc.a, 6-15
liste des disponibilits, 2-6
modification de la taille, 7-16
paramtre maxfree, J-8
paramtre minfree, J-11
localit de rfrence, exemple, 1-6

longueur du parcours, 1-6
lowclust, 9-26, J-6
lowmbuf, 9-26, J-7
M
malloc
affectation des emplacements de lespace de
pagination, 2-11
AIX 3.1 et AIX 3.2, F-1
perte de mmoire., 7-4
maxbuf, J-8
maxperm, J-9
modification, 7-17
prsentation, 2-8
maxpgahead, J-9
maxpout, J-10
mb_cl_hiwat, 9-27
mbuf
description, 9-26
gnralits sur la gestion, 9-3
lowclust, 9-26, J-6
lowmbuf, 9-26, J-7
mb_cl_hiwat, 9-27, J-10
vrification de la taille actuelle du pool, 9-30
mmoire
de calcul, 2-7
valuation des besoins dune application, 7-8
fichier, 2-7
rduction de la taille, 12-27
mmoire fixe, 4-22
minperm, J-11
modification, 7-17
prsentation, 2-8
minpgahead, J-11
minpout, J-12
MTU, 9-35, J-12
N
National Language Support (NLS), I-1
NFS
acclrateurs matriels, 9-40
cache dattribut de fichier, 9-38
compte biod, J-2
configuration du disque du serveur, 4-24
mise en cache de donnes, 9-39
montage logiciel et matriel, 9-37
nombre de biods et de nfsds, 9-36
paramtre nfs_chars, J-13
paramtre nfs_gather_threshold, J-13
paramtre nfs_portmon, J-13
paramtre nfs_repeat_messages, J-14
paramtre nfs_setattr_error, J-14
paramtre nfs_udpcksum, J-14
paramtre timeo, 9-38
prsentation, 9-36
relation avec les couches infrieures, 9-39
support ACL, 9-39
taille du tampon socket, 9-39
Index
X-3
O
optimisation
compilateur XL, 4-14
effet sur la vitesse du compilateur, 4-20
niveau, 4-18
propre une architecture, 4-15
optimisation de DFS, 10-1
optimisation des performances, tapes, 1-8
optimisation des performances du systme, tapes
du processus, 1-8
outil BigFoot, 7-5
outil STEM, exemple danalyse du flux de
commande, 6-17
outils doptimisation, A-3
outils de performance, A-1, A-3
outils de rapport et danalyse, A-1
P
pages, 2-5
paramtres, optimisables, rcapitulatif, J-1
paramtres AIX optimisables, rcapitulatif, J-1
paramtres doptimisation UDP, TCP/IP et mbuf,
9-31
partie active (dfinition), 4-12
partition logique (LP), 2-13
partition physique (PP), 2-13
performances de la sousroutine printf, 6-16
PerfPMR
capture des donnes, 13-4
diagnostic des performances, 12-21
installation, 13-3
pour AIX version 3, 13-2
rapport dun possible dfaut de performance
AIX, 13-1
pile de disques, 2-16
pilote de la carte LAN
flux denvoi, 9-11
placement sur le disque, 8-3
points critiques de la CPU, recherche dans un
programme, 6-10
politique de planification, 2-2
porte concurrentielle, 2-2
porte concurrentielle globale, 2-2
porte concurrentielle locale, 2-2
position sur le disque, 8-3
postaffectation des emplacements despace de
pagination, 2-11
POWER (architecture), 4-15
pragma, 4-16
Prestoserve, 9-40
priorit
affichage via ps, 6-21
commande nice, 2-3
commande renice, 2-3
composant
minimum routine utilisateur, 2-3
utilisation de la CPU, 2-3
valeur nice, 2-3
excution dune commande avec nice, 6-20
fixe, 2-3
affichage via ps, 6-21
X-4
dfinition via setpri, 6-20

modification via renice, 6-22
optimisation de lalgorithme de calcul, J-2
sousroutine setpri, 2-3
valeur de priorit, 2-3
variable, 2-3, 6-20
priorit fixe, 2-3
priorit variable, 2-3
prise en charge de routines, prsentation, 2-2
processeur
accs lhorloge matrielle du processeur, H-1
contrle des conflits via la priorit, 6-20
contrle via vmstat, 6-2
mesure de lutilisation via la commande time,
6-3
profilage des zones critiques, 6-10
schma dadressage virtuel, C-1
tranche horaire, 2-4, 6-25
programmateur, 2-2
programme de chargement, 1-5
PTX, disponibilit, A-1
R
RAID, 2-16
RAM, mesur des besoins via rmss, 7-8
rec_que_size, J-17
rcapitulatif, 9-34
rdition des liens de fichiers excutables, D-1
registres de segment, C-2
regroupement rfrentiel, dfinition, 4-12
rgulation, 2-16
E/S disque, 8-13
rgulation des E/S, 2-16, 8-13
remplacement de page, A-9
rorganisation des donnes sur disque, 8-5
rpartition, 8-15
rpartition des volumes logiques, 8-15
rseau
commande netpmon, 9-59
iptrace, 9-61
paramtre arpt_killc, J-1
paramtre loop_check_sum, J-6
rsolution de chemins daccs, 9-42
rsolution de problmes de performances
communications, 9-1
CPU, 6-1
disque, 8-1
gnralits, 12-17
mmoire, 7-1
ressource
critique, 1-9
valuation, 4-3, 4-7
logique, 1-9
mesure, 4-4
relle, 1-9
supplmentaire, 1-11, 8-10
ressource critique, 1-9
rfc1122addrchk, J-17
rfc1323, J-18
rcapitulatif, 9-32
routine
politique de planification, 2-2
porte concurrentielle, 2-2
porte concurrentielle globale, 2-2

porte concurrentielle locale, 2-2
routine initiale, 3-11
S
saturation de la file dentre IP, 9-23
saturation des files dentre IP, 9-23
sb_max, J-18
rcapitulatif, 9-32
script pdt_config, A-12
script pdt_report, A-13
script shell vmstatit, 12-25
segment, mmoire virtuelle, associatif quatre
voies, C-2
segment diffr
client, 2-6
de travail, 2-6
dcharger, 2-6
journalis, 2-6
persistant, 2-6, 2-14
SMIT
cration dun port TTY, 9-58
dfinition des paramtres de rgulation des
E/S disque, 8-13
nombre de dmons nfsd lanc au dmarrage,
9-47
SOCC, conseils doptimisation, 9-25
socket
cration, 9-4
flux denvoi, 9-4
limite de la taille du tampon, 9-3
taille du tampon, 9-39
sockthresh, rcapitulatif, 9-31
sort, performance en environnement local C et non
C, I-1
sousroutine free
limination des pertes de mmoire, 7-4
utilisation inutile, 7-4
sousroutine fsync, 8-21
sousroutine psdanger(), 4-26
sousroutine realloc, 7-4, F-1
sousroutine setpri, 2-3
exemple, 6-20
sousroutine string, 4-18
sousroutine trcstart, 11-7
station de travail sans disque, 9-41
activit NFS pour excution dun programme
simple, 9-42
cart de performances avec les systmes
disque, 9-48
pagination via NFS, 9-44
remarques sur loptimisation, 9-46
ressources requises, 9-45
statistiques de pagination, 12-26
subnetsarelocal, J-18
surcharge, des outils de contrle, E-1
System Management Interface Tool, 9-47
systme de fichiers journalis (JFS), 2-14
T
tableaux
C, 6-13
structure du stockage, C-5
tableaux C, 6-13
tampon historique des pages dj rfrences, 2-7
tampon TLB (Translation Lookaside Buffer)
absence
RAM, 1-4
remplissage de ligne, C-4
prsence, C-4
TCP
fentre (illustration), 9-6
flux denvoi, 9-9
TCP/IP, 9-6, 9-10
illustration du flux de donnes, 9-2
iptrace, 9-61
tcp_keepidle, J-19
tcp_keepintvl, J-19
tcp_mssdflt, J-20
tcp_recvspace, J-20
rcapitulatif, 9-33
tcp_sendspace, J-20
rcapitulatif, 9-33
tcp_ttl, J-21
temps de latence
dfinition, 1-3
recherche, 1-3
rotationnelle, 1-3
temps de rponse, 1-2
thewall, J-21
rcapitulatif, 9-31
thewall (description), 9-27
TLB, 1-4
trace
ajout dvnements, 11-9
appels ioctl de contrle, 11-7
canaux, 11-9
commandes de contrle, 11-6
exemple dvnement utilisateur, 11-11
format article vnement, 11-9
ID vnement, 11-10
macros, 11-10
souscommande, 11-6
sousroutines de contrle, 11-7
syntaxe de la strophe de fichier de format,
11-13
utilitaire, 11-1
tranche horaire, 2-4
augmentation, J-1
effet, 2-4
modification via schedtune, 2-4, 6-25
U
UDP
flux denvoi, 9-6
illustration du flux de donnes, 9-2
udp_recvspace, J-21
rcapitulatif, 9-32
udp_sendspace, J-22
rcapitulatif, 9-32
udp_ttl, J-22
Index
X-5
units brutes, disque, 8-20

utilisation de la CPU, 2-3
V
valeur nice, 2-3
variable denvironnement
LANG, I-2
LC_ALL, I-2
MALLOCTYPE, F-1
PATH, 9-44
variable denvironnement MALLOCTYPE, F-1
X-6
vrification de lcriture, 4-27

vitesse du compilateur, 4-20
vitesse du compilateur C, 4-20
vmtune, prsentation, 2-7
volume logique (LV), 2-13
volume physique (PV), 2-13
X
xmt_que_size, J-22
rcapitulatif, 9-34
Vos remarques sur ce document / Technical publication remark form

Titre / Title :
Bull AIX 4.3 Guide doptimisation
N Rfrence / Reference N :
86 F2 72AP 04
Dat / Dated :
Octobre 1999
ERREURS DETECTEES / ERRORS IN PUBLICATION
AMELIORATIONS SUGGEREES / SUGGESTIONS FOR IMPROVEMENT TO PUBLICATION
Vos remarques et suggestions seront examines attentivement.

Si vous dsirez une rponse crite, veuillez indiquer ci-aprs votre adresse postale complte.
Your comments will be promptly investigated by qualified technical personnel and action will be taken as required.
If you require a written reply, please furnish your complete mailing address below.
NOM / NAME :
SOCIETE / COMPANY :
ADRESSE / ADDRESS :
Remettez cet imprim un responsable BULL ou envoyez-le directement :

Please give this technical publication remark form to your BULL representative or mail to:

CEDOC
FRANCE
Date :
Technical Publications Ordering Form

Bon de Commande de Documents Techniques
To order additional publications, please fill up a copy of this form and send it via mail to:
Pour commander des documents techniques, remplissez une copie de ce formulaire et envoyez-la :

CEDOC
ATTN / MME DUMOULIN
FRANCE
Managers / Gestionnaires :
Mrs. / Mme :
C. DUMOULIN
Mr. / M :
L. CHERUBIN
+33 (0) 2 41 73 76 65
+33 (0) 2 41 73 63 96
FAX :
EMail / Courrier Electronique :
+33 (0) 2 41 73 60 19
srv.Cedoc@franp.bull.fr
Or visit our web site at: / Ou visitez notre site web :

http://wwwfrec.bull.com
(PUBLICATIONS, Technical Literature, Ordering Form)
CEDOC Reference #
No Rfrence CEDOC
Qty
Qt
CEDOC Reference #
No Rfrence CEDOC
Qty
Qt
CEDOC Reference #
No Rfrence CEDOC
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
__ __ ____ _ [__]
Qty
Qt
[ _ _ ] : no revision number means latest revision / pas de numro de rvision signifie rvision la plus rcente
NOM / NAME :
Date :
SOCIETE / COMPANY :
ADRESSE / ADDRESS :
TELEPHONE / PHONE :
FAX :
EMAIL :
For Bull Subsidiaries / Pour les Filiales Bull :

Identification:
For Bull Affiliated Customers / Pour les Clients Affilis Bull :
Customer Code / Code Client :
For Bull Internal Customers / Pour les Clients Internes Bull :
Budgetary Section / Section Budgtaire :
For Others / Pour les Autres :
Please ask your Bull representative. / Merci de demander votre contact Bull.
86 F2 72AP 04
PLACE BAR CODE IN LOWER

LEFT CORNER

CEDOC
FRANCE
Utiliser les marques de dcoupe pour obtenir les tiquettes.

Use the cut marks to get the labels.
AIX
AIX 4.3
Guide
doptimisation
86 F2 72AP 04
AIX
AIX 4.3
Guide
doptimisation
86 F2 72AP 04
AIX
AIX 4.3
Guide
doptimisation
86 F2 72AP 04

AIX 4.3 Guide D'optimisation 86F272AP04

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AIX 4.3 Guide D'optimisation 86F272AP04

Загружено:

Авторское право:

Доступные форматы

Bull

AIX 4.3 Guide doptimisation

BULL ELECTRONICS ANGERS

Bull S.A. 1992, 1999

Table des matires

Chapitre 2. Gestion des ressources AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 3. Introduction au multitraitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Charge de travail dun SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 4. Planification, conception et implantation . . . . . . . . . . . . . . . . . . . . . .

Chapitre 5. Contrle systme et diagnostics des performances . . . . . . . . . . . .

Chapitre 6. Contrle et optimisation de la CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . .

AIX 4.3 Guide doptimisation

Modification de la tranche horaire du programmateur . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 7. Contrle et optimisation de la mmoire . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 8. Contrle et optimisation des E/S disque . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 9. Contrle et optimisation des E/S de communication . . . . . . . . . . . .

AIX 4.3 Guide doptimisation

Optimisation des performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 10. Optimisation des performances DFS . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 11. Analyse des performances avec lutilitaire de suivi . . . . . . . . . . . .

Chapitre 12. Outil de diagnostic PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 13. Gestion dun possible dfaut de performance AIX . . . . . . . . . . . . .

Annexe A. Commandes de contrle et doptimisation des performances AIX

Annexe B. Sous-routines lies aux performances . . . . . . . . . . . . . . . . . . . . . . . . .

Annexe C. Mmoire cache et adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Annexe F. Gestion de la mmoire des applications . . . . . . . . . . . . . . . . . . . . . . . .

AIX 4.3 Guide doptimisation

Annexe G. Bibliothques partages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Annexe H. Accs lhorloge du processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Annexe I. Support NLS (National Language Support) . . . . . . . . . . . . . . . . . . . . . .

Annexe J. Rcapitulatif des paramtres AIX optimisables . . . . . . . . . . . . . . . . .

AIX 4.3 Guide doptimisation

Gestion des performances AIX : structure

Phases danalyse des performances et outils correspondants

Collecte des informations dtailles sur le traitement dune charge par

Transforme les informations dtailles en comptes rendus et en un

Utilise le modle de mise en file dattente pour estimer les effets de

Outil de diagnostic des performances AIX (PDT)

Systme dexploitation de base AIX (BOS)

Rapporte les statistiques relatives la CPU et aux E/S.

Affiche les attributs des units.

Affiche des informations sur un volume logique ou les affectations de volumes

Affiche le contenu des structures de donnes relatives au rseau.

Excute une commande un niveau de priorit suprieur ou infrieur son

Affiche ou dfinit des options rseau.

Affiche ltat des processus.

Modifie la priorit dun ou de plusieurs processus.

Rorganise laffectation des partitions physiques dans un groupe de volumes.

Collecte et rend compte ou enregistre des informations sur lactivit du

AIX 4.3 Guide doptimisation

Imprime la dure dexcution coule et les temps de traitement utilisateur et

Enregistre et rend compte dvnements systme slectionns.

Rend compte de lactivit de la mmoire virtuelle et dautres statistiques

Bote outils Performance Toolbox (PTX)

Optimise un programme excutable pour une charge de travail donne.

Exploite lutilitaire de suivi pour contrler et rendre compte de lactivit

Affiche des statistiques relatives aux verrouillages de noyau.

Exploite lutilitaire de suivi pour rendre compte de lutilisation de CPU

Simule des systmes dots de mmoires de tailles diffrentes pour

Capture et analyse les informations concernant lexploitation de la

Enregistre et compte les appels systme.

Exploite lutilitaire de suivi pour rendre compte de lutilisation de CPU au

Rend compte des schmas daccs mmoire des processus (AIX