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.

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);
}