Partager via

Considérations relatives au protocole LDAP lors du réglage des performances d’AD DS

Important

Voici un résumé des principales recommandations et considérations relatives à l’optimisation du matériel serveur pour les charges de travail Active Directory traitées plus en détail dans l’article Planification de capacité pour Active Directory Domain Services. Les lecteurs sont vivement encouragés à passer en revue Planification de capacité pour Active Directory Domain Services pour une meilleure compréhension technique et les implications de ces recommandations.

Vérifier les requêtes LDAP

Vérifiez que les requêtes LDAP sont conformes aux recommandations en matière de création de requêtes efficaces.

Il existe une documentation complète sur MSDN sur la façon d’écrire, de structurer et d’analyser correctement les requêtes à utiliser sur Active Directory. Pour plus d’informations, consultez Création d’applications avec Microsoft Active Directory plus efficaces.

Optimiser les tailles de page LDAP

Lorsque vous retournez des résultats avec plusieurs objets en réponse aux requêtes du client, le contrôleur de domaine doit stocker temporairement le jeu de résultats dans la mémoire. L’augmentation des tailles de page entraîne une utilisation plus importante de la mémoire et peut faire sortir inutilement des éléments du cache. Dans ce cas, les paramètres par défaut sont optimaux. Dans plusieurs scénarios, des recommandations ont été faites d’augmenter les paramètres de taille de page. Nous vous recommandons d’utiliser les valeurs par défaut, sauf si elles sont spécifiquement identifiées comme inadéquates.

Lorsque les requêtes ont de nombreux résultats, une limite du nombre de requêtes similaires exécutées simultanément peut être rencontrée. Cette situation se produit quand le serveur LDAP épuise éventuellement une zone de mémoire globale appelée pool de cookies. Il peut s’avérer nécessaire d’augmenter la taille du pool, comme indiqué dans Gestion des cookies du serveur LDAP.

Pour régler ces paramètres, consultez Windows Server 2008 et le contrôleur de domaine le plus récent retourne uniquement 5 000 valeurs dans une réponse LDAP.

Déterminer s’il est nécessaire d’ajouter des index

L’indexation des attributs s’avère utile lors de la recherche d’objets dont le nom d’attribut se trouve dans un filtre. L’indexation permet de réduire le nombre d’objets à visiter lors de l’évaluation du filtre. En revanche, elle réduit les performances des opérations d’écriture, car l’index doit être mis à jour lorsque l’attribut correspondant est modifié ou ajouté. Elle augmente également la taille de la base de données de l’annuaire, même si les avantages l’emportent souvent sur le coût du stockage. La journalisation peut servir à identifier les requêtes coûteuses et inefficaces. Une fois identifiées, envisagez d’indexer certains attributs utilisés dans les requêtes correspondantes pour améliorer les performances de la recherche. Pour plus d’informations sur le fonctionnement des recherches Active Directory, consultez Fonctionnement des recherches Active Directory.

Scénarios qui tirent avantage de l’ajout d’index

  • La charge du client lors de la demande de données génère une utilisation significative du processeur et le comportement de requête du client ne peut pas être modifié ni optimisé.

  • La charge du client génère des E/S disque importantes sur un serveur en raison d’un attribut non indexé et le comportement de requête du client ne peut pas être modifié ni optimisé.

  • Une requête prend beaucoup de temps et ne se termine pas dans un délai acceptable pour le client en raison d’un manque d’index.

  • De grands volumes de requêtes avec des durées élevées sont à l’origine de la consommation et de l’épuisement des threads LDAP ATQ. Supervisez les compteurs de performances suivants :

    • NTDS\Latence de demande : Cette latence est soumise à la durée de traitement de la demande. Active Directory fait expirer les requêtes au bout de 120 secondes (par défaut). Néanmoins, la majorité s’exécutent beaucoup plus rapidement et les requêtes extrêmement longues sont masquées dans les nombres globaux. Recherchez les modifications apportées à cette base de référence, plutôt que des seuils absolus.

      Notes

      Ici, des valeurs élevées peuvent également indiquer des retards dans les demandes de connexion proxy adressées à d’autres domaines et les vérifications de liste de révocation de certificats.

    • NTDS\Délai de file d’attente estimé : Ce délai doit idéalement être proche de 0 pour des performances optimales, car cela signifie que les demandes n’attendent pas d’être gérées.

Ces scénarios peuvent être détectés à l’aide d’une ou plusieurs des approches suivantes :

Autres considérations relatives aux index

  • Vérifiez que la création de l’index est la bonne solution au problème une fois que le paramétrage de la requête a été épuisé en tant qu’option. Il est très important de dimensionner correctement le matériel. Des index doivent être ajoutés uniquement lorsque le correctif approprié consiste à indexer l’attribut, et non dans une tentative d’ignorer des problèmes matériels.

  • Les index augmentent la taille de la base de données d’au moins une fois la taille totale de l’attribut indexé. Une estimation de la croissance de la base de données peut donc être effectuée en prenant la taille moyenne des données dans l’attribut et en la multipliant par le nombre d’objets dont l’attribut sera rempli. En général, il s’agit d’une augmentation de 1 % de la taille de la base de données. Pour plus d’informations, consultez Fonctionnement du magasin de données.

  • Si le comportement de recherche est principalement effectué au niveau de l’unité d’organisation, envisagez une indexation pour les recherches conteneurisées.

  • Les index de tuple sont plus grands que les index normaux, mais il est beaucoup plus difficile d’en estimer la taille. Utilisez des estimations de taille d’index normaux comme base de croissance, avec un maximum de 20 %. Pour plus d’informations, consultez Fonctionnement du magasin de données.

  • Si le comportement de recherche est principalement effectué au niveau de l’unité d’organisation, envisagez une indexation pour les recherches conteneurisées.

  • Les index de tuple sont nécessaires pour prendre en charge les chaînes de recherche médianes et les chaînes de recherche finales. Les index de tuple ne sont pas nécessaires pour les chaînes de recherche initiales.

    • Chaîne de recherche initiale : (samAccountName=MYPC*)

    • Chaîne de recherche médiane : (samAccountName=*MYPC*)

    • Chaîne de recherche finale : (samAccountName=*MYPC$)

  • La création d’un index génère des E/S disque pendant la construction de l’index. Cette opération est effectuée sur un thread d’arrière-plan avec une priorité plus faible et les demandes entrantes sont prioritaires par rapport à la génération de l’index. Si la planification de capacité a été effectuée correctement pour l’environnement, elle doit être transparente. Néanmoins, des scénarios d’écriture intensive ou un environnement où la charge sur le stockage du contrôleur de domaine est inconnue peuvent dégrader l’expérience client et doivent être effectués pendant les heures creuses.

  • L’impact sur le trafic de réplication est minime, car la génération d’index se produit localement.

Pour plus d’informations, consultez :

Références supplémentaires