Update verfügbar der LDAP-Anfragen beschleunigt

Hallo!

Ihr habt schon einige Zeit keinen Blog mehr von uns gehabt. Man könnte sagen, wir hatten viel zu tun. Manchmal kommt bei der Arbeit auch etwas Interessantes und für viele Kunden Wichtiges heraus.

Wir haben nun einen Update für den LDAP Server von Windows Server 2008 R2 bekommen, der für viele Kunden eine deutliche Verbesserung der Performance mit sich bringen dürfte.

Der KB Artikel dazu ist: 2862304        AD DS or AD LDS responds slowly to complex LDAP query that has a deeply nested filter on Windows Server 2008 R2 server

Die Verbesserung des LDAP Query Optimizers ist in Windows 2012 R2 bereits an Bord, und die wichtigsten Verbesserungen wurden damit auf die ältere Version portiert. Ein Update für Windows Server 2012 ist ebenfalls in Arbeit.

Windows Server 2012 R2 hat zusätzlich noch bessere Details zur Verbesserung der Query im Event 1644 für suboptimale Queries und auch in der STATS-Control Antwort. Ein Teil der Verbesserungen in Event 1644 sind ebenfalls zurück portiert worden: https://support.microsoft.com/kb/2800945/en-us

Es gibt leider noch keine öffentlichen Informationen zu den Verbesserungen des Query Optimizers und der Events 1644.

Wie sieht das Reporting für die Verbesserung aus?

Ein Beispiel für eine Query auf älteren DCs wird so bearbeitet:

     Call Time: 578 (ms)

     Entries Returned: 111

     Entries Visited: 18784

     Used Filter: ( | ( & ( | (cn=user1*) (userPrincipalName= user1*) ) ( | (objectClass=person) (cn= user1*) ) ) ( & (cn= user1*) (objectClass=person) ) )

     Used Indexes: DNT_index:7550:N;

     Pages Referenced: 169205

     Pages Read From Disk: 0

     Pages Pre-read From Disk: 426

     Clean Pages Modified: 0

     Dirty Pages Modified: 1

     Log Records Generated: 0

     Log Record Bytes Generated: 0

So sieht die neue STATS Control Antwort aus:

     Call Time: 125 (ms)

     Entries Returned: 111

     Entries Visited: 111

     Used Filter: ( | ( & ( | (cn=user1*) (userPrincipalName= user1*) ) ( | (objectClass=person) (cn= user1*) ) ) ( & (cn= user1*) (objectClass=person) ) )

     Used Indexes: idx_cn:121:N;idx_userPrincipalName:0:N;

     Pages Referenced: 2826

     Pages Read From Disk: 23

     Pages Pre-read From Disk: 0

     Clean Pages Modified: 0

     Dirty Pages Modified: 0

     Log Records Generated: 0

     Log Record Bytes Generated: 0

Getting 111 entries:

Das ist doch mal ein Unterschied. Windows Server 2012 R2 ist schneller, obwohl der Server auf IO für 23 Datenbankseiten warten musste.

In den „Used Indexes“ sieht man, dass im Gutfall zwei recht spezifische Indizes ausgewählt wurden. Mit dem alten Optimizer sehen Sie allgemeine Indizes wie „DNT_index“ oder „Ancestors_index“. Damit werden oft viele Objekte in den Speicher geholt „Entries Visited“. Die Query ist auch schneller, weil deswegen auch wesentlich weniger Datenbankseiten angefasst wurden (Pages Referenced). Wenn das ohne Disk IO stattfindet, ergibt das eine hohe CPU Zeit, und ist ggf. trotzdem langsam.

Bei einer Wiederholung auf Windows Server 2012 R2 habe ich den Threshold für Events 1644 herab gesetzt. Der Vorgang ist in diesem Blog beschrieben: https://blogs.technet.com/b/ad/archive/2008/04/01/how-to-create-a-mosiac-of-user-thumbnails-in-aduc-dsa-msc.aspx

Die Kurzfassung ist, für den Test Diagnostics-Eintrag „15 Field Engineering“ auf „5“ und diese Registry-Einträge auf „1“ zu setzen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Expensive Search Results Threshold (reg_dword)
Inefficient Search Results Threshold (reg_dword)

Damit es auch etwas Neues zu sehen gibt, habe ich einen Filter verwendet, den auch der neue Query Optimizer nicht verbessern kann. In dem Fall geht es um ein nicht indiziertes Attribut. Ich bekomme damit folgenden Event:

Log Name: Directory Service

Source: Microsoft-Windows-ActiveDirectory_DomainService

Event ID: 1644

Task Category: Field Engineering

Level: Information

Description:

Internal event: A client issued a search operation with the following options.

Client:

[::1]:52009

Starting node:

DC=w7-child1,DC=herbertm-w7,DC=com

Filter:

 (printerName=gener*) 

Search scope:

subtree

Attribute selection:

objectClass,name,description,canonicalName

Server controls:

Visited entries:

235

Returned entries:

3

Used indexes:

Ancestors_index:313:N;

Pages referenced:

2344

Pages read from disk:

0

Pages preread from disk:

0

Clean pages modified:

0

Dirty pages modified:

0

Search time (ms):

0

Attributes Preventing Optimization:

printerName

Deswegen ergibt das eine Volltextsuche in vielen Objekten. Das sind alle Objekte, die per Schema Definition das Attribut haben können.

Es ist mittlerweile schwerer einen Filter zu erstellen, auf den der Query Optimizer keine Antwort kennt und wo es einen entsprechenden Hinweis gibt.

Was ist zu tun?

Ihr habt relativ gut beschäftige AD- oder LDS-Server. Nachdem die aber immer gute Antwortzeiten geliefert haben, war es nie wichtig nachzusehen, was die so beschäftigt den ganzen Tag.

Mit diesem Update und vor allem den verbesserten Möglichkeiten von Windows Server 2012 R2 könnt Ihr mehr Bandbreite aus dem Server holen und auch besser untersuchen, was denn eine bestimmte Query so langsam macht.

Ein schon etwas älterer Einstieg in das Thema ist auch der Blog von Hans.

Viel Erfolg mit Euren jetzt noch schnelleren Servern!

Euer

Herbert