IBAnalyst: Jak prawidłowo uzyskać statystyki z bazy danych InterBase/Firebird

Dmitry Kuzmenko, ostatnia aktualizacja 31-03-2014

Streszczenie

Ten dokument poświęcony jest wskazówkom i trikom dotyczącym zbierania i analizowania statystyk z baz danych InterBase/Firebird z użyciem IBAnalyst lub bez niego.

Właściwy czas, właściwe miejsce

To brzmi dziwnie, ale samo pobranie statystyk za pomocą gstat lub Services API nie wystarczy. Statystyki muszą być pobierane we właściwym momencie, aby pokazać, jak aplikacje wpływają na dane i transakcje w bazie danych. Najgorszy czas na pobieranie statystyk to:

Bezpośrednio po przywróceniu bazy
Po wykonaniu kopii zapasowej (gbak -b db.gdb) bez przełącznika -g
Po ręcznym sweepie (gfix -sweep)

Prawdą jest również, że podczas pracy mogą wystąpić momenty, w których baza danych jest w prawidłowym stanie, na przykład gdy aplikacje generują mniejsze obciążenie bazy niż zwykle (użytkownicy przy starcie, przerwa obiadowa lub wynika to z konkretnych godzin procesów biznesowych).

Jak wyłapać moment, w którym z bazą danych dzieje się coś złego?

Tak, Twoje aplikacje mogą być zaprojektowane tak doskonale, że zawsze będą poprawnie pracować z transakcjami i danymi, nie powodując luk w sweepie, dużej liczby aktywnych transakcji, długo działających snapshotów i tak dalej. Zwykle tak się nie dzieje. Przynajmniej dlatego, że niektórzy programiści testują swoje aplikacje przy 2-3 jednocześnie pracujących użytkownikach, nie więcej. Dlatego gdy wdrażają napisane aplikacje dla 15 i więcej jednoczesnych użytkowników, baza danych może zachowywać się nieprzewidywalnie. Oczywiście tryb wieloużytkownikowy może działać poprawnie, ponieważ większość konfliktów wieloużytkownikowych można przetestować przy 2-3 jednocześnie uruchomionych aplikacjach. Ale potem, gdy będzie działać więcej jednoczesnych aplikacji, mogą pojawić się problemy z garbage collection (przynajmniej). I można to wyłapać, jeśli pobierzesz statystyki we właściwych momentach.

Jeśli nie doświadczasz okresowych problemów z wydajnością

Może się tak zdarzyć, gdy Twoje aplikacje są poprawnie zaprojektowane, obciążenie bazy danych jest niskie, lub Twój sprzęt jest nowoczesny i bardzo wydajny (wystarczający do obsługi obecnej liczby użytkowników i danych).

Najcenniejsze informacje to obciążenie transakcjami i akumulacja wersji. Można to zobaczyć tylko wtedy, gdy skonfigurujesz regularne zapisywanie statystyk.

InterBase nie ma wewnętrznego harmonogramu zadań, więc możesz swobodnie używać dowolnego zewnętrznego, jak standardowy Harmonogram zadań (Windows) lub cron (Unix).

Najlepsza konfiguracja to pobieranie godzinnych statystyk transakcji. Można to zrobić, uruchamiając:

gstat -h db.gdb >db_stat_.txt

gdzie:

db.gdb to nazwa Twojej bazy danych,

db_stat_.txt to plik tekstowy, w którym zostaną zapisane statystyki,

- bieżąca data i godzina pobrania statystyk.

Jeśli doświadczasz okresowych problemów z wydajnością

Te problemy są zwykle spowodowane automatycznym uruchomieniem sweepa. Najpierw musisz określić okres czasu między takimi spadkami wydajności. Następnie podziel ten interwał minimalnie na 4 (8, 16 i tak dalej). Obecnie systemy informatyczne mają wielu jednoczesnych użytkowników, a większość problemów z wydajnością przy nieodpowiednio skonfigurowanym serwerze i bazie danych występuje 2 lub 3 razy dziennie. Na przykład, jeśli spadki wydajności występują co 3 godziny, musisz pobierać:

gstat -h db.gdb

statystyki co 30-45 minut, oraz

gstat -a -r db.gdb -user SYSDBA -pass masterkey

co 1-1,5 godziny.

Najlepiej jest pobrać statystyki gstat -a -r tuż przed spodziewanym spadkiem wydajności. Pokaże to, gdzie znajduje się prawdziwy garbage i ile nieaktualnych wersji rekordów się zgromadziło.

Co zrobić z tymi statystykami

Jeśli Twoja aplikacja jawnie używa transakcji i robi to dobrze, tj. wiesz, czym jest read_committed i kiedy go używać, Twoje transakcje snapshot nie trwają dłużej niż to konieczne, a transakcje są aktywne przez minimalny czas, możesz dostroić interwał sweepa lub go wyłączyć, a następnie martwić się tylko o to, ile aktualizacji wykonują aplikacje i które tabele wymagają mniejszej liczby aktualizacji lub opieki.

Co to oznacza, możesz zapytać? Podamy przykład pewnego systemu, w którym problemy z wydajnością występowały każdego ranka przez 20-30 minut. To było wystarczające dla “porannych” aplikacji i nie mogło trwać dłużej.

Administrator bazy danych został zapytany o właściwe pytania i oto obraz sytuacji:

Codzienna praca była podzielona na sekcje - analitycy pracują rano, potem dane są wprowadzane i edytowane przez zwykłych operatorów, a na koniec dnia uruchamiane są specjalne procedury zbierające dane, które będą używane przez analityków następnego dnia (przynajmniej).

Ostatnia praca na bazie danych na koniec dnia to duża liczba aktualizacji, i to aktualizacji tych tabel, których analitycy używali rano. W związku z tym było dużo wersji garbage, które zaczynały być zbierane przez aplikację działającą rano.

I rozwiązanie tego problemu okazało się proste - uruchomienie gfix -sweep na koniec dnia.

Sweep czyta wszystkie tabele w bazie danych i próbuje zebrać wszystkie wersje garbage dla zatwierdzonych i wycofanych transakcji. Po sweepie baza danych stała się czysta prawie jak po przywróceniu.

I “poranny problem” zniknął.

Dlatego musisz rozpatrywać statystyki z wieloma innymi czynnikami:

ilu jednoczesnych użytkowników (średnio) pracuje w ciągu dnia
jak długi jest dzień pracy (8, 12, 16, 24 godziny)
jakie aplikacje działają o różnych porach dnia i jak wpływają na dane używane przez inne aplikacje działające w tym samym czasie lub później. To znaczy, musisz rozumieć procesy biznesowe zachodzące w ciągu całego dnia i całego tygodnia.

Kiedy DBA nie może nic zrobić

Niestety, takie sytuacje się zdarzają. I znowu przykład:

Pewien system zainstalowany dla ~15 użytkowników. Okresowo wydajność jest tak zła, że DBA musi zrestartować serwer. Po restarcie serwera wszystko działa dobrze przez jakiś czas, potem wydajność znowu spada. Statystyki pokazały, że średnia dzienna liczba transakcji wynosi około 75 000, a od początku dnia do momentu spadku wydajności działają aktywne transakcje.

Niestety, aplikacje zostały napisane z użyciem BDE i w ogóle nie używały transakcji; to znaczy cała obsługa transakcji była automatyczna i wykonywana przez samo BDE. To spowodowało, że niektóre transakcje pozostawały aktywne przez długi czas, a garbage (wersje rekordów) gromadził się, dopóki DBA nie zrestartował serwera. Po restarcie automatyczny sweep uruchomił się i garbage został zebrany (wyeliminowany).

Wszystko to było spowodowane przez aplikacje, ponieważ były testowane tylko przy 2-3 jednoczesnych użytkownikach, a gdy było ich ~15, aplikacje zaczęły generować bardzo duże obciążenie.

Trzeba powiedzieć, że w tej konfiguracji 70% użytkowników tylko czytało dane, a pozostałe 30% wprowadzało i aktualizowało jakieś (!) dane.

W tej sytuacji jedyną rzeczą, która może poprawić wydajność, jest całkowite przeprojektowanie aplikacji.

Nadal masz pytania? Zapytaj nas na [email protected]