Cette section décrit les améliorations apportées à la plate-forme et aux performances dans cette version. Ces fonctions permettent d'optimiser les systèmes Oracle Solaris for SPARC et x86 en améliorant les performances, mais fournissent également un meilleur diagnostic pour vos systèmes.
La version Oracle Solaris 11.4 présente un nouveau fournisseur SCSI DTrace destiné à assurer le suivi des commandes SCSI et des fonctions de gestion de tâches émises par un système Oracle Solaris. Le fournisseur SCSI offre les avantages suivants :
Il permet d'assurer le suivi des commandes SCSI sur un système Oracle Solaris sans connaître la structure interne.
Il inclut des sondes et des structures respectant autant que possible les normes SCSI T10.
Il offre une contrepartie au fournisseur d'E/S DTrace qui suit le trafic d'E/S sur une autre couche.
Il fournit un script scsitrace qui consomme les nouvelles sondes.
L'exemple suivant illustre un suivi sur une ligne identifiant les réinitialisations de cible SCSI :
# dtrace -n 'scsi:::tmf-request
/(args[1] == SCSI_TMF_TARGET_RESET) &&
(args[0]->addr_path != "NULL")/ {
printf("Target Reset sent to %s", args[0]->addr_path);}'
Pour plus d'informations, reportez-vous à la section iscsi Provider du manuel Guide d’utilisation d’Oracle Solaris 12 DTrace (Dynamic Tracing).
Le fournisseur fileops présente un jeu complet de sondes d'opération de fichier UNIX standard qui sont plus destinées à un administrateur Oracle Solaris qu'à un développeur. Par exemple, le fournisseur peut afficher les informations de latence de lecture (read) ou d'écriture (write) pour tous les systèmes de fichiers, y compris les pseudo-systèmes de fichiers.
Les sondes fileops s'appliquent aux opérations de fichiers suivantes : open, close, read, write, etc. Ces sondes ne sont spécifiques d'aucun type de système de fichiers et ne sont pas dépendantes des E/S vers les périphériques de stockage externes. Par exemple, la sonde fileops:::read se déclenche sur n'importe quelle lecture d'un fichier, que les données proviennent du disque ou soient mises en mémoire cache.
Vous pouvez utiliser la sonde read pour observer les latences de lecture sur différents types de système de fichiers. Par exemple :
fileops:::read
{
@[args[0]->fi_fs] =
quantize(args[1]);
}
La sortie en résultant fournit un graphique du nombre de lectures et des latences sur tous les types de système de fichiers du système.
Pour plus d'informations, reportez-vous à la section fileops Provider du manuel Guide d’utilisation d’Oracle Solaris 12 DTrace (Dynamic Tracing).
La version Oracle Solaris 11.4 étend le fournisseur MIB DTrace pour l'observation des événements de la pile réseau avec des informations de protocole afin que les connexions TCP, UDP et IP puissent être identifiées.
Pour plus d'informations, reportez-vous à la section mib Provider du manuel Guide d’utilisation d’Oracle Solaris 12 DTrace (Dynamic Tracing).
Une nouvelle action, pcap(), a été ajoutée à DTrace. L'action pcap() effectuera l'une des opérations suivantes :
Affiche les données de paquet comme le fait tracemem(), mais fusionnées dans un tampon contigu.
Si freopen() a spécifié un fichier de capture, l'action pcap() capturera les données de paquet dans un fichier de capture de paquet via la fonction libpcap pcap_dump(). DTrace effectue les opérations suivantes sur les données de paquet :
Collecte les données de paquet dans un contexte de sonde.
Fusionne les données de paquet dans un tampon contigu si elles ne s'y trouvent pas déjà.
Vide les données dans le fichier spécifié via la fonction pcap_dump(), qui a été appelée lors de la collecte des données.
L'action pcap() suivante vide la mémoire dans stdout comme le fait tracemem() :
pcap(mblk, protocol);
Les appels suivants vident les données de paquet dans le fichier de capture avec un suffixe spécifiant le pid actuel :
freopen("/tmp/cap.%d", pid);
pcap(mblk, protocol);
Cela vous permet d'assembler les suivis de paquet par processus ou service, par exemple. Comme freopen() est classée en tant qu'action destructive, le script ci-dessus doit spécifier l'option –w (”destructive”) dtrace. L'action pcap() n'est pas destructive.
DTrace présente une nouvelle action print() pour afficher les types arbitraires, comme l'illustre l'exemple suivant :
# dtrace -q -n 'fop_close:entry {print(*args[0]);exit(0)}'
vnode_t {
v_lock = {
_opaque = [ NULL ]
}
v_flag = 0x0
v_count = 0x1
v_data = 0xffffc10054425378
v_vfsp = specfs`spec_vfs
v_stream = 0xffffc100623354e8
v_type = VCHR
v_rdev = 0xee00000026
v_vfsmountedhere = NULL
v_op = 0xffffc10029d98040
v_pages = NULL
v_filocks = NULL
v_shrlocks = NULL
v_nbllock = {
_opaque = [ NULL ]
}
v_cv = {
_opaque = 0x0
}
v_pad = 0xbadd
v_count_dnlc = 0x0
v_locality = NULL
v_femhead = NULL
v_path = "/devices/pseudo/udp@0:udp"
v_rdcnt = 0x0
v_wrcnt = 0x0
v_mmap_read = 0x0
v_mmap_write = 0x0
v_mpssdata = NULL
v_fopdata = NULL
v_vsd_lock = {
_opaque = [ NULL ]
}
v_vsd = NULL
v_xattrdir = NULL
v_fw = 0xbaddcafebaddcafe
}
#
Pour plus d'informations, reportez-vous à la section print Action du manuel Guide d’utilisation d’Oracle Solaris 12 DTrace (Dynamic Tracing).
La structure v2 des statistiques relatives au noyau (kstats) offre de meilleures performances et un certain nombre d'optimisations par rapport à la structure kstat précédente. Les nouveaux composants notables incluent notamment :
Une API de noyau permettant de créer et de manipuler des kstats v2. Les kstats sont identifiées à l'aide d'un URI unique et incluent des métadonnées pour la kstat et les paires nom-valeur qu'elle contient. Cette API permet à la kstat de décrire les valeurs qu'elle signale.
Une bibliothèque libkstat2 qui fournit l'accès aux kstats v2 créées dans le noyau. Les kstats sont consultées en fonction de leur URI unique et sont présentées en tant que tables de hachage. Les développeurs peuvent s'abonner aux événements à un niveau d'URI de kstat donné et être informés lorsque des kstats sont ajoutées sous les événements dans l'arborescence d'URI ou qu'elles en sont retirées.
L'utilitaire /usr/bin/kstat2 qui fournit l'accès via la CLI à la kstat. Ce nouvel utilitaire examine les kstats disponibles sur le système et signale les statistiques qui correspondent aux critères spécifiés sur la ligne de commande. Chaque statistique correspondante est alors imprimée avec son URI et sa valeur réelle. Différents formats de sortie sont pris en charge, notamment les formats lisibles par l'utilisateur, les formats analysables et les formats JSON (JavaScript Object Notation).
Pour plus d'informations sur l'API de noyau, reportez-vous aux pages de manuel kstat2_create(9F), kstat2_create_with_template(9F) et kstat2_create_histogram(9F). Pour plus d'informations sur la bibliothèque libkstat2, reportez-vous aux pages de manuel libkstat2(3LIB) et kstat2(3KSTAT2). Pour plus d'informations sur l'utilitaire kstat2, reportez-vous à la page de manuel kstat2(8).
Oracle Solaris 11.4 inclut la fonction de diagnostic de dump noyau, qui offre un résumé des télémétriques des dumps noyau d'utilisateur, génère des alertes FMA pour informer l'utilisateur, et fournit une stratégie de conservation de diagnostic ainsi qu'une association de cas SMF.
Les fichiers noyau de diagnostic ne contiennent que le nécessaire, ce qui fait que leur contenu est de petite taille. Les fichiers noyau seront supprimés une fois les fichiers récapitulatifs de texte générés, réduisant ainsi l'espace disque. Avec d'autres nouvelles fonctions telles que le diagnostic de pile, FMA peut rechercher les problèmes connus dans les piles du fichier récapitulatif de la base de données Oracle. La stratégie de conservation permet à l'utilisateur de définir la stratégie principale de diagnostic via la commande coreadm. La commande coreadm fournit également des fonctionnalités telles que la suppression immédiate des noyaux ou la conservation d'un nombre de noyaux donné pendant un certain temps. La fonction d'association de cas concerne le moteur de diagnostic sw-diag-response. Toutes les alertes de diagnostic de noyau menant à une défaillance du service logiciel peuvent être consultées avec le jeu des données de pile et d'environnement de chaque événement.
L'utilisateur peut maintenant mieux contrôler les noyaux de diagnostic. Lorsqu'un service logiciel ne s'exécute pas correctement et est mis hors service, l'administrateur peut facilement et rapidement voir tous les événements qui ont conduit à la défaillance du service et être mieux informé sur les processus qui ont échoué ainsi que sur l'emplacement de l'échec de chaque processus dans son code d'exécution.
Pour plus d'informations, reportez-vous à la page de manuel coreadm(8).
Dans Oracle Solaris 11.4, la commande pfiles accepte un nom de dump noyau en tant qu'argument et peut afficher des informations sur les descripteurs de fichier ouvert par un processus qui effectue un dump noyau. Cette fonctionnalité fournit une aide supplémentaire pour déboguer le dump noyau de processus et connaître la cause à l'origine du dump.
Contrairement aux versions précédentes, dans Oracle Solaris 11.4, la commande pfiles n'arrête plus un processus cible en cours d'exécution lors de l'extraction des données sur des fichiers ouverts dans ce processus.
Pour plus d'informations, reportez-vous à la page de manuel proc(1).
La commande fsstat comporte une nouvelle option –l qui signale les informations de latence pour les opérations read, write et readdir. Les informations de latence étant indépendantes des opérations d'E/S physiques, elles sont représentatives des performances du système de fichiers, telles qu'elles sont constatées par les applications. Cette fonction permet aux utilisateurs d'observer la latence du système de fichiers pour les types de système de fichiers ou les systèmes de fichiers individuels. Elle s'avère utile pour résoudre les problèmes de performances de système de fichiers.
Pour plus d'informations, reportez-vous à la page de manuel fsstat(8).
Oracle Solaris 11.4 fournit désormais des informations sur le temps de réponse d'E/S SCSI ou sur la répartition de la latence d'E/S pour une meilleure observabilité. La répartition du temps de réponse d'E/S permet d'identifier les valeurs aberrantes de temps de réponse. La répartition est stockée dans un histogramme avec trois options d'échelle x : linear, log2-based et log10-based. La répartition peut être affichée à l'aide de la commande iostat. L'option –L est ajoutée en conjonction avec les options –x et –Y pour afficher l'histogramme. Ces informations de répartition permettent d'examiner les problèmes de performances.
Pour plus d'informations, reportez-vous aux pages de manuel sd(4D) et iostat(8).