Section Directory Search

the Most CPU Usage affiche une liste des adresses IP client et d’informations sur la performance de recherche de clients. La table Unique Search montre que les recherches générées par le client à 10.70.0.131 utilisent une énorme quantité de CPU. Dans la première ligne de cette table, l’indicateur dans la colonne Index correspond à l’avertissement de performance de la figure 2 et il vous indique que le client à 10.7.0.131 utilise 24,74 % de la CPU.

Si vous cliquez sur le signe plus à gauche de l’adresse IP d’un client dans la table Clients with the Most CPU Usage, vous obtenez plus de détails sur toutes les recherches attribuées à ce client, en même temps que les paramètres de recherche et d’autres informations liées à la recherche, comme le montre la figure 4. Chaque ligne représente une ou plusieurs opérations de recherche qui ont la même base de recherche LDAP, domaine, filtre et code résultat. La notation Top: 3 de 7 dans la barre de titre de la table indique que SPA ne montre que les trois premières recherches LDAP. Pour voir d’autres entrées, cliquez sur le 3 et tapez un autre nombre. Pour trier les données par valeurs dans une colonne particulière, cliquez sur l’en-tête de colonne. La plupart des tables du rapport SPA se comportent ainsi.

La colonne Index montre l’index que l’AD a utilisé dans sa recherche. Dans la recherche la plus volumineuse, portant sur le schéma naming context (NC), le filtre de recherche cn=*a* spécifie une recherche medial-string (c’est-à-dire une recherche munie d’un filtre contenant un joker qui n’est pas à la fin de la chaîne) sur l’attribut Common Name (CN). L’attribut CN est indexé par défaut dans AD, mais pas pour les recherches medial-string, donc AD doit lire tous les objets présents dans le schéma NC pour déterminer s’il correspond au filtre.

En examinant les autres recherches effectuées par ce client, vous verrez qu’elles font la même chose que la recherche de schéma : elles effectuent des recherches médiales dans la sous-arborescence sur l’attribut CN, amenant l’AD à utiliser soit l’index ancestors, soit l’index distinguished name tag (dnt_index), dont aucun des deux n’est bon pour la performance. Face à un grand nombre de recherches qui utilisent l’index ancestors ou dnt_index, vous devez soit modifier le filtre de recherche pour bénéficier des index qui existent déjà dans l’AD, soit créer de nouveaux index. Par exemple, si vous déterminez que cn=*a* est un filtre de recherche légitime qu’il faut optimiser, vous pouvez ajouter un index medial search sur l’attribut CN.

Ajouter un index à l’AD est simple, comme l’explique l’article Microsoft « Index an attribute in Active Directory ». Sachez que chaque index consomme de l’espace disque supplémentaire et allongera les opérations de mise à jour. Si vous avez déjà un grand Directory Information Tree (DIT), cet espace disque supplémentaire pourrait être substantiel. De plus, tous les objets présents dans l’AD seront indexés, et pas simplement ceux qui se trouvent dans un conteneur ou NC ; donc, réfléchissez à l’influence d’un nouvel index sur la performance et testez-le soigneusement avant de procéder au changement.

Nous avons expliqué deux des trois avertissements de performance avec lesquels nous avons commencé. Voyons maintenant la longue file d’attente de sortie du troisième NIC.