Inspiracja , wiedza , realizacja
Jsystems

W przebudowie

Login



Java

Oracle

Linux

Android

PostgreSQL

Microsoft SQL Server

PgBench-tools – automatyczne narzędzie testujące

Data dodania: Jun 16, 2016
Data aktualizacji: Jun 16, 2016

Wdrożenie


Wykorzystując samego PgBench można robić ręcznie wiele testów, ale gdybyśmy zechcieli zrobić kompleksowe testy np. sprawdzające kiedy ilość transakcji na sekundę spada poniżej określonego limitu, byłoby to bardzo pracochłonne. Trzeba byłoby zrobić zestawienie wyników dla różnej wielkości bazy, różnej ilości wątków i klientów i wielokrotnie całość powtarzać. Na szczęście jest narzędzie które zrobi to za nas, a nawet przedstawi wyniki w formie graficznych wykresów. Przykładowy zrzut z wyników:



Jeśli zechcemy skorzystać z tego narzędzia, musimy oczywiście posiadać pakiet pgbench i musi on być zainstalowany w bazie. Następnie tworzymy bazę danych w której mają zostać utworzone tabele na potrzeby testów (najlepiej by baza ta była pusta), oraz bazę która będzie przechowywała wyniki testów:


create database pgbench;

create database results;

Teraz musimy zainstalować narzędzie GIT które posłuży nam do pobrania pgbench-tools:


yum install git


Przechodzimy do katalogu w który będziemy chcieli mieć zainstalowane narzędzia dla pgbench. Zadbajmy też o odpowiednie uprawnienia. Wydajemy komendę:


git clone git://git.postgresql.org/git/pgbench-tools.git


PgBench-tools wykorzystuje pakiet „gnuplot” służący do generowania wykresów, a bez którego nie zobaczymy wyników (jakoś producentom zapomniało się dodać o tym informacji w dokumentacji i w pliki readme). Zainstalujmy go więc:


yum install gnuplot


Przechodzimy teraz do katalogu rozpakowanego pakietu:


cd pgbench-tools/


Bazę przechowującą wyniki musimy zainicjalizować:


psql -f init/resultdb.sql -d results


Konfiguracja i uruchamianie testów


Od uruchomienia testów dzieli nas już tylko konfiguracja w pliku config znajdującym się w katalogu pgbench-tools. Przechodzimy do edycji:


nano config


Kilka rzeczy trzeba ustawić aby to narzędzie w ogóle działało i od tego zaczniemy. W pliku config znajdziemy parametry BASEDIR I PGBENCHBIN. Pierwszy odnosi się do katalogu w którym mają zostać wygenerowane wyniki, drugi powinien wskazywać ścieżkę do narzędzia pgbench (powinien być tam gdzie wszystkie binaria PostgreSQL).




Teraz ustawienia opcjonalne które znajdziemy w dalszej części pliku:




Możemy tutaj zmienić hosta na którym znajduje się baza testowa i baza na wyniki, a także ustawić port na którym nasłuchuje PostgreSQL. Od razu uprzedzam – bardzo nie polecam puszczania testów przez sieć. Odbywają się one wtedy okropnie wolno.


Kolejna część parametrów:




Przyjrzyjmy się parametrom SCRIPT,SCALES,SETCLIENTS i SETTIMES. Pierwszy parametr SCRIPT określa skrypt używany do testów. Jest ich kilka i wykonują różne operacje. Możesz nawet stworzyć własne. Wszystkie one znajdują się w podkatalogu tests. Poniżej wyświetlam ich listę oraz zawartość tego ustawionego domyślnie.



Drugi parametr SCALES określa skalę – dla jakiej wielkości bazy mają odbywać się testy (to determinuje wielkość tabel tworzonych przez pgbencha – zależności są tu takie same jak w przełączniku -s samego pgbench). Parametr SETCLIENTS określa ilość klientów z których mają być przeprowadzane testy. W domyślnym ustawieniu najpierw testy przebiegają z użyciem jednego klienta, następnie dwóch, czterech itd. Parametr SETTIMES określa ile razy mają być przeprowadzane testy.

Na potrzeby testów do tej publikacji ustawiam skalę na 1 i 10, 1 2 i 4 klientów oraz 3-krotne uruchomienie testów.

Zanim uruchomimy testy, upewnij się że masz wystarczającą ilość miejsca na dysku na ewentualnie powstające zarchiwizowane pliki WAL! Jeśli tego miejsca zabraknie, testy zostaną przerwane (sprawdzone na własnej skórze po kilku godzinach mielenia testów).

Aby rozpocząć testy uruchamiamy skrypt runset:

./runset


Po uruchomieniu skrypt zacznie tworzyć potrzebne mu tabele. Ewentualnymi ostrzeżeniami o braku jakiejś tabeli się po prostu nie przejmujemy. Przyjrzyj się linijce zaczynającej się od „Run set”. Informuje nas ona który jest to test. W związku z moimi ustawieniami przeprowadzone będą TRZYKROTNIE następujące testy:



Skala

Ilość klientów

1

1

1

2

1

4

10

1

10

2

10

4



W sumie przeprowadzone będzie 18 testów. W linii „Run set” widzimy które to uruchomienie, z iloma klientami i dla jakiej skali. Same testy mogą trochę potrwać, a im więcej dałeś skal i klientów tym dłużej. Podczas testów wywoływane są checkpointy, więc będą nam się archiwizowały pliki WAL. Monitoruj przestrzeń w której są składowane, aby nie została zapełniona w 100%.

Takie testy są baaaardzo obciążające dla bazy. Nie wykonuj ich więc na środowisku na której aktualnie pracują użytkownicy!


Przeglądanie wyników testów i ich analiza


Kiedy testy dobiegną końca, wchodzimy w podkatalog results i uruchamiamy znajdujący się w nim plik index.htm Powinniśmy tam zobaczyć wyniki testów. Jeśli nie zainstalowałeś wspomnianego wcześniej pakietu gnuplot, nie zobaczysz takich eleganckich wykresów jak poniżej. Pierwszy wykres obrazuje stosunek wielkości bazy danych do ilości przeprowadzanych transakcji na sekundę. Zasadniczo wynik był do przewidzenia, im większa baza tym mniej traksakcji jest się w stanie odbyć w ciągu sekundy. Jeśli przypomnimy sobie zawartość testowego pliku select.sql, zauważymy że są to zapytania wyciągające po jednym wierszu. Do przewidzenia było więc że wydajność będzie spadała liniowo w stosunku do ilości wierszy w tabelach. Za chwilę zobaczymy jak to wygląda dla operacji DML, tutaj mogą być nieco bardziej zaskakujące wyniki, a także stworzymy własny plik z instrukcjami dla testów.




Przyjrzyj się za to drugiemu wykresowi. Mamy tutaj przedstawioną wydajność wyrażoną w liczbie transakcji na sekundę w stosunku do ilości klientów. Przyjrzyj się najwyższemu punktowi wykresu. Przy jakiej ilości klientów osiągnięto najwyższą wydajność? Przy 8! Tak się składa że na komputerze na którym uruchamiałem te testy jest akurat 8 rdzeni :) To jest moment maksymalnego wykorzystania ich wydajności. Potem gdy klientów jest więcej wydajność zaczyna spadać a wynika to z konieczności przełączania się procesora między wątkami.



Nieco niżej znajdziemy tabelkę z zestawionymi wynikami rozbitymi na poszczególne testy.



Myślę że jego interpretacja nie powinna sprawić problemu. Widzimy tutaj skale i ilość klientów których sami konfigurowaliśmy w pliku config. Obok liczba transakcji na sekundę przy danym teście, maksymalne opóźnienie etc. Możemy kliknąć na numer testu by wejść w jego szczegóły:



Pod linkiem pg_settings.txt zobaczymy aktualną konfigurację jaka obowiązywała podczas przeprowadzania danego testu.



Pod linkiem result.txt zobaczymy szczegóły danego testu.


W niektórych przypadkach po kliknięciu na numer testu zobaczymy nieco więcej rzeczy. Są wygenerowane pliki graficzne. Nie we wszystkich testach mi się to wygenerowało, niby nie dostałem żadnego błędu, ale musiał zaistnieć jakiś problem dla którego nie utworzyły się te pliki. Powinny być wszędzie. Te pliki graficzne to obrazy dla danego testu.



Kiedy klikniemy na zawarty w tym samym katalogu plik index.html powinniśmy zobaczyć jeszcze owe wykresy: