Tag: promon

Promon – analiza danych 3

Dziś napiszę znowu o promonie odpowiadając przy okazji na kilka Waszych pytań, za które bardzo dziękuję.

Pierwsze dotyczy strojenia parametru -spin (tylko dla licencji serwera Enterprise).
Parametr „Spin Lock Retries” (–spin N) służy do określania, ile razy proces próbuje uzyskać zatrzask (latch) do zablokowanego zasobu w pamięci współdzielonej przed “pójściem na drzemkę”. Po wstrzymaniu procesu na określoną liczbę milisekund, proces uruchamia się ponownie i ponownie próbuje uzyskać zatrzask. Proces ten bardzo obciąża procesor dlatego uzywa się go wyłącznie w maszynach wieloprocesorowych, choć w starych systemach jednoprocesorowych zalecano użycie tego parametru z wartością 1, ze względu na to, że i tak był on szybszy niż mechanizm oparty na semaforach. Liczba nieudanych prób uzyskania zatrzasku określana jest w promonie Latch timeouts. Im jest ich więcej tym częściej dochodzi do konfliktów między zatrzaskami i tym gorsza jest wydajność bazy danych.

Domyślne obliczenie brokera bazy danych to 6.000 x liczba procesorów zgłoszonych przez system operacyjny, co prawdopodobnie było odpowiednie, gdy na serwer przypadało 2 lub 4 rdzenie/procesory, ale teraz, w przypadku maszyn wielordzeniowych z 16 lub więcej rdzeniami, automatycznie obliczona liczba jest prawdopodobnie zbyt wysoka.
Np. w moim laptopie procesor ma 4 rdzenie i 8 wątków i parametr ten ma domyślną wartość 48.000.
Miejcie więc na względzie aby sprawdzić tę wartość w promonie:
R&D -> 4. Administrative Functions 4. Adjust Latch Options


W tym samym miejscu możemy zmienić tę wartość online (podopcja 1).

Expert z White Star Software uważa, że wartości z przedziału 5.000 do 20.000 są wystarczające dla zdecydowanej większości baz danych, więc nie ma co szaleć. Należy przede wszystkim monitorować wykorzystanie CPU i w razie gdy osiąga ono duże wartości (90% lub więcej) zmniejszyć -spin online.

Analizę timeoutów możemy podejrzeć na poniższym ekranie promona – ostatni wiersz.
R&D -> 3. Other Displays -> 1. Performance Indicators -> Latch timeouts

Drugim parametrem, o którym chcę tutaj napisać jest -lruskips dostępny także tylko dla serwera Enterprise i ma związek z zatrzaskami przy próbie dostępu do zasobu w puli buforów.
Łańcuch LRU (Least Recently Used) składa się ze wskaźników do buforów w puli i przy każdym odczycie z tej puli (dla -lruskips = 0) potrzebne jest uzyskanie zatrzasku aby uaktualnić ten łańcuch. Jeśli ustawimy -lruskips = 100 (dobra wartość stosowana obecnie domyślnie) to próba uzyskania zatrzasku LRU będzie co 100-tny dostęp do bufora, co poprawia współbieżność i wydajność.
Wartość parametru możemy dostosować także online w tym samym miejscu promona co dla -spin (patrz poniższy obrazek). Jeśli mamy dwie pule buforów (-B i -B2) to możemy określić osobno -lruskip i -lruskip2. Mechanizm ten nie jest wykorzystywany w prywatnej puli buforów.

Administracja , ,

Promon – analiza danych 2

Powracając do tematyki związanej z tym najbardziej znanym narzędziem dla administratorów baz, chciałbym napisać dwa słowa o ukrytej opcji, którą, jak się okazuje, nie wszyscy znają.
Kiedyś była to opcja R&D, niewidoczna z głównego menu ale to było dawno temu.
Drugie menu było bardziej ukryte. Trzeba było napisać devdbh, Enter i następnie 6.
Obecnie w nowym promonie ta opcja jest widoczna właśnie na pozycji 6 w meny R&D chociaż możemy wejść do niej także “po staremu”.

Zawiera zaawansowane opcje dogłębnego monitorowania aktywności i wydajności systemu baz danych OpenEdge.

Jak widać lista jest całiem długa, ale są to informacje dla zaawansowanych administratorów, lub raczej dla techsupportu PSC. Może się zdarzyć że będziemy poproszeni o przesłanie konkretnych danych z tej listy.

Powróćmy do danych, które możemy pobrać do własnej analizy. Myślę, że jednymi z najważniejszych są te związane z checkpointami.
Uruchamiam własny program generujący transakcje w bazie testowej (kopia sports2000) i wchodzę do promona.
W opcji R&D -> 1. Status Displays -> 9. BI Log sprawdzam parametry zapisu BI na dysku. Blok BI ma 8kB, a cluster tylko 512 kB (domyślna wartość). Zobaczmy jaki to będzie miało efekt w działaniu.

Przechodzę do głównego menu, a następnie 3. Other Displays -> 4. Checkpoints.
Popatrzmy na poniższą analizę. Nie wygląda to dobrze…

Co oznaczają niektóre kolumny (wg dokumentacji):
Dirty – liczba zmodyfikowanych buforów zaplanowanych do zapisania.
CPT Q – Liczba buforów zapisanych z kolejki checkpoint przez procesy APW.
Scan – Liczba buforów zapisanych przez procesy APW podczas cyklu skanowania.
APW Q – Liczba buforów zapisanych przez kolejkę APW i zastąpionych w łańcuchu LRU przez procesy APW.
DB Writes – Całkowita liczba buforów bazy danych zapisanych na końcu checkpointu.

Administratorzy baz chcą aby odstęp między checkpointami (kolumna Len) był rzędu kilku minut, a tu mamy 2 sekundy. Ponadto podczas checkpointu jest nienaturalnie duża ilość zapisów na dysk – kolumna DB Writes (ten parametr w starszych wersjach jest określany jako Flushes). Tak liczne zapisy powodują spadek wydajności.
Nie uruchomiłem jeszcze procesu APW, więc kolejka APW jest pusta, ale i tak widać od razu, że trzeba koniecznie wydłużyć cluster. Zwiększę go zatem z 0.5 MB do 16 MB. Rozmiar bloku BI zwiększę przy okazji z 8 KB do 16 KB.
proutil [baza] -C truncate bi -bi 16384 -biblocksize 16

Ponieważ rozmiar clustra został zwiększony 32 razy to dostęp między checkpointami zwiększy się z 2-3 sekund do ok. 70 sekund. Po odczekaniu zobaczmy jak teraz wygląda analiza checkpointów.

Zobaczmy, że wartości Dirty nie przekraczają wartości DB Writes, jak poprzednio. Oznacza to, że jest dość czasu podczas checkpointu żeby zapisy zostały dokonane. Jednakże duża liczba tych zapisów może powodować spowolnienie systemu podczas checkpointu. Nie mamy tu na razie procesów asynchronicznych (tylko serwer Enterprise) i kolumna CPT Q pokazuje same zera.

A teraz co się zmieni po uruchomieniu procesu APW (niebieska ramka). Wszystkie bufory do zapisu są umieszczone w kolejce checkpoint i zapisane przez procesy APW tak, że podczas checkpointu nie ma już żadnych zapisów i system nie będzie spowalniał

Metoda wydłużenia czasu między checkpointami jest dość prosta i możemy pokusić się o dalsze zwiększenie clustra BI żeby czas wynosił tutaj 2-3 a nawet 5 minut. Pytanie tylko czy nasze dyski są dostatecznie szybkie aby temu podołać. Clustra nie można zwiększać bez końca bez żadnych konsekwencji.

W następnym wpisie napiszę o prostym teście jak można taką graniczną wartość określić.

Na koniec jeszcze mała uwaga dotycząca zbierania danych z promona poprzez skrypt. Większość parametrów znajduje się w tablicach VST, zawierających tylko jeden rekord (podawana wartość to różnica wartości z danego pola w czasie) ale czasem tych rekordów jest więcej, jak w przypadku checkpointów. Nie ma dla nich w promonie opcji automatycznego odświeżania. Najłatwiej jest oczywiście napisać program w ABL ale jeśli nie mamy takiej możliwości, to obliczamy po ilu minutach zapełnią się dane wszystkich checkpointów na ekranie (tutaj ok. 15 minut) i ustawiamy uruchomienie skryptu zapisującego tylko ten ekran (np. w cronie) co ten czas.

Administracja , ,

Promon – analiza danych

Administratorzy baz danych stają czasem przed problemem: jak analizować parametry generowane w narzędziu promon w funkcji czasu. Wszystkie te parametry pochodzą z tablic VST i można łatwo napisać odpowiedni program w języku ABL. Problem polega jednak na tym, że administratorzy często nie mają uprawnień do kompilacji.
Sytuacja nie jest jednak beznadziejna i można sobie z nią poradzić bez większych problemów.

Promon to narzędzie które można obsługiwać ręcznie, przeglądając określone statystyki lub generować zrzuty ekranowe w sposób automatyczny. Zrzuty takie można potem analizować na różne sposoby. Wystarczy stworzyć wejściowy plik tekstowy, zawierający zestaw znaków sterujących, odpowiadający dokładnie takim samym klawiszom które użylibyśmy przeglądali określone statystyki ręcznie.

Zanim stworzymy taki plik, musicie wiedzieć, że dla wersji OE12 znajdują się w katalogu [DLC]\bin skrypty dla serwera bazy Enterprise: gather-script-enterprise.bat
oraz Workgroup: gather-script-wrkgrp.bat.
Wystarczy uruchomić taki skrypt na naszej bazie i powstanie plik wynikowy zawierający wiele ekranów z menu podstawowego oraz R&D. We wcześniejszych wersjach OE trzeba poszukać skryptu gather. Dokładniejszy opis jest w bazie wiedzy.
Dla naszych potrzeb stwórzmy prostszy plik sterujący promon_in.txt:

R&D  # Opcje R&D
5    # Adjust Monitor Options
1    # Display page length
9999 # Enter 9999 for length
3    # Monitor sampling interval
30   # Ustaw na 30 sek.
4    # Pause between displays
30   # Ustaw na 30 sek.
6    # Number of auto repeats 
10   # Ustaw 10 odświeżeń
t    # Powrót do głównego menu R&D 
2    # Activity Displays
1    # Summary
A    # Tryb automatyczny

Plik ten zawiera określone wybory menu i ustawienia oraz komentarz. Oczywiście dla wysterowania promona komentarz musimy usunąć. Plik więc będzie wyglądał następująco:

R&D
5
1
9999
3
30
4
30
6
10
t
2
1
A

W tym prostym przykładzie dostaniemy zrzut 10 ekranów z ogólnej aktywności bazy. Każdy ekran wygeneruje się co 30 sekund.
Uruchamiamy zatem promona na bazie testowej poleceniem:
promon [baza] < promon_in.txt > promon_out.txt
Można użyć opcjonalnie parametru -NL, szczególnie do analizy problemów z konfliktami aktywności w pamięci współdzielonej. Tutaj można go pominąć. Nas będzie interesował parametr BI Writes.
Pominąłem jeden krok, uruchomiłem wcześniej program, który dokonuje losowo transakcji na tablicy Customer (kopia bazy sports2000). Krok ten zostawiam czytelnikom.

Promon wygeneruje plik wynikowy promon_out.txt, zawierający zrzuty ekranowe. Z uwagi na jego obszerność wyświetlam tylko interesujący nas fragment. Zgodnie z ustawieniami plik zawiera 10 wygenerowanych takich ekranów.

Event                  Total  Per Sec |Event                  Total  Per Sec

Commits            17245004      99.4 |DB Reads                332       0.0
Undos               1864747      10.8 |DB Writes            904278       5.2
Record Reads       38455612     221.7 |BI Reads              61998       0.4
Record Updates     15614825      90.0 |BI Writes           1380881       8.0
Record Creates      1630171       9.4 |AI Writes                 0       0.0
Record Deletes      1630180       9.4 |Checkpoints           20601       0.1
Record Locks       82489712     475.5 |Flushed at chkpt     883672       5.1
Record Waits              0       0.0 |Active trans              0

Dla nas jest ważne aby wyekstrahować określone informacje, np. linie zawierające określone dane, jak badany parametr BI Writes.
W systemie Windows możemy posłużyć się komendą findstr. Poniżej ściąga jak używać tej komendy:
findstr [szukane słowo] promon_out.txt > wynik.txt
findstr /C:”[szukana fraza]” promon_out.txt > wynik.txt
W systemie Linux/Unix możemy posłużyć się komendą grep.
Uruchamiamy tutaj następująca komendę.
findstr /C:”BI Writes” promon_out.txt > bi.txt
Zawartość pliku bi.txt wygląda następująco.

Record Updates        10859     362.0 |BI Writes               938      31.3
Record Updates        10879     362.6 |BI Writes              1005      33.5
Record Updates        10476     349.2 |BI Writes               872      29.1
Record Updates        10930     364.3 |BI Writes              1005      33.5
Record Updates        10933     364.4 |BI Writes               938      31.3
Record Updates        10850     350.0 |BI Writes               938      30.3
Record Updates        10578     352.6 |BI Writes               939      31.3
Record Updates        10847     361.6 |BI Writes               938      31.3
Record Updates        10855     361.8 |BI Writes              1006      33.5
Record Updates        10828     360.9 |BI Writes               938      31.3

Juz jest nieźle, bo mamy tylko 10 potrzebnych linii. Teraz trzeba zaimportować te dane do arkusza jak Excell czy LibreOffice. Tu posłużyłem się LibreOffice, w którym można wygodnie ustalić miejsca podziału kolumn.

Niepotrzebne kolumny można usunąć. Potrzebujemy jeszcze osi czasu, ale to prosta sprawa bo odczytujemy tylko czas dla pierwszego odczytu, dodajemy 30 sekund do następnego a pozostałe czasy wygenerują się automatycznie po przeciągnięciu kursorem myszy.

Na koniec generujemy wykres w celu analizy. Tutaj jest akurat w Excellu.

Jak widać cały proces nie jest trudny i gdy raz go przejdziemy nie będzie kłopotu aby powtarzać go dla innych danych.
Następnym razem napiszę o jeszcze kilku analizach w promonie.

Administracja ,