Delen via

LDAP-overwegingen bij het afstemmen van prestaties bij ADDS

Important

Hier volgt een overzicht van de belangrijkste aanbevelingen en overwegingen voor het optimaliseren van serverhardware voor Active Directory-workloads die uitgebreider worden behandeld in het artikel Capaciteitsplanning voor Active Directory Domain Services . Lezers worden ten zeerste aangemoedigd om capaciteitsplanning voor Active Directory Domain Services te bekijken voor een beter technisch begrip en gevolgen van deze aanbevelingen.

LDAP-queries controleren

Controleer of LDAP-query's voldoen aan de aanbevelingen voor efficiënte query's.

Er is uitgebreide documentatie over MSDN over het correct schrijven, structuren en analyseren van query's voor gebruik met Active Directory. Zie Het maken van efficiëntere Microsoft Active Directory-Enabled-toepassingen voor meer informatie.

LDAP-paginaformaten optimaliseren

Wanneer resultaten met meerdere objecten worden geretourneerd als reactie op clientaanvragen, moet de domeincontroller de resultatenset tijdelijk opslaan in het geheugen. Het vergroten van de paginagrootten veroorzaakt meer geheugengebruik en kan items onnodig uit de cache verouderen. In dit geval zijn de standaardinstellingen optimaal. Er zijn verschillende scenario's waarin aanbevelingen zijn gedaan om de instellingen voor het paginaformaat te verhogen. U wordt aangeraden de standaardwaarden te gebruiken, tenzij deze specifiek zijn geïdentificeerd als ontoereikend.

Wanneer query's veel resultaten hebben, kan er een limiet van vergelijkbare query's worden aangetroffen die gelijktijdig worden uitgevoerd. Dit gebeurt omdat de LDAP-server een globaal geheugengebied kan verwijderen dat bekend staat als de cookiegroep. Het kan nodig zijn om de grootte van de groep te vergroten, zoals wordt beschreven in hoe cookies van LDAP-servers worden verwerkt.

Zie Windows Server 2008 en nieuwere domeincontroller retourneert slechts 5000 waarden in een LDAP-antwoord om deze instellingen af te stemmen.

Bepalen of indexen moeten worden toegevoegd

Het indexeren van kenmerken is handig bij het zoeken naar objecten met de kenmerknaam in een filter. Indexering kan het aantal objecten verminderen dat moet worden bezocht bij het evalueren van het filter. Dit vermindert echter de prestaties van schrijfbewerkingen omdat de index moet worden bijgewerkt wanneer het bijbehorende kenmerk wordt gewijzigd of toegevoegd. Het verhoogt ook de grootte van de directorydatabase, hoewel de voordelen vaak wegen tegen de kosten van opslag. Logboekregistratie kan worden gebruikt om de dure en inefficiënte query's te vinden. Zodra dit is geïdentificeerd, kunt u overwegen om een aantal kenmerken te indexeren die worden gebruikt in de bijbehorende query's om de zoekprestaties te verbeteren. Zie Hoe Active Directory-zoekopdrachten werken voor meer informatie over hoe Active Directory-zoekopdrachten werken.

Scenario's die voordeel hebben bij het toevoegen van indexen

  • Clientbelasting bij het aanvragen van de gegevens genereert aanzienlijk CPU-gebruik en het gedrag van de clientquery kan niet worden gewijzigd of geoptimaliseerd.

  • De clientbelasting genereert aanzienlijke schijf-I/O op een server vanwege een niet-geïndexeerd kenmerk en het gedrag van de clientquery kan niet worden gewijzigd of geoptimaliseerd.

  • Een query duurt lang en wordt niet binnen een acceptabel tijdsbestek voor de cliënt voltooid door een gebrek aan dekkende indices.

  • Grote hoeveelheden query's met een hoge duur veroorzaken het verbruik en de uitputting van ATQ LDAP-threads. Bewaak de volgende prestatiebalansen:

    • Latentie van NTDS\Aanvraag : dit is afhankelijk van hoe lang het duurt voordat de aanvraag wordt verwerkt. Active Directory annuleert aanvragen na 120 seconden (standaardinstelling), maar de meeste zouden veel sneller moeten worden uitgevoerd en extreem langlopende query's zouden niet op moeten vallen in de totale cijfers. Zoek naar wijzigingen in deze basislijn in plaats van absolute drempelwaarden.

      Note

      Hoge waarden hier kunnen ook indicatoren zijn van vertragingen in 'proxying'-aanvragen voor andere domeinen en CRL-controles.

    • NTDS\Geschatte wachtrijvertraging : dit moet in het ideale geval bijna 0 zijn voor optimale prestaties, omdat aanvragen geen tijd besteden aan onderhoud.

Deze scenario's kunnen worden gedetecteerd met behulp van een of meer van de volgende benaderingen:

Andere overwegingen voor indexen

  • Zorg ervoor dat het maken van de index de juiste oplossing is voor het probleem nadat het afstemmen van de query is uitgeput als optie. Het juiste formaat van hardware is erg belangrijk. Indexen moeten alleen worden toegevoegd wanneer de juiste oplossing is om het kenmerk te indexeren en geen poging om hardwareproblemen te verdoezelen.

  • Indexen vergroten de grootte van de database met een minimum van de totale grootte van het kenmerk dat wordt geïndexeerd. Een schatting van de databasegroei kan daarom worden geëvalueerd door de gemiddelde grootte van de gegevens in het kenmerk te nemen en te vermenigvuldigen met het aantal objecten dat het kenmerk heeft ingevuld. Over het algemeen komt dit neer op een toename van ongeveer 1% in de databasegrootte. Zie Hoe het gegevensarchief werkt voor meer informatie.

  • Als zoekgedrag voornamelijk wordt uitgevoerd op organisatie-eenheidsniveau, kunt u overwegen om te indexeren voor zoekopdrachten in containers.

  • Tuple-indexen zijn groter dan normale indexen, maar het is veel moeilijker om de grootte te schatten. Gebruik de schattingen van de normale indexgrootte als de bodem voor groei, met een maximum van 20%. Zie Hoe het gegevensarchief werkt voor meer informatie.

  • Als zoekgedrag voornamelijk wordt uitgevoerd op organisatie-eenheidsniveau, kunt u overwegen om te indexeren voor zoekopdrachten in containers.

  • Tuple-indexen zijn nodig om mediale zoekreeksen en uiteindelijke zoekreeksen te ondersteunen. Tuple-indexen zijn niet nodig voor initiële zoekreeksen.

    • Initiële zoekreeks – (samAccountName=MYPC*)

    • Mediale zoekreeks - (samAccountName=*MYPC*)

    • Laatste zoekreeks – (samAccountName=*MYPC$)

  • Als u een index maakt, wordt schijf-I/O gegenereerd terwijl de index wordt gebouwd. Dit wordt gedaan op een achtergrondthread met een lagere prioriteit en binnenkomende aanvragen krijgen prioriteit boven de indexbuild. Als de capaciteitsplanning voor de omgeving correct is uitgevoerd, moet dit transparant zijn. Schrijfintensieve scenario's of een omgeving waarin de belasting van de domeincontrolleropslag onbekend is, kan de clientervaring echter verslechteren en moet buiten kantooruren worden uitgevoerd.

  • Invloed op replicatieverkeer is minimaal omdat het bouwen van indexen lokaal plaatsvindt.

Zie het volgende voor meer informatie:

Aanvullende verwijzingen

  • Last updated on