RSS Feed

Posts Tagged ‘baza’

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


  2. Backupninja 0.9.8, backup mysqla w vserverze i bug

    Kwiecień 27, 2011 by 0verlord

    Objawia się tak: mamy sobie głównego hosta, i kilka guestów (vserverów). Na jednym z nich chodzi mysql. Dodajemy akcję do backupninja przy pomocy helpera, żeby nam robił dumpa wszystkich baz. Konfiguracja z ninjahelperem jest banalna, więc ją pominę. Error w debugu wygląda np. tak dla losowej bazy:
    Debug: su root -c "/usr/sbin/vserver mysql exec /usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --quote-names sugarcrm -r '/home/vservers/mysql/var/backups/mysql/sqldump/sugarcrm.sql'"
    Warning: mysqldump: Can't create/write to file '/home/vservers/mysql/var/backups/mysql/sqldump/sugarcrm.sql' (Errcode: 2)
    Warning: Failed to dump mysql databases sugarcrm

    Teraz ocb? Skrypt wykonujący backup, konkretnie ten (na Debianie):
    /usr/share/backupninja/mysql
    wydaje się nie zauważać, że wykonuje polecenie w środku vservera, więc nie ma tam katalogu podanego jako parametr do polecenia. To co widać powyżej, szuka katalogu
    /home/vservers/mysql/var/backups/mysql/sqldump
    ale w środku vservera, czyli jak byśmy zrobili na gueście katalog taki:
    /home/vservers/mysql/var/backups/mysql/sqldump
    widziany z poziomu maina jako
    /home/vservers/home/vservers/mysql/var/backups/mysql/sqldump
    to by się backup zrobił, ale szukać by go trzeba gdzie indziej.

    Jak to naprawić? Generalnie bez zagłębiania się w logikę kodu, i zdając sobie sprawę, że mogę popsuć coś innego, hackujemy sobie na szybko
    /usr/share/backupninja/mysql,
    linijka 287 i okolice.

    # Test to make sure mysqld is running, if it is not sqldump will not work
    $VSERVER $vsname exec su $user -c "$MYSQLADMIN $defaultsfile ping 2>&1 >/dev/null"
    if [ $? -ne 0 ]; then
    fatal "mysqld doesn't appear to be running!"
    fi
    if [ "$compress" == "yes" ]; then
    execstr="$VSERVER $vsname exec $DUMP | $GZIP $GZIP_OPTS > '$vroot$dumpdir/${db}.sql.gz'"
    else
    execstr="$VSERVER $vsname exec $DUMP -r '$vroot$dumpdir/${db}.sql'"
    fi
    else

    usuwamy ‚$vroot’ z linijek zaczynających się na execstr, i zostaje samo ‚$dumpdir’. czyli tutaj ‚/var/backups/mysql/sqldump’ czyli tak, jak ma być.
    I to wszystko. W ten sposób usuwamy /home/vservers z argumentu do vserver exec i już polecenie widzi odpowiedni katalog.

    Ciekawe, że nikt tego nie znalazł do tej pory, bo buga poprawiam drugi raz, pierwszy raz trafiłem go w Lenny’m i się pojawił po upgrade do Squeeze’a.