RSS Feed

Diagnozowanie podstawowych problemów z wydajnością bazy Firebird

Marzec 26, 2013 by 0verlord

firebird logo

O bazie Firebird już pisałem, konkretnie w tym poście, gdzie to jest wyjaśnione, po co należy robić gbak i odgbak (tj restore). A dzisiaj będzie o przypadku z życia i o tym, jak taki przypadek wyeliminować.

Baza po jakimś czasie zaczęła zamulać. Proste zapytanie trwały nawet i kilkadziesiąt sekund. Przy okazji podstroiłem Apacha pod kątem wydajności, bo najpierw miałem niecne podejrzenie, że to właśnie tutaj jest problem. Po poprawkach w konfigu, firebird zaczął chodzić jakieś 30% szybciej, ale zamuła dalej była odczuwalna.

Po konsultacji z mistrzami wymiataczami, został zarządzony gbak/restore bazy. Dla porządku, baza to Firebird SuperServer, w wersji 2.5.1, a wirtualizacja jest na LXC.

Po restore, poprzednia prędkość bazy wróciła do normy, co kazało mi odświeżyć sobie info o poście, który wspominałem na początku wpisu. Jeżeli baza wróciła do siebie po restore, to znaczy, że nie zadziałało czyszczenie.

W cronie regułka była – ale na wszelki wypadek ją odpaliłem z konsoli. Zapytała o usera i hasło do bazy… #fail.
A to znaczyło, że sweep się nie wykonał, i baza nabrała rozmaitego śmiecia. Te śmieci wyczyścił gbak/restore. Co ciekawe, na innym serwerze mam dokładnie taką samą regułkę – i tam to działa (tak, sprawdziłem dzisiaj). Różnica jest tylko taka, że tam jest Classic, a na wirtualce SuperServer. Kocham takie niespójności…

Przy okazji, taki problem można zdiagnozować szybciej, przy pomocy polecenia ‚gstat’.
Na customowej instalacji z tarballa w Debianie, gstat jest tu: /opt/firebird/bin/gstat.
Uruchamiamy go z parametrem -h i ścieżką do pliku bazy, np. tak:

/opt/firebird/bin/gstat -h /var/db/bla.fdb

Powinien pokazać coś podobnego do tego:


Database "/var/db/bla.fdb"
Database header page information:
Flags 0
Checksum 12345
Generation 51183
Page size 4096
ODS version 11.2
Oldest transaction 51141
Oldest active 51142
Oldest snapshot 51142
Next transaction 51143
Bumped transaction 1
Sequence number 0
Next attachment ID 104
Implementation ID 19
Shadow count 0
Page buffers 21480
Next header page 0
Database dialect 3
Creation date Mar 26, 2013 21:50:48
Attributes

Variable header data:
Sweep interval: 0
*END*

Co nas interesuje z tej listy? Sweep interval – tutaj ustawiony na 0, czyli jak się można domyślić – jest wyłączony. Interesuje nas jeszcze ODS version (czyli on-disk structure), bo to pokazuje, która wersja bazy danych odczyta nasz plik z bazą. Na szczęście w przypadku pomylenia wersji, dostaniemy odpowiedni komunikat, że ODS jest niezgodny.
Interesuje nas też konkretnie ta sekcja:
Oldest transaction 51141
Oldest active 51142
Oldest snapshot 51142
Next transaction 51143

Tutaj mamy numerki, a żeby baza dobrze chodziła, różnica pomiędzy nimi nie może być większa niż 100, lub w innych manualach 200.
Można to bardzo prosto sprawdzić – wystarczy przez jakiś czas nie włączać sweepa, potem go włączyć i zobaczyć.
Z punktu wydajnościowego interesuje nas jeszcze parametr „Page buffers” – dla superservera z 4 GB ramu powinien być właśnie na takim poziomie jak u mnie. Ale np. w wersji Firebird Classic, wartość 5000 jest sensowna.

Podsumowując,


Brak komentarzy »

No comments yet.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

− 3 = trzy