Manuel de suivi dynamique Solaris

Chapitre 11 Tampons et mise en tampon

La mise en tampon et la gestion des données est un service essentiel que fournit la structure DTrace à ses clients, comme par exemple dtrace(1M). Ce chapitre explore en détails la mise en tampon de données et décrit les options que vous pouvez utiliser pour modifier les stratégies de gestion de tampon de DTrace.

Tampons principaux

Le tampon principal est présent dans chaque appel DTrace. Par défaut, c'est vers ce tampon que les actions de suivi enregistrent leurs données. Parmi ces actions figurent :

exit()

printf()

trace()

ustack()

printa()

stack()

tracemem()

 

Les tampons principaux sont toujours alloués par CPU. Cette stratégie n'est pas réglable mais le suivi et l'allocation de tampon peuvent se limiter à une seule CPU en utilisant l'option cpu.

Stratégies de tampon principal

DTrace autorise le suivi dans des contextes de contrainte élevée du noyau. En particulier, DTrace autorise le suivi dans des contextes dans lesquels le logiciel de noyau risque de ne pas allouer de mémoire de façon fiable. La conséquence de cette flexibilité de contexte est la suivante : il existe toujours une possibilité pour que DTrace tente de suivre des données lorsque l'espace disponible est insuffisant. DTrace doit disposer d'une stratégie pour gérer de tels cas de figure, le cas échéant, mais il est possible que vous souhaitiez régler la stratégie en fonction des besoins d'une expérimentation donnée. Parfois, la stratégie appropriée risque de rejeter les nouvelles données. Dans d'autres cas, il peut être souhaitable de réutiliser l'espace contenant les données enregistrées les plus anciennes pour suivre les nouvelles données. Le plus souvent, la stratégie souhaitée consiste à réduire le risque de manquer d'espace disponible, en tout premier lieu. Pour répondre à ces différentes demandes, DTrace prend en charge plusieurs stratégies de tampon. Cette prise en charge est implémentée avec l'option bufpolicy et peut être définie par consommateur. Pour de plus amples informations sur les options de paramétrage, reportez-vous au Chapitre16Options et paramètres réglables.

Stratégie switch

Par défaut, le tampon principal dispose d'une stratégie de tampon switch. Dans le cadre de cette stratégie, les tampons par CPU sont alloués par paires : un tampon est actif, l'autre non. Lorsqu'un consommateur tente de lire un tampon, le noyau commence par commuter les tampons actif et inactif. La commutation des tampons s'effectue de telle sorte qu'aucune donnée de suivi ne risque d'être perdue dans une fenêtre. Une fois que les tampons sont commutés, le tampon devenu inactif est copié dans le consommateur DTrace. Grâce à cette stratégie, le consommateur affiche toujours un tampon autocohérent : un tampon ne fait jamais l'objet d'un suivi et d'une copie simultanément. Cette technique permet également d'éviter l'introduction d'une fenêtre dans laquelle le suivi est mis à l'état de pause ou empêché d'une autre manière. La vitesse de commutation et de lecture du tampon est contrôlée par le consommateur avec l'option switchrate. Comme avec n'importe quelle option de vitesse, switchrate peut être spécifié avec n'importe quel suffixe temporel mais le suffixe par défaut est le nombre par seconde. Pour de plus amples informations sur les options, telles que switchrate, reportez-vous au Chapitre16Options et paramètres réglables.


Remarque –

Pour procéder au traitement du tampon principal au niveau utilisateur à un taux supérieur que le taux par défaut d'une fois par seconde, réglez la valeur de switchrate. Le système traite les actions qui entraînent l'activité au niveau utilisateur (telles que printa() et system()) lorsque l'enregistrement correspondant du tampon principal est traité. La valeur de switchrate détermine le taux auquel le système traite ces actions.


Dans le cadre de la stratégie switch, si une sonde activée donnée procède au suivi de davantage de données qu'il n'y a d'espace disponible dans le tampon principal actif, les données sont abandonnées et le nombre d'abandons par CPU est incrémenté. Dans l'éventualité d'un ou de plusieurs abandons, dtrace(1M) affiche un message similaire à l'exemple suivant :


dtrace: 11 drops on CPU 0

Si un enregistrement donné est supérieur à la taille totale du tampon, l'enregistrement est supprimé quelle que soit la stratégie de tampon. Vous pouvez réduire ou éliminer les suppressions soit en augmentant la taille du tampon principal avec l'option bufsize, soit en augmentant la vitesse de commutation avec l'option switchrate.

Dans le cadre de la stratégie switch, l'espace de travail pour copyin(), copyinstr() et alloca() est alloué à l'extérieur du tampon actif.

Stratégie fill

Dans le cas de certains problèmes, vous pouvez utiliser un tampon unique interne au noyau. Tant que cette approche peut être implémentée avec la stratégie switch et les constructions D appropriées en incrémentant une variable en D et en réalisant un prédicat d'action exit() correctement, cette implémentation n'élimine pas le risque d'abandons. Pour demander un tampon unique de grande capacité interne au noyau et poursuivre le suivi jusqu'à ce qu'au moins un des tampons par CPU soit rempli, utilisez la stratégie de tampon fill. Dans le cadre de cette stratégie, le suivi se poursuit jusqu'à ce qu'une sonde activée tente de suivre plus de données que ne peut en accueillir l'espace restant sur le tampon principal. Lorsque l'espace restant est insuffisant, le tampon est marqué comme rempli et le consommateur est notifié qu'au moins un de ses tampons par CPU est rempli. Une fois que dtrace(1M) détecte un tampon rempli, le suivi est arrêté, tous les tampons sont traités, puis dtrace se ferme. Aucune autre donnée n'est suivie dans un tampon rempli même s'il reste suffisamment de place pour l'accueillir.

Pour utiliser la stratégie fill, définissez l'option bufpolicy sur fill. Par exemple, la commande suivante procède au suivi de chaque entrée d'appel système dans un tampon par CPU de 2K avec la stratégie de tampon définie sur fill :


# dtrace -n syscall:::entry -b 2k -x bufpolicy=fill

Stratégie fill et sondes END

En règle générale, les sondes END ne se déclenchent pas avant que le suivi n'ait été arrêté de manière explicite par le consommateur DTrace. Les sondes END se déclenchent toujours sur une CPU, mais celle-ci n'est pas définie. Avec les tampons fill, le suivi est arrêté de manière explicite lorsqu'au moins l'un des tampons principaux par CPU est marqué comme rempli. Si la stratégie fill est sélectionnée, la sonde END est susceptible de se déclencher sur une CPU ayant un tampon rempli. Pour accueillir le suivi END dans des tampons fill, DTrace calcule la quantité d'espace potentiellement consommée par les sondes END et soustrait cet espace de la taille du tampon principal. Si la taille nette est négative, DTrace refuse de démarrer et dtrace(1M) affiche un message d'erreur correspondant.


dtrace: END enablings exceed size of principal buffer

Le mécanisme de réservation garantit qu'un tampon plein dispose toujours d'un espace suffisant pour n'importe quelle sonde END.

Stratégie ring

La stratégie de tampon ring de DTrace vous aide à procéder au suivi d'événéments à l'origine de pannes. Si la reproduction de la panne prend plusieurs heures ou plusieurs jours, vous ne souhaiterez certainement conserver que les données les plus récentes. Dès qu'un tampon principal est rempli, le suivi effectue une recherche circulaire sur la première entrée, écrasant ainsi des données de suivi antérieures. Vous établissez le tampon circulaire en définissant l'option bufpolicy sur la chaîne ring :


# dtrace -s foo.d -x bufpolicy=ring

Lorsqu'il est utilisé pour créer un tampon circulaire, dtrace(1M) n'affiche aucune sortie jusqu'à la fin du processus. Lors de l'achèvement du processus, le tampon circulaire est consommé et traité. dtrace traite chaque tampon circulaire dans l'ordre des CPU. Dans le tampon d'une CPU, les enregistrements de suivi sont affichés chronologiquement, du plus ancien au plus récent. Tout comme dans le cas d'une stratégie de tampon switch aucun tri n'existe entre les enregistrements effectués depuis différentes CPU. Si un tri de ce type est requis, vous devez procéder au suivi de la variable timestamp dans le cadre de votre requête de suivi.

L'exemple suivant montre l'utilisation d'une directive #pragma option pour activer la mise en tampon circulaire :

#pragma D option bufpolicy=ring
#pragma D option bufsize=16k

syscall:::entry
/execname == $1/
{
	trace(timestamp);
}

syscall::rexit:entry
{
	exit(0);
}

Autres tampons

Les tampons principaux sont présents dans chaque activation DTrace. Outre les tampons principaux, certains consommateurs DTrace peuvent disposer d'autres tampons de données internes au noyau : un tampon de groupement, présenté dans le Chapitre9Groupements, et un ou plusieurs tampons spéculatifs, présentés dans le Chapitre13Suivi spéculatif.

Taille des tampons

La taille de chaque tampon peut être réglée par consommateur. Des options séparées sont fournies pour régler chaque taille de tampon, comme indiqué dans le tableau suivant :

Tampon 

Option de taille 

Principal 

bufsize

Spéculatif 

specsize

Groupement 

aggsize

Chacune de ces options est définie avec une valeur dénotant la taille. Comme avec n'importe quelle option de taille, la valeur peut avoir un suffixe de taille facultatif. Pour de plus amples informations, reportez-vous au Chapitre16Options et paramètres réglables. Par exemple, pour définir la taille de tampon à un méga-octet sur la ligne de commande dans dtrace, vous pouvez utiliser -x pour définir l'option :


# dtrace -P syscall -x bufsize=1m

Vous pouvez également utiliser l'option -b dans dtrace :


# dtrace -P syscall -b 1m

Enfin, vous pouvez définir bufsize avec l'option #pragma D option :

#pragma D option bufsize=1m

La taille de tampon sélectionnée dénote la taille de tampon sur chaque CPU. En outre, lorsque la stratégie de tampon switch est sélectionnée, bufsize dénote la taille de chaque tampon sur chaque CPU. La taille de tampon par défaut est de quatre méga-octets.

Stratégie de redimensionnement du tampon

Parfois, il arrive que le système ne dispose pas de mémoire disponible dans le noyau pour allouer un tampon de la taille souhaitée car la mémoire disponible est insuffisante ou car le consommateur DTrace a dépassé l'une des limites réglables décrites dans le Chapitre16Options et paramètres réglables Vous pouvez configurer la stratégie en cas de panne de l'allocation de tampon avec l'option bufresize, qui, par défaut, est définie sur auto. Dans le cadre de la stratégie de redimensionnement du tampon auto, la taille du tampon est divisée en deux jusqu'à ce qu'une allocation correcte soit effectuée. dtrace(1M) génère un message si la taille du tampon alloué est inférieure à celle requise :


# dtrace -P syscall -b 4g
dtrace: description 'syscall' matched 430 probes
dtrace: buffer size lowered to 128m
...

ou


# dtrace -P syscall'{@a[probefunc] = count()}' -x aggsize=1g
dtrace: description 'syscall' matched 430 probes
dtrace: aggregation size lowered to 128m
...

Vous pouvez aussi nécessiter une intervention manuelle après la panne d'allocation de tampon en définissant bufresize sur manual. Dans le cadre de cette stratégie, une panne d'allocation provoque un échec de démarrage :


# dtrace -P syscall -x bufsize=1g -x bufresize=manual
dtrace: description 'syscall' matched 430 probes
dtrace: could not enable tracing: Not enough space
#

La stratégie de redimensionnement de tous les tampons (principaux, spéculatifs et de groupement) est dictée par l'option bufresize.