Problem z niewydajną baza danych. Flopsar Application Performance Monitoring

1. Problemy bazy danych
cd..
30 sekundowa analiza przyczyn powstawania problemów

2. Symptom driven diagnostic
• System „wczesnego
ostrzegania” (AI) Flopsar
informuje o narastających
problemach z czasem
odpowiedzi aplikacji.
• Problem powstaje nagle,
po weekendowym
wdrożeniu nowej wersji
aplikacji.
Problem pojawia się nagle, po
wdrożeniu aplikacji. Problemy
narastają (są ciągłe)
Brak symptomów
Problemy dotyczą czasu odpowiedzi
aplikacji, Jest on o wiele wyższy niż
typowo, dotyczy wielu funkcji aplikacji.

3. Root cause
• Problem zostaje skontenerowany do dwóch funkcji:
• doSelect/executeQuery
• read/write
• Kontenerowanie odbywa się na dedykowanym panelu. Nie wymaga
jest jego konfiguracja.
• Inne parametry aplikacji są w normie
• Obie funkcje są charakterystyczne dla problemów z niewydajną
bazą danych. Wykres DuraMon/CPU pokazuje, że prawie 100%
czasu aplikacja spędza poza serwerem. Nie należy więc szukać
przyczyny (i optymalizować) w serwerze aplikacji (komponentach
aplikacji)
• Dla upewnienia się, że wstępna diagnoza jest poprawna operator
weryfikuje mapę czasów odpowiedzi aplikacji, aby poznać szczegóły

4. Mapa wydajności
Szereg „kominów” pokazujących, że
czas odpowiedzi jest wysoki (dochodzi
do 22 sekund). 95% odpowiedzi
generowane jest jednak w czasie do 2
sekund

5. Kto jest winny?
„Kominy” powstają poza serwerem.
Ponad 99% czasu jest tracone na
oczekiwanie

6. Kto jest winny. Precyzyjna diagnoza
Mamy problem z pisaniem/czytaniem
danych, oraz wykonywaniem zapytań
bazodanowych (doSelect)
Możliwość obejrzenia pojedynczych
wywołań zawierających „podejrzane”
metody

7. Stack wywołania

8. Stack wywołania cd…

9. Wnioski
• Każde zapytanie bazodanowe (select 1, select count(),
select … from..) trwa powyżej 1 sekundy.
• Transport danych oraz odbiór wyników (write/read)
trwa powyżej 50 ms dla kilkunastu bajtów
• Wskazuje to problem nadmiernego obciążenia bazy
danych. Nie jest ona w stanie poprawnie realizować
swoich działań.

10. Rozwiazanie
• Przygotowując wdrożenie,
administratorzy popełnili błąd przy
konfiguracji skryptu docker-owego
dla bazy.
• Został wdrożony skrypt ze
środowiska developerskiego
• Zawierał on istotne ograniczenia
bazy - w wykorzystaniu
procesora i pamięci.
• Po zniesieniu limitów i restarcie bazy
danych, wszytko wróciło do normy

11. Wnioski końcowe
• Cała analiza trwała poniżej jednej minuty, uruchomiono
poprawne środowisko w kolejnych 10. Cała awaria trwała
więc około 15 minut.
• Czy dało by się określić przyczynę tej awarii bez Flopsar?
• Oczywiście że tak.
• Pytanie otwarte - jakimi zasobami i w jakim czasie.