IBAnalyst: co możesz zobaczyć w widoku podsumowania

Dmitry Kuzmenko, ostatnia aktualizacja 31-03-2014

Streszczenie

Ten dokument poświęcony jest wyjaśnieniu informacji na stronie „Widok podsumowania” w IBAnalyst oraz temu, jak interpretować te informacje dla statystyk własnej bazy danych. Dodaliśmy również kilka przykładów statystyk do pakietu instalacyjnego, aby ułatwić Ci poznanie wszystkich szczegółów statystyk InterBase. Znajdują się one w katalogu Examples instalacji IBAnalyst.

Jeśli nie wiesz, czym jest najstarsza transakcja, najstarszy snapshot, aktywna i następna, przeczytaj najpierw artykuł Craiga Stunza „Understanding Transactions Lifetime”:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Numery transakcji

Jeśli przeczytałeś artykuł Understanding Transaction Lifetimes, być może nadal masz pytania dotyczące numerów OIT/OST/OAT. Oto krótki opis:


Numer	Zatrzymuje się, …	Przesuwa się do przodu, …
Najstarsza transakcja	gdy transakcja z tym numerem została wycofana i zawierała dużo zmian danych, lub gdy połączenie klienta zostało utracone	gdy automatyczny lub ręczny sweep zakończy się sukcesem.
Najstarszy snapshot	gdy snapshot (lub read committed write przed IB 7.1) jest aktywny przez długi czas (zapamiętał najstarszy aktywny snapshot jako swój lokalny OST)	gdy rozpoczyna się nowa transakcja, jeśli transakcja trzymająca OST została zakończona
Najstarsza aktywna	gdy transakcja z tym numerem jest aktywna przez długi czas	gdy rozpoczyna się nowa transakcja, jeśli transakcja trzymająca OAT została zakończona
Następna	nigdy	gdy rozpoczyna się nowa transakcja

uwaga: Najstarsza transakcja tutaj jest tym samym co Najstarsza Interesująca Transakcja (OIT), wspomniana w wielu innych artykułach.

Dokładne statystyki przy standardowych ustawieniach

Uruchommy IBAnalyst i otwórzmy (menu Statistics/Load statistics from file) plik !allok.txt.

IBAnalyst raportuje nie tylko datę utworzenia bazy danych, ale także rozpoznaje bieżącą datę i czas na serwerze, jeśli statystyki zostały pobrane przez Services API, lub datę pliku, jeśli jest to wczytany plik statystyk.

Dlatego sugerujemy, aby nie modyfikować plików statystyk, ponieważ w tym przypadku IBAnalyst będzie nieprawidłowo obliczać średnią liczbę transakcji dziennie. Wiersz transakcji dziennie pokazuje tutaj około ~12500 transakcji dziennie, a baza danych „żyje” od jej utworzenia lub przywrócenia przez 8 dni.

Najstarsza, najstarszy snapshot, najstarsza aktywna i następna transakcje są tutaj w idealnym stanie - życzymy Ci, aby Twoje statystyki zawsze tak wyglądały.

Wiele aktywnych transakcji

Następnie otwórz plik !lotofactive.txt (w każdej chwili możesz spojrzeć na obrazek !allok, aby porównać poniższe przykłady).

Tutaj wiersz aktywnych transakcji jest oznaczony na czerwono, ponieważ istnieje duża różnica między najstarszą aktywną a następną transakcją. Oznacza to, że pewna transakcja w momencie pobierania statystyk była nadal aktywna, a po jej rozpoczęciu wystartowało już 55 000 transakcji (mogą być w dowolnym stanie - aktywne, zatwierdzone, wycofane). Ponieważ średnia liczba transakcji dziennie wynosi ~12500, IBAnalyst pokazuje ostrzeżenie, że pewna transakcja nadal żyje od 4,4 dni. Może się to zdarzyć, gdy:

jakaś aplikacja nadal działa i ma co najmniej jedną otwartą transakcję - niektórzy użytkownicy mogą trzymać aplikację uruchomioną przez długi czas
aplikacja działa przez długi czas i gubi uchwyty transakcji - tj. Twój kod (lub używane komponenty/biblioteki) dynamicznie rozpoczyna transakcje i w pewnych okolicznościach „zapomina” je zakończyć przez rollback lub commit.
Twoja aplikacja nie używa jawnych transakcji (BDE), pozostawiając obsługę transakcji używanym komponentom. W rezultacie czas życia transakcji nie jest kontrolowany przez aplikację i możesz być pewien, że większość transakcji Next-OAT jest naprawdę aktywna.
Twoja aplikacja używa sterownika lub komponentów, które pozwalają na „transakcję domyślną”. Jeśli Twój kod nie kontroluje tej transakcji, może działać bardzo długo.

Niestety statystyki nie pokazują rzeczywistej liczby aktualnie aktywnych transakcji. Można to zobaczyć tylko w InterBase 7.x za pomocą IBConsole, IB Performance Monitor lub przez bezpośrednie zapytanie do tymczasowej tabeli systemowej tmp$transactions. W Firebird 1.5 można wywołać isc_database_info z parametrem isc_info_active_transactions.

Sweeping

Teraz otwórzmy !needsweep.txt.

Sweep to proces porządkowania wewnątrz InterBase. Sweep przechodzi przez wszystkie rekordy w bazie danych i próbuje wyczyścić wszystkie wersje śmieci, a następnie próbuje przesunąć numer najstarszej transakcji w górę. W nowo utworzonej bazie danych interwał sweep domyślnie wynosi 20000. Gdy różnica między transakcjami (patrz tabela poniżej) staje się większa niż interwał sweep, sweep uruchomi się automatycznie. W ten sposób możesz zauważyć okresowe pogorszenie wydajności bazy danych. Na przykład Twoje aplikacje działają dobrze w poniedziałek i wtorek, ale w środę użytkownicy zgłaszają problemy z wydajnością przez kilka godzin, a potem wydajność znów wraca do normy.

Jeśli widzisz podobne zachowanie - to automatyczny sweep.


Wersja serwera	Kiedy uruchamiany jest sweep
InterBase 7.x	(Najstarsza aktywna - Najstarsza) > interwał sweep
InterBase 4.x, 5.x, 6.x, Firebird przed 1.5.2, Yaffil	(Najstarszy snapshot - Najstarsza) > interwał sweep

Tabela 1. Warunki uruchamiania automatycznego sweep

uwaga: IBAnalyst automatycznie pokazuje poprawne informacje o luce sweep dla wszystkich wersji. IBAnalyst może wykryć różnicę między implementacjami serwera tylko po identyfikatorze ODS, na przykład InterBase 7.x ma ODS 11.x, inne nowoczesne serwery mają ODS 10.x. Jeśli pracujesz tylko z bazami InterBase 7.x (ODS 11), możesz przełączyć odpowiednią opcję w oknie dialogowym Options.

Gdy Twoja baza danych ma interwał sweep <> 0, IBAnalyst zasadniczo oznacza ten wiersz na żółto (ostrzegając, że automatyczny sweep może rozpocząć się w nieprzewidywalnym momencie). Ogólnie 60% wszystkich aplikacji ma problemy z automatycznym sweepingiem. Najłatwiejszym sposobem uniknięcia tego problemu jest ustawienie interwału sweep na 0, co prowadzi do wyłączenia automatycznego sweep. Ale jeśli jakaś aplikacja wprowadzi wiele zmian, a następnie je wycofa, najstarsza transakcja zamarznie i nie przesunie się w górę, dopóki nie zostanie uruchomiony sweep. Ponieważ efektywny stan transakcji jest obliczany od najstarszej do następnej transakcji, ta odległość będzie rosnąć, a wydajność spadnie. Aby temu zapobiec, musisz uruchomić sweep ręcznie (gfix -sweep). Na tym obrazku widać zachowanie, gdy interwał sweep wynosi 0 i wystąpiła duża wycofana transakcja:

Tutaj wartość luki sweep pokazuje, że jakaś duża (wprowadzająca wiele zmian) transakcja została wycofana około 4,5 dnia temu. Zalecamy ręczne uruchamianie sweep codziennie.

Oczywiście dla tych wspomnianych 60% aplikacji może być lepiej ustawić interwał sweep większy lub mniejszy niż 20000, ale zależy to od wielu czynników (dzienna liczba transakcji jest jednym z tych czynników, na przykład) i może być zrozumiane tylko metodą eksperymentalną. Więc jeśli ustawisz interwał sweep na 0, możesz być pewien, że sweep nie uruchomi się automatycznie w nieprzewidywalnym momencie.

Ten sam obrazek można zobaczyć dla pliku !rollback.txt.

uwaga: Jeśli sweep działa automatycznie, dla dużej bazy danych lub bazy z dużą ilością śmieciowych wersji rekordów, snapshot, aktywna i następna transakcje mogą przesuwać się do przodu podczas pracy sweep, a sweep może rozpocząć się ponownie przy najbliższym rozpoczęciu transakcji.

Kiedy sweep nie może wykonać swojej pracy

Istnieje wiele przypadków, gdy sweep nie może przesunąć najstarszej transakcji wyżej. Oczywiście sweep najpierw próbuje wykonać swoją pracę, tj. sprawdzić wszystkie rekordy w bazie i zebrać niepotrzebne wersje rekordów. Ale będzie uruchamiany wielokrotnie bez sukcesu, jeśli

wystąpił problem podczas działania sweep: serwer został zatrzymany podczas sweep, lub wystąpił błąd podczas czyszczenia śmieciowych wersji rekordów. Dodatkowo ten obrazek można zobaczyć, gdy:

statystyki zostały pobrane podczas działania sweep
sweep działa i próbuje zebrać śmieci dla tabeli, która jest stale aktualizowana. Może to trwać, dopóki aktualizacje się nie zakończą.
sweep utknął na blokadach stron, ponieważ wielu użytkowników pracuje z danymi.

Ogólnie rzecz biorąc, sweep nie ma szans na zakończenie podczas dużego obciążenia bazy danych. Zwykle, gdy wydajność spada do niemożności kontynuowania normalnej pracy, DBA restartuje serwer, a sweep uruchamia się przy pierwszym połączeniu użytkownika. Ponieważ minie trochę czasu, zanim inni użytkownicy się połączą, sweep będzie miał czas na zakończenie swojej pracy.

Ponieważ InterBase 7.1/7.5 oblicza lukę sweep inaczej niż poprzednie wersje, inną sytuacją, gdy sweep nie może wykonać swojej pracy, jest długo działająca transakcja snapshot w jakiejś aplikacji:

Tutaj są dwa ostrzeżenia - jedno (żółte) o długo działającym snapshotcie i drugie (czerwone) o interwale sweep i luce sweep.

Długo działający snapshot

Poprzedni obrazek wskazuje długo działający snapshot w InterBase 7.1/7.5. Jeśli interwał sweep został ustawiony na 0, nie byłoby czerwonych ostrzeżeń, tylko żółte. Podobny obrazek wskaże długo działającą transakcję snapshot w innych wersjach InterBase, Firebird i Yaffil:

Jak widać tutaj, luka sweep jest obliczana na podstawie różnicy między najstarszym snapshotem a najstarszą transakcją (dla ODS 10, wersje przed IB7.x). Więc nie ma ostrzeżenia o sweep (poza domyślnym interwałem sweep).

Ale nie tylko transakcje snapshot wpływają w ten sposób na stan transakcji. Wszystkie wersje InterBase, Firebird i Yaffil z wyjątkiem InterBase 7.1/7.5 mają następujące zachowanie, które nazwaliśmy „artefaktem read committed”.

Snapshoty ponownie i kiedy ReadCommitted zamraża najstarszy snapshot

Otwórz !snapshot2.txt. :

Zauważ, że najstarsza transakcja jest większa niż najstarszy snapshot. A luka sweep ma wartość ujemną. Może się to zdarzyć w dwóch przypadkach. Pierwszy przypadek to sytuacja, gdy niektóre transakcje snapshot zaczynają się i zatwierdzają jedna po drugiej. Tj. ten obrazek może wystąpić zarówno dla snapshotów, jak i poprzedni obrazek. Następny przypadek występuje tylko w serwerach innych niż IB 7.1/7.5 z transakcjami ReadCommitted (lub w kombinacji transakcji ReadCommitted i Snapshot). Mogą one zablokować numer najstarszego snapshota w ten sam sposób, jak robią to transakcje Snapshot. Bieżący stan transakcji można zasymulować następującą sekwencją:

rozpocznij transakcję 1, snapshot lub read_committed
rozpocznij/zatwierdź kilka transakcji read_committed
rozpocznij transakcję 2, snapshot lub read_committed
rozpocznij/zatwierdź kilka transakcji read_committed
zatwierdź transakcję 1

(oczywiście mówimy tutaj o transakcjach read_committed write, nie tylko do odczytu).

W tym momencie aktualnie aktywna transakcja 2 (snapshot lub read committed), rozpoczęta po snapshotcie 1 (punkt 3), będzie trzymać numer snapshotów jako najstarszy snapshot (jeśli pracujesz z IB 7.1/7.5, może się to zdarzyć tylko dla równoczesnych transakcji snapshot. read_committed lub read_committed+snapshot nie wywoła tego efektu). Ponieważ nie było dużych wycofań, najstarsza transakcja przesuwa się do przodu i staje się większa niż najstarszy snapshot.

Teraz, jeśli masz długo działającą transakcję read committed, zobaczysz obrazek taki jak ten. Niestety nie możesz nic zrobić ze swoimi aplikacjami (poza dodaniem parametru „read” dla transakcji tylko do odczytu). I oczywiście sweep nie uruchomi się automatycznie (jeśli jest ustawiony <> 0) w tym przypadku.

uwaga: to zachowanie zostanie naprawione w Firebird 2.0

Widoki bezwzględne i względne

Domyślnie IBAnalyst wypełnia wiersze transakcji według procentu ich wartości bezwzględnej. Tj. 100% to od 0 do następnej transakcji. Czasami, gdy baza danych działa przez długi czas, możesz zobaczyć informacje o transakcjach jako

Podczas gdy jest wiele transakcji, różnica między snapshotem, aktywną i najstarszą wygląda na bardzo małą (blisko 98%). Aby wyjaśnić sytuację, otwórz okno dialogowe Options, zakładkę Transactions i zaznacz opcję „Relative (from oldest) bars %” (nie możesz zaznaczyć tego pola, jeśli używasz widoku w starym stylu, bez pasków wykresu). Po naciśnięciu przycisku OK widok transakcji zmieni się na

Teraz widzisz różnicę transakcji w widoku względnym (100% to od najstarszej (lub snapshot) transakcji do następnej, nie od 0). Łatwiej jest zrozumieć aktualną sytuację i zobaczyć ostrzeżenia (jeśli takie są).

Ten widok będzie utrzymywany, dopóki go nie odznaczysz w oknie dialogowym Opcje. Możesz zrozumieć, jaki widok widzisz, patrząc na wiersz Najstarsza transakcja lub Najstarszy snapshot - w widoku względnym jeden z tych wierszy nigdy nie jest wypełniony kolorem zielonym. W widoku absolutnym jest zawsze wypełniony (oczywiście częściowo).

Nadal masz pytania? Zapytaj nas na [email protected]