Witam serdecznie,
od jakiegoś czasu użytkownicy naszej aplikacji działającej w jednej z naszych firm klienckich skarżą się, że aplikacja działa im coraz wolniej, a czasami zwalnia im do poziomu w który nie są w stanie pracować.
Pisząc "aplikacja zwalnia" - mam na myśli ekstremalnie wolne odświeżanie browserów.
1. Baza danych jest wystawiona na serwerze Linuxowym w środowisku OpenEdge 10.0B.
2. Klient bazy dla Windows (również OpeneEdge10.0B) jest zainstalowany na tym samym serwerze Linuxowym i udostępniony w sieci przy pomocy Samby. Komputery klienckie mają zmapowany w/w udział sieciowy z serwera jako dysk sieciowy i z niego uruchamiają naszą aplikację.
3. Nasza aplikacja działa zarówno w wersji graficznej jak i znakowej. W obydwu wersjach aplikacja działa wolno. Wersja znakowa działa odrobinę lepiej. Użytkownicy wersji znakowej aplikacji łączą się do serwera przy pomocy programu PuTTY skonfigurowanej w taki sposób, że po zalogowaniu do serwera automatycznie odpala im się nasza aplikacja.
4. Informatyk z firmy klienckiej sprawdził ruch sieciowy do serwera na którym stoi baza i stwierdził, że sieć nie jest w jakiś szczególny sposób obciążona.
5. Serwer nie jest przeciążony - w sytuacji gdy aplikacja zwalnia do poziomu uniemożliwiającego pracę, procesy Progressa zużywają do 30% zasobów CPU i MEM. Inne procesy również nie obciążają serwera.
6. Zrobiłem dump bazy, następnie wczytałem go przy pomocy bulkloadera i przeindeksowałem, ale nie wpłynęło to w żaden sposób na działanie aplikacji.
Baza danych jest wystartowana z następującymi parmaterami:
-n 30 -Mi 3 -B 600000 -nb 50 -L 120000 -bibufs 25
Przyznam, że zastanawia mnie parametr -bibufs. W innych firmach korzystających z naszego oprogramowania, bazy są startowane bez tego parametru...
Co możemy zrobić, aby poprawić działanie bazy danych u naszego klienta?
Z góry dziękuję za odpowiedź i pozdrawiam,
Adam Rzońca
ZETO Białystok
>>>>od jakiegoś czasu (...)
Od jakiego czasu? Czy to znaczy że wcześniej wszystko działało bez problemów? Jakie mogły być potencjalne zmiany w czasie gdy spowolnienie zostało zauważone po raz pierwszy?
Aby konkretnie zidentyfikować przyczynę potrzebujemy więcej faktów i wskaźników z promon-a. Czy występują BI waits? Jeżeli tak to liczba buforów (-bibufs) jest za mała. Wątpię, że to jest wąskie gardło, gdyż domyślnie (parametr nie ustawiony) alokujemy tylko 5 buforów a w tym przypadku jest ich 25.
Jaka jest częstotliwość checkpoint-ów? Jaki jest rozmiar klastra BI? Jaki jest rozmiar bloków (BI/AI). Czy After Imaging jest w użyciu? Czy wymagane procesy BIW/AIW/APW są uruchomione?
Czy występują latch timeouts? Jakie jest ustawienie -spin? Czy suma wszystkich obiektów w bazie (tabel + indeksów) jest większa niż 1024? Jeżeli tak, to czy parametr -omsize jest w użyciu?
Pozdrawiam
Marek
@Marek
Użytkownicy twierdzą, że baza zaczęła zwalniać do prędkości uniemożliwiającej im pracę w okolicach Lipca/Sierpnia.
Zmiany jakie zachodzą w bazie to przyrost ilości danych :) oraz (w sumie teraz sobie o tym przypomniałem) skonfigurowaliśmy im skrypt, odpalany cyklicznie przez Linuxa, łączący się do bazy w trybie batchowym i wyprowadzający dane do pliku. Coś takiego było kiedyś skonfigurowane w innej firmie, ale z ich strony nie było żadnych sygnałów o spowalnianiu bazy.
Spróbujemy wyłączyć im tę funkcjonalność i zobaczymy, czy coś się zmieni...
Promon wyświetlił mi następujące dane:
Status: Database
Database was started at: 10/31/17 08:23
It has been up for: 3:18:30
Database state: Open (1)
Database damaged flags: None
Integrity flags: None
Most recent database open: 10/31/17 08:23
Previous database open: 10/31/17 08:23
Local cache file time stamp: 09/14/17 17:13
Database block size: 4096 bytes
Number of blocks allocated: 6974038 (27896124 kb)
Empty blocks: 3939725 (56 %)
Free blocks: 206 (0 %)
RM blocks with free space: 26 (0 %)
Last transaction id: 2645014
Highest table number defined: 0
Database version number: 150
Shared memory version number: 10036
Activity: Summary
11:42:28 10/31/17 08:23 to 10/31/17 11:22 (3 hrs 0 min)
Event Total Per Sec |Event Total Per Sec
Commits 27517 2.6 |DB Reads 3710713 344.2
Undos 38 0.0 |DB Writes 24144 2.2
Record Reads 145429K 13813.1 |BI Reads 3246 0.3
Record Updates 57961 5.4 |BI Writes 5449 0.5
Record Creates 15006 1.4 |AI Writes 0 0.0
Record Deletes 1128 0.1 |Checkpoints 58 0.0
Record Locks 194957 296.4 |Flushed at chkpt 23953 2.2
Record Waits 5 0.0
Rec Lock Waits 0 % BI Buf Waits 0 % AI Buf Waits 0 %
Writes by APW 0 % Writes by BIW 0 % Writes by AIW 0 %
DB Size: 26 GB BI Size: 22 MB AI Size: 0 K
Empty blocks: 3939874 Free blocks: 206 RM chain: 90
Buffer Hits 98 % Active trans: 1
4 Servers, 24 Users (5 Local, 19 Remote, 0 Batch), 0 Apws
Status: BI Log
Before-image cluster age time: 0 seconds
Before-image block size: 8192 bytes
Before-image cluster size: 512 kb (524288 bytes)
Number of before-image extents: 1
Before-image log size (kb): 22648
Bytes free in current cluster: 494105 (95 %)
Last checkpoint was at: 10/31/17 11:39
Number of BI buffers: 25
Full buffers: 0
*** After-image logging is not enabled. ***
>>>>> Czy wymagane procesy BIW/AIW/APW są uruchomione?
Jak mogę to sprawdzić?
Parametr -spin nie jest ustawiony. Rozumien, że "latch timeouts" są związane z tym parametrem?
Liczba tabel i indeksów (obliczona przy pomocy select count(*) from _storageobject.) wynosi: 1354.
Parametr -omsize nie jest ustawiony.
Dzisiaj po telefonie od użytkownika zrestartowałem bazę, więc pewnie dane z Promona mogą być nie takie, jakie w chwili przycięcia bazy danych...
Dziękuję za zainteresowanie i pozdrawiam,
Adam Rzońca
@Piotr
>>>> Jak wyglada obciazenie dyskow?
Będę musiał to jeszcze przeanalziować.
>>>>> Ta wolna praca dotyczy calej aplikacji, czy tylko wybranych browserow ?
Całej aplikacji.
Dzięki za info o VST _TableStat i _UserTableStat.
Zainteresuję się tym tematem.
Dziękuję za zainteresowanie i pozdrawiam,
Adam Rzońca
Panie Adamie,
Rozwiązanie problemu związanego ze zwolnienie systemu aplikacji jest zwykle złożone. Należy przyjrzeć się wielu parametrom. Ze strony Galeosa możemy zaproponować konsultację naszych konsultantów ew. usługę zespołu specjalistów Progress MDBA.
Pozdrawiam,
Piotr Tucholski
- APW, BIW nie sa wlaczone – trzeba wlaczyc
- -spin jak najbardziej trzeba
- Widac wzglednie duzo readow z DB – trzeba spojrzec na te VST ktore poslalem poprzednio, konkretnie wlasnie na ilosc readow
- AfterImaging nie jest wlaczony – ja bym sie bal ;) Ale to juz inny temat.
@Marek
Problemy użytkownicy zaczęli zgłaszać na przełomie Lipca/Sierpnia.
Teraz sobie przypomniałem, że w tym czasie skonfigurowaliśmy im cyklicznie uruchamiany przez Linuxa skrypt, który łączy się do bazy w trybie baczowym i wyprowadza dane do pliku. Spróbujemy wyłączyć im tę funkcjonalność i zobaczymy co się stanie.
Promon wyświetla mi m.in następujące wyniki:
Status: Database
12:39:13
Database was started at: 10/31/17 08:23
It has been up for: 4:15:56
Database state: Open (1)
Database damaged flags: None
Integrity flags: None
Most recent database open: 10/31/17 08:23
Previous database open: 10/31/17 08:23
Local cache file time stamp: 09/14/17 17:13
Database block size: 4096 bytes
Number of blocks allocated: 6974038 (27896124 kb)
Empty blocks: 3939614 (56 %)
Free blocks: 206 (0 %)
RM blocks with free space: 3 (0 %)
Last transaction id: 2647562
Highest table number defined: 0
Database version number: 150
Shared memory version number: 10036
Activity: Summary
12:40:44 10/31/17 08:23 to 10/31/17 12:14 (3 hrs 51 min)
Event Total Per Sec |Event Total Per Sec
Commits 29907 2.2 |DB Reads 3719448 268.0
Undos 41 0.0 |DB Writes 28405 2.0
Record Reads 173507K 12801.4 |BI Reads 3279 0.2
Record Updates 66778 4.8 |BI Writes 6731 0.5
Record Creates 18349 1.3 |AI Writes 0 0.0
Record Deletes 1528 0.1 |Checkpoints 69 0.0
Record Locks 4067678 293.1 |Flushed at chkpt 28203 2.0
Record Waits 5 0.0
Rec Lock Waits 0 % BI Buf Waits 0 % AI Buf Waits 0 %
Writes by APW 0 % Writes by BIW 0 % Writes by AIW 0 %
DB Size: 26 GB BI Size: 22 MB AI Size: 0 K
Empty blocks: 3939647 Free blocks: 206 RM chain: 3
Buffer Hits 98 % Active trans: 0
4 Servers, 24 Users (5 Local, 19 Remote, 0 Batch), 0 Apws
Activity: BI Log
12:41:13 10/31/17 08:23 to 10/31/17 12:14 (3 hrs 51 min)
Total Per Min Per Sec Per Tx
Total BI writes 6731 29 0.48 0.23
BIW BI writes 0 0 0.00 0.00
Records written 379676 1641 27.36 12.70
Bytes written 35360784 152867 2547.79 1182.36
Total BI Reads 3279 14 0.24 0.11
Records read 70 0 0.01 0.00
Bytes read 5376 23 0.39 0.18
Clusters closed 69 0 0.00 0.00
Busy buffer waits 0 0 0.00 0.00
Empty buffer waits 456 2 0.03 0.02
Log force waits 0 0 0.00 0.00
Log force writes 0 0 0.00 0.00
Partial writes 2330 10 0.17 0.08
Activity: AI Log
12:41:31 10/31/17 08:23 to 10/31/17 12:14 (3 hrs 51 min)
Total Per Min Per Sec Per Tx
Total AI writes 0 0 0.00 0.00
AIW AI writes 0 0 0.00 0.00
Records written 0 0 0.00 0.00
Bytes written 0 0 0.00 0.00
Busy buffer waits 0 0 0.00 0.00
Buffer not avail 0 0 0.00 0.00
Partial writes 0 0 0.00 0.00
Log force waits 0 0 0.00 0.00
>>>> Czy After Imaging jest w użyciu? Czy wymagane procesy BIW/AIW/APW są uruchomione?
Jak mogę to sprawdzić?
Parametr -spin nie jest ustawiony. Rozumiem, że "latch timeouts" są związane z tym parametrem?
Liczba obiektów w bazie (obliczona przy pomocy "select count(*) from _storageobject") wynosi 1354.
Parametr -omsize nie jest ustawiony.
Dziękuję za zainteresowanie i pozdrawiam,
Adam Rzońca
Nie wspomniałem o ważnej rzeczy. Nasza baza (OE10.0B) działa na licencji Workgroup.
APW, BIW, -spin: dotyczą chyba tylko baz w wersji Enterprise?
Tak jak napisał Piotr, jeżeli to jest licencja Enterprise to należy wystartować procesy wspomagające: APW i BIW.
Parametr -spin jest domyślnie ustawiany na 6000 x CPU. Jego aktualną wartość można sprawdzić w logu lub promonie. Znowu pytanie czy jest to wersja Enterprise?
Checkpointy są w normie chociaż klaster jest bardzo mały (default). Było trochę za dużo flushes przez 3 godziny od wystartowania. Czy w tym czasie był wykonywany backup online? Blok BI można by zwiększyć do 16K i klaster do 1MB (przy okazji truncate bi)...ale tu nie widać wąskiego gardła w przesłanej próbce.
DBReads jest stosunkowo za duży ale buffer hit przez ten czas był 47 (średnio co 47 odczytywanych rekordów baza musiała sięgnąć do dysku). Nie jest tragicznie ale i nie idealnie... Interesujące będzie sprawdzenie jak wygląda sytuacja z I/O gdy problemy występują (IO waits - %wa)
Rozmiar bazy można zakwalifikować jako "mały", zakładam rozmiar bloku bazy 8K - buffer pool powinien być wystarczający. Parametr -omsize można ustawić na 1400.
Wszystko to na podstawie dzisiejszych statystyk pomiędzy 8:23 i 12:14... zakładając że nieakceptowalne zachowanie bazy występowało cały czas.
>>>Nasza baza (OE10.0B) działa na licencji Workgroup.
OK. No to nasze opcje są ograniczone. Możemy zapomnieć o APW, BIW i spin. W tym wypadku korzystamy z "wolnych" semaforów...Jeżeli dobrze pamiętam to -spin=1 został wprowadzony w 10.1B01...
Warto byłoby pomyśleć o licencji Enterprise i nowszej wersji jeżeli jest to ważny i istotny system produkcyjny...
Z logu bazy wynika, że spin jest ustawiony na 0.
Rozmiar bloku bazy wynosi 4K. Czy zmiana na 8K nie będzie kolidował z rozmiarem bloku w linuxie, który też wynosi 4K?
Parametr -omsize ustawię na 1400 przy najbliższym restarcie bazy.
Jeśli chodzi o pamięć to serwer ma 16GB pamięci. W chwili przycinki, procesy Progressa zużywają max 30% zasobów serwera.
Czy przy pomocy promona da się wyciągnąć dane, jakie użytkownicy w danym momencie wykonują r-kody, lub coś w tym stylu?