Mesurez, analysez, optimisez : Le guide complet de FULLSTIMER pour SAS
FULLSTIMER, c'est l'outil de monitoring ultime pour votre SAS ! Un véritable tableau de bord de la performance qui enregistre les pulsations CPU, la consommation RAM et les transferts d'octets (I/O) de chaque DATA et PROC. Pensez-y comme un 'cat /proc/stats' interne à votre SAS, mais avec un récap' stylé à la sortie. On va décortiquer ensemble les métriques les plus 'mainstream' chez les utilisateurs d'UNIX/Linux et Windows, histoire de parler le même langage binaire !
Activation de FULLSTIMER
L'activation de FULLSTIMER est simple et se fait généralement via l'instruction OPTIONS : OPTIONS FULLSTIMER;. Elle peut également être activée dans les fichiers de configuration SAS, lors de l'invocation de SAS, ou via SAS Environment Manager pour les environnements gérés. Pour la désactiver et revenir au comportement par défaut, on utilise OPTIONS NOFULLSTIMER;. Il faut être conscient des interactions potentielles : l'option NONOTES, qui supprime les messages "NOTE:" du journal, supprimera également la sortie de FULLSTIMER. Si les options STIMER et FULLSTIMER sont toutes deux activées, ce sont généralement les statistiques plus détaillées de FULLSTIMER qui sont écrites dans le journal.
Comprendre les Statistiques FULLSTIMER : Métriques Clés
FULLSTIMER fournit une richesse d'informations. Voici une description détaillée des métriques les plus couramment rapportées, basée sur la documentation et les articles communautaires :
Real Time (Temps Réel) : C'est le temps écoulé "au mur" (wall clock time) pour l'exécution de l'étape ou du travail SAS. C'est le temps d'attente perçu par l'utilisateur. Cette mesure est fortement dépendante de la charge globale du système et de la contention pour les ressources (CPU, I/O, mémoire). Si le système est très sollicité, le temps réel peut augmenter considérablement car le processus SAS doit attendre que les ressources deviennent disponibles.
User CPU Time (Temps CPU Utilisateur) : Représente le temps pendant lequel le processeur (CPU) a activement exécuté le code du programme SAS lui-même. Cela inclut le code écrit par l'utilisateur ainsi que le code interne des procédures et fonctions SAS, mais exclut le temps passé à attendre ou à exécuter des appels directs au système d'exploitation.
System CPU Time (Temps CPU Système) : Désigne le temps CPU consacré à l'exécution des tâches du système d'exploitation effectuées pour le compte du processus SAS. Cela inclut, par exemple, la gestion des requêtes d'entrée/sortie, l'allocation de mémoire, ou d'autres services du noyau nécessaires au fonctionnement du programme SAS. User CPU Time et System CPU Time sont généralement mutuellement exclusifs.
(Total) CPU Time (Temps CPU Total) : Souvent rapporté par l'option STIMER (voir section 3.5), c'est simplement la somme du User CPU Time et du System CPU Time. Une note importante : sur les systèmes multi-processeurs où SAS peut utiliser plusieurs threads simultanément (par exemple, dans certaines procédures), le Temps CPU Total peut légitimement dépasser le Temps Réel. Si deux threads tournent pendant 1 seconde chacun sur deux CPU distincts, cela consomme 2 secondes de CPU en seulement 1 seconde de temps réel.
Memory (Mémoire) : Indique la quantité de mémoire requise ou allouée par l'étape spécifique en cours d'exécution. Il est crucial de comprendre que cela ne représente pas la consommation totale de mémoire de la session SAS entière, car cela n'inclut pas la mémoire utilisée par les composants SAS généraux (gestionnaire SAS, etc.).
OS Memory (Mémoire SE) : Représente la quantité maximale de mémoire du système d'exploitation disponible pour SAS ou demandée par SAS pendant l'étape ou la session (la définition précise peut légèrement varier selon l'OS et la version de la documentation). Dans certains contextes , elle peut refléter le pic d'utilisation mémoire pour l'ensemble du processus.
Page Faults (Défauts de Page) : Compte le nombre de fois où le processus SAS a tenté d'accéder à une page de mémoire qui n'était pas présente en mémoire vive (RAM) et a donc nécessité une opération d'I/O sur disque pour la récupérer. Un nombre élevé de défauts de page ("hard page faults") est un indicateur de pression mémoire et peut sérieusement dégrader les performances en raison de la lenteur de l'accès disque.
Page Reclaims (Récupérations de Page) : Compte le nombre de fois où une page mémoire nécessaire a été trouvée dans une liste de pages prêtes à être réallouées (par exemple, un cache mémoire) sans nécessiter d'I/O disque. Un nombre élevé de récupérations ("soft page faults") est généralement le signe d'une gestion mémoire efficace.
Page Swaps (Échanges de Pages) : Indique le nombre de fois où le processus (ou une partie de celui-ci) a été déplacé de la mémoire principale vers l'espace d'échange (swap) sur le disque. Des valeurs non nulles, surtout si elles sont élevées, sont un signe de forte pression mémoire et impactent lourdement les performances.
Voluntary Context Switches (Commutations de Contexte Volontaires) : Compte le nombre de fois où le processus SAS a volontairement cédé le contrôle du CPU avant la fin de son temps d'exécution alloué. Cela se produit typiquement lorsqu'il doit attendre une ressource externe, le plus souvent une opération d'I/O (lecture ou écriture sur disque). Un certain nombre est normal, mais des valeurs très élevées peuvent suggérer des goulots d'étranglement I/O.
Involuntary Context Switches (Commutations de Contexte Involontaires) : Compte le nombre de fois où le système d'exploitation a forcé le processus SAS à céder le contrôle du CPU. Cela arrive généralement lorsque son temps d'exécution alloué (time slice) a expiré, ou lorsqu'un processus de priorité supérieure a besoin du CPU. Un nombre élevé et constant de commutations involontaires suggère une forte contention pour le CPU, indiquant que le système est globalement surchargé.
Block Input/Output Operations (Opérations d'E/S par Bloc) : Compte le nombre d'opérations physiques de lecture (Input) ou d'écriture (Output) effectuées sur le sous-système de stockage. Des valeurs élevées indiquent une activité disque significative. (Note : mentionne des I/O bufferisées et directes pour OpenVMS).
Timestamp (Horodatage) : Indique la date et l'heure auxquelles l'étape s'est terminée. Très utile pour corréler les statistiques du journal SAS avec les données d'autres outils de surveillance système externes.
Explication des Statistiques FULLSTIMER
Je sais qu'il vous manquait un tableau récapitulatif, comme je suis gentil, le voici :
| Statistique | Description | Indice d'Interprétation |
|---|---|---|
| Real Time | Temps d'horloge écoulé pour l'étape/job. | Temps perçu par l'utilisateur. Affecté par la charge système. Comparer au Temps CPU Total. |
| User CPU Time | Temps CPU passé à exécuter le code SAS (utilisateur et interne). | Indique le travail de calcul intrinsèque à SAS. |
| System CPU Time | Temps CPU passé dans les appels système pour le compte de SAS (I/O, mémoire, etc.). | Indique la charge sur l'OS induite par SAS. |
| (Total) CPU Time | Somme de User CPU Time + System CPU Time. | Temps total d'activité CPU. Peut dépasser Real Time en multi-thread. Comparer au Real Time. |
| Memory | Mémoire requise/allouée par l'étape spécifique. | Indique les besoins en mémoire de l'étape. Ne reflète pas la totalité de la session. |
| OS Memory | Pic de mémoire SE disponible/demandé pendant l'étape/session. | Donne une idée de l'empreinte mémoire globale. |
| Page Faults | Pages mémoire requises non en RAM (nécessitant I/O disque). | Un nombre élevé indique une pression mémoire, ralentissements dus au disque. |
| Page Reclaims | Pages mémoire requises trouvées en cache mémoire (sans I/O disque). | Généralement signe d'efficacité de la gestion mémoire. |
| Page Swaps | Processus déplacé de la RAM vers le disque (swap). | Un nombre élevé indique une forte pression mémoire, impact majeur sur les performances. |
| Voluntary Context Switches | Processus cède le CPU volontairement (attend I/O, etc.). | Normal, mais un nombre très élevé peut signaler un goulot d'étranglement I/O. |
| Involuntary Context Switches | Processus forcé de céder le CPU (temps écoulé, priorité). | Un nombre élevé suggère une forte contention CPU (système surchargé). |
| Block Input/Output Operations | Nombre d'opérations physiques de lecture/écriture disque. | Indique l'intensité de l'activité disque. |
| Timestamp | Date et heure de fin de l'étape. | Utile pour corréler avec des moniteurs externes. |
Interprétation des Données de Performance : Identification des Goulots d'Étranglement
L'analyse des statistiques FULLSTIMER permet de diagnostiquer la nature des limitations de performance.
La Comparaison Fondamentale : Temps Réel vs. Temps CPU Total
C'est le point de départ le plus important pour le diagnostic.
Scénario 1 : Temps Réel ≈ Temps CPU Total : Si le temps réel est proche du temps CPU total (par exemple, avec une différence inférieure à environ 15% selon ), cela suggère que l'étape est principalement limitée par la puissance de calcul disponible (CPU-bound). Le processeur travaille activement pendant la majeure partie du temps d'exécution. Dans ce cas, SAS s'exécute de manière relativement efficace compte tenu du matériel. Pour accélérer l'étape, il faudra probablement optimiser le code SAS lui-même, utiliser des CPU plus rapides, ou envisager des techniques de parallélisation.
Scénario 2 : Temps Réel >> Temps CPU Total : Si le temps réel est significativement plus élevé que le temps CPU total (par exemple, une différence de 20%, 50% ou plus ), cela indique que le processus SAS passe une part importante de son temps en attente (wait state). Il n'est pas activement en train de calculer, mais attend qu'une ressource devienne disponible. Les causes les plus probables sont des goulots d'étranglement au niveau des entrées/sorties (I/O) ou une pression excessive sur la mémoire.
Diagnostic des États d'Attente (Quand Temps Réel >> Temps CPU) : Lorsque l'analyse initiale pointe vers un état d'attente, les autres métriques FULLSTIMER aident à affiner le diagnostic :
Pression Mémoire : Rechercher des valeurs élevées pour les Page Faults (défauts de page nécessitant I/O) et surtout pour les Page Swaps. Si ces valeurs sont importantes, cela suggère que le système manque de mémoire vive pour satisfaire les besoins du processus SAS, le forçant à utiliser le disque comme extension de mémoire, ce qui est très lent. Corréler cela avec les statistiques Memory et OS Memory.
Goulot d'Étranglement I/O : Des valeurs élevées pour les Block Input Operations et Block Output Operations indiquent une activité disque intense. Un nombre élevé de Voluntary Context Switches peut également être un symptôme, car le processus cède le CPU en attendant la fin des opérations I/O.
Contention CPU (Système Surchargé) : Un nombre élevé et persistant d'Involuntary Context Switches suggère que le système dans son ensemble est surchargé. Le processus SAS est fréquemment interrompu non pas parce qu'il attend une ressource spécifique, mais parce que d'autres processus monopolisent le CPU.
Analyse CPU-Bound (Quand Temps Réel ≈ Temps CPU) : Même lorsque le processus est limité par le CPU, il peut être utile d'examiner la répartition entre User CPU Time et System CPU Time. Un User CPU Time élevé indique que le temps est passé dans les algorithmes et la logique du code SAS. Un System CPU Time élevé suggère que SAS fait de nombreux appels au système d'exploitation, ce qui peut encore être lié à une gestion intensive des I/O ou de la mémoire, mais initiée activement par SAS plutôt qu'une simple attente passive.
FULLSTIMER comme Point de Départ Diagnostique : Il est essentiel de comprendre que FULLSTIMER fournit des indicateurs précieux sur la performance au niveau de SAS. Cependant, pour confirmer la cause racine exacte d'un goulot d'étranglement, en particulier ceux liés au matériel (disque lent, réseau saturé, CPU insuffisant), il est souvent nécessaire de corréler ces informations avec d'autres sources. Cela peut inclure la sortie de SASTRACE (pour les interactions base de données) ou, de manière plus significative, les données provenant d'outils de surveillance au niveau du système d'exploitation (comme nmon, perfmon, vmstat, iostat, etc., mentionnés dans ). FULLSTIMER guide l'investigation en indiquant où et quand regarder avec ces outils plus spécialisés.
FULLSTIMER vs. STIMER : Choisir le Bon Niveau de Détail
SAS propose également l'option STIMER, qui est souvent activée par défaut. La différence essentielle réside dans le niveau de détail fourni :
STIMER fournit un sous-ensemble des statistiques de FULLSTIMER. Typiquement, il n'affiche que le Real Time et le (Total) CPU Time pour chaque étape.
FULLSTIMER offre une vue beaucoup plus complète, incluant les détails sur la mémoire, le paging, les opérations I/O, les commutations de contexte, etc..
Comme mentionné précédemment, si les deux options sont activées, la sortie de FULLSTIMER, plus détaillée, prévaut généralement. Le choix entre les deux dépend du besoin :
Utiliser STIMER pour : Obtenir un aperçu rapide des temps d'exécution des étapes avec un minimum d'encombrement dans le journal.
Utiliser FULLSTIMER pour : Effectuer une analyse de performance approfondie, diagnostiquer des goulots d'étranglement complexes, réaliser des benchmarks précis.
FULLSTIMER en Action : Identification des Points Chauds et Benchmarking
Exemple 1 : Identification des Étapes Coûteuses en Ressources :
En activant OPTIONS FULLSTIMER;, le journal SAS affichera les blocs de statistiques pour chaque étape DATA et PROC.
Il suffit de parcourir le journal et d'examiner les lignes "NOTE:... statement used (Total process time):" ou "NOTE: PROCEDURE... used (Total process time):". En comparant les valeurs de Real Time et de CPU Time (User + System) pour chaque étape, on peut rapidement identifier les "points chauds" (hotspots) – les étapes qui consomment le plus de temps d'horloge ou celles qui présentent un écart important entre le temps réel et le temps CPU, indiquant une attente significative. Cela permet de concentrer les efforts d'optimisation sur les parties les plus critiques du code.
Exemple 2 : Benchmarking des Modifications de Code :
FULLSTIMER est un outil essentiel pour mesurer objectivement l'impact des efforts d'optimisation. Le processus typique est le suivant :
Exécuter le code original (la baseline) avec OPTIONS FULLSTIMER;.
Noter les métriques clés (Real Time, CPU Times, Memory, Page Faults, Block I/O) pour les étapes critiques que l'on souhaite améliorer.
Modifier le code SAS (par exemple, ajouter un index à une table avant une jointure, remplacer une jointure par une autre technique, utiliser une clause WHERE au lieu d'un IF de sous-ensemble, ajuster les options SORTSIZE ou MEMSIZE).
Réexécuter le code modifié, toujours avec OPTIONS FULLSTIMER;.
Comparer les métriques de la nouvelle exécution avec celles de la baseline pour quantifier l'amélioration (ou la dégradation) des performances.
Pour des benchmarks fiables, il est recommandé d'exécuter chaque version plusieurs fois et de moyenner les résultats, d'utiliser des données de test réalistes en termes de volume et de complexité, et si possible, d'exécuter chaque test dans une session SAS distincte pour éviter les effets de cache résiduels.
L'utilisation de FULLSTIMER dans ce contexte fournit les données objectives nécessaires pour valider si une modification de code a réellement atteint l'objectif d'amélioration des performances, permettant des décisions basées sur des faits plutôt que sur des suppositions.
