W2K.PL

Jump to Comments

Karol (przy okazji okazało się że prowadzi bloga, o którym nie wiedziałem ale już dodałem do subskrypcji) podrzuca mi czasami przy okazji spotkań lub przez e-mail ciekawe pytania. Tym razem podesłał mi pytanie następujące:

Co jest wydajniejsze dla samego LDAP w AD:
   *  duża ilość obiektów w jednym OU ( jakieś 10-20tys. kont)
   *  wiele OU w obrębie głównego OU i w nich mniejsze ilości
     obiektów(20 OU i w każdym po 1000 kont)?

Odpowiedziałem mu również przez e-mail ale pomyślałem, że temat może jeszcze kogoś zainteresować więc i tutaj go opiszę.

(cc) magic mudpuddle

Krótka odpowiedź na tak postawione pytanie jest następująca: “Z punktu widzenia operacji LDAP na bazie danych katalogu to nie ma znaczenia”. Kropka.

To teraz odpowiedź dłuższa, czyli klasyczne szkolne rozwinięcie i uzasadnienie ;).

Laboratorium …

Na potrzeby ćwiczenia utworzyłem dwa OU, w jednym umieściłem 20 tys obiektów użytkowników, w drugim 20 następnych OU a w każdym z nich po 1 tys użytkowników.

Mała dygresja – w celach czysto ćwiczebnych pierwsze 20 tys użytkowników założyłem korzystając z admod.exe w drugim zaś przypadku, zarówno OU jak i użytkowników założyłem korzystając z nowych poleceń Powershell z W2008R2. Wygoda podobna, polecenie admod było krótkie (dzięki wbudowanym skrótom), skrypt PoSh miał jakieś 4 linijki. Następnym razem zmierzę jeszcze czas operacji dla porównania.

Krótkie ćwiczenie polegało na wykonaniu podobnego zapytania LDAP, wyszukującego 1 użytkownika po jego nazwie logowania w każdym z OU. Wykonałem je przy pomocy ADFIND i następującej składni:

adfind -b <OU> -s subtree  -f "(samaccountname=<nazwa użytkownika>)" -stats+only

Przełącznik -statst+only powoduje, że wynikiem zapytania będą tylko statystyki zapytania (dla tych od SQLa, na przykład Pawła gdyby się tutaj zabłąkał – to coś jak execution plan ;))

#1 – wyszukanie użytkownika w ramach 20 tys. obiektów w pojedynczym OU

Statistics
=================================
Elapsed Time: 47 (ms)
Returned 1 entries of 1 visited - (100.00%)

Used Filter:
(sAMAccountName=1038_testusr)

Used Indices:
idx_sAMAccountName:1:N

Pages Referenced        : 31
Pages Read From Disk    : 1
Pages Pre-read From Disk: 0

Analysis
———————————
Hit Rate of 100.00% is Efficient

Indices used:

Index Name  : idx_sAMAccountName
Record Count: 1  (estimate)
Index Type  : Normal Attribute Index

#2 – wyszukanie użytkownika w ramach 20 tys. obiektów rozłożonych po wielu OU

Statistics
=================================
Elapsed Time: 0 (ms)
Returned 1 entries of 1 visited - (100.00%)

Used Filter:
(sAMAccountName=11520_user)

Used Indices:
idx_sAMAccountName:1:N

Pages Referenced        : 33
Pages Read From Disk    : 0
Pages Pre-read From Disk: 0

Analysis
———————————
Hit Rate of 100.00% is Efficient

Indices used:

Index Name  : idx_sAMAccountName
Record Count: 1  (estimate)
Index Type  : Normal Attribute Index

Na pierwszy rzut oka widać że zarówno efektywność zapytań, jak i użyte indeksy nie różnią się pomiędzy sobą. W drugim przypadku jednak czas zapytania jest o wiele dłuższy. Czy winę za to ponosi fakt, że 20 tys. obiektów znajdowało się w pojedynzym kontenerze? Otóż nie i mogłem tutaj przedstawić dw aidentyczne wyniki ale wybrałem ten właśnie w celach dydaktycznych. W pierwszym przypadkiem elementem kluczowym dla wydajności zapytania jest ten element:

Pages Read From Disk    : 1

Oznacza to, że wynik zapytania nie znajdował się w pamięci operacyjnej i konieczne było odczytanie z dysku jednej strony bazy danych katalogu. Powtórzmy to zapytanie raz jeszcze:

Statistics
=================================
Elapsed Time: 0 (ms)
Returned 1 entries of 1 visited - (100.00%)

Used Filter:
(sAMAccountName=1038_testusr)

Used Indices:
idx_sAMAccountName:1:N

Pages Referenced        : 27
Pages Read From Disk    : 0
Pages Pre-read From Disk: 0

Analysis
———————————
Hit Rate of 100.00% is Efficient

Indices used:

Index Name  : idx_sAMAccountName
Record Count: 1  (estimate)
Index Type  : Normal Attribute Index

Jak widać w tym wypadku wynik już jest zdecydowanie lepszy. Wynika to z faktu, że raz odczytane dane są (o ile to możliwe) w pamięci operacyjnej w ramach cache procesu lsass.exe.

Przy okazji, możliwość prezentacji statystyk dostępu do dysków (w zasadzie stron bazy danych) w statystykach LDAP to nowość w Windows 2008.

Wnioski …

Czego to ćwiczenie dowodzi? Jeżeli spojrzymy tylko i wyłącznie na wydajność operacji LDAP to widzimy, że przy odpowiednio zadanym zapytaniu (indeksy) rozłożeni obiektów w katalogu nie ma znaczenia. Należy pamiętać, że pod warstwą LDAP katalogu jest silnik bazy danych ESE i to tam wykonywane są operacje związane z wyszukiwaniem obiektów itp. Tak więc hierarchia obiektów nie będzie miała tutaj większego znaczenia. To co ma znaczenie to efektywność zadawanych zapytań oraz ewentualnie konfiguracja i wykorzystanie zasobów systemowych.

Wnioski z ćwiczenia są więc następujące:

• Dla wydajności operacji wykonywanych na bazie danych katalogu nie jest ważne rozłożenie obiektów w strukturze logicznej tegoż. To co jest istotne,  jak w przypadku każdej bazy danych, to wykorzystanie odpowiednich indeksów i zadawanie efektywnych zapytań LDAP oraz o ile to możliwe ograniczenie odwołań do dysku (patrz następny punkt).
• W przypadku serwerów pełniących rolę kontrolerów domeny warto zadbać o to, aby posiadały one taką ilość pamięci RAM aby jak najwięcej danych z bazy DIT mogło zostać umieszzone w pamięci podręcznej. W przypadku baz danych DIT zbliżających się do 3GB należy użyć systemów 64-bitowych w celu zapewnienia odpowiednich możliwości adresowania pamięci > 3GB.

I tym dzisiejsze laboratorium zakończymy.