OpeneEdge10.0B - wolna praca bazy danych - General Forum - PUG Poland - Progress Community

OpeneEdge10.0B - wolna praca bazy danych

 General Forum

OpeneEdge10.0B - wolna praca bazy danych

  • 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

  • Witam,
     
    Jezeli dobrze rozumiem, aplikacja w wersji znakowej podlacza sie cez shared memory, zgadza sie ? Jezeli tak, to mozna wykluczyc problemy z siecia.
    W parametrach brakuje mi przede wszystkim –spin.
    Jak wyglada obciazenie dyskow ?
    Ta wolna praca dotyczy calej aplikacji, czy tylko wybranych browserow ?
    Polecalbym zainteresowac sie VST _TableStat i _UserTableStat (mam nadzieje ze byly juz w wersji 10.0, nie pamietam) – trzeba tylko nastawic odpowiednio parametr –tablelimit.
    Trzeba sprawdzic w ktorych tabelach sie najwiecej dzieje w czasie wystepowania problemow i czy jest to uzasadnione.
    Parametr –bibufs mowi o ilosci BI bufferow i nie ma zadnego wplywu na odczyt danych.
     
    Piotr
     
     
  • @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

  • Z tego co widze w Promonie trzeba by pomyslec o:

    -          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.

     
    Piotr
     
     
     
     
  • @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.

  • @Piotr Tucholski
     
    Jakby wyglądały tego typu konsultacje z Państwa firmą? Zazwyczaj problemy z bazami udawało nam się rozwiązywać własnymi siłami, ale tym razem pomysły mi się skończyły i jestem zmuszony szukać pomocy u mądrzejszych :)

    Pozdrawiam,
    Adam Rzońca
     

  • >>>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...

  • Marek, jezeli dobrze pamietam, to –spin ma default > 0 dopiero od ktorejs pozniejszej wersji OE (11.x ?). Ale oczywiscie moge sie mylic J
    Ale skoro maja workgroup to i tak bez znaczenia.
    Block size maja 4kb, ale i tak buffer pool nie wydaje mi sie maly. Z drugiej strony, zmiana na 8kb by tez mogla pomoc.
     
    A tak swoja droga – ile pamieci ma serwer ? Nie swapuje przez przypadek ?
     
    P.
     
     
  • 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?