Dostrajanie bazy danych Firebird SQL o pojemności 1,7 terabajta
Alexey Kovyazin, 14 lipca 2014
Jak pamiętacie z naszych poprzednich artykułów, zbadaliśmy mity dotyczące degradacji wydajności Firebirda ( /pl/articles/firebird-performance-degradation-tests-myths-and-truth/), gdzie utworzyliśmy kilka baz danych od 9 GB do 30 GB, a także przetestowaliśmy bardzo dużą bazę danych Firebird (1,7 terabajta) (/pl/articles/more-details-about-1-7-terabyte-firebird-sql-database/).
Wszystkie testy zostały przeprowadzone na tym samym sprzęcie, który jest dość niskobudżetową konfiguracją: CPU AMD-FX8350, RAM 16 GB, SATA software RAID1 2x4TB HDD Seagate, system operacyjny Windows Server 2008R2 (2008R2 jest 64-bitowy), oraz z tą samą konfiguracją Firebirda: Firebird 2.5.2 64-bit, SuperServer, ze zwiększonymi buforami stron i TempCacheSize. Możesz pobrać ten plik konfiguracyjny SuperServer za darmo z tej lokalizacji: /pl/optimized-firebird-configuration/
W rezultacie otrzymaliśmy następujący obraz wydajności bazy danych:
Rysunek 1. Degradacja wydajności od 9 GB do 30 GB oraz 1,7 TB
Punkt #11 to ocena wydajności dla bazy 30 GB, a #12 dla bazy 1,7 terabajta - rozmiar bazy wzrósł 60 razy (z 30 GB do 1813 GB), strata wydajności wyniosła 2,4 razy (z 407 do 169 punktów).
Zatem pytanie brzmi: czy możemy poprawić wydajność Firebirda na tym samym sprzęcie poprzez dostrojenie konfiguracji?
A odpowiedź brzmi: tak!
Supercharging FirebirdSQL
Jak pamiętacie, w tym teście uruchomiliśmy 20 jednoczesnych połączeń, które wykonują intensywne operacje INSERT oraz mniej intensywne UPDATE.
Wszystkie SELECT-y są krótkie i dobrze zdefiniowane, z efektywnymi planami wykonania SQL, więc jest to typowa aplikacja OLTP (przetwarzanie transakcji online). Dla takich aplikacji najważniejsza dla wydajności jest równoległość przetwarzania. Firebird SuperServer 2.5.2 nie jest dobrze przystosowany do przetwarzania wielowątkowego - efektywnie wykorzystuje tylko 1 rdzeń na bazę danych, co sprawia, że SuperServer nie jest najlepszym wyborem dla aplikacji OLTP.
Dlatego musimy zmienić architekturę Firebirda na Classic lub SuperClassic, które obsługują przetwarzanie wielowątkowe i wykorzystują wiele rdzeni CPU (w CPU AMD-FX8350 jest 8 rdzeni).
Następnie potrzebne jest pewne dostrojenie, ponieważ domyślna konfiguracja Firebirda nie jest optymalna dla naszego systemu testowego.
Dostrajanie parametrów w firebird.conf
Pamięć podręczna stron
Aby poprawić wydajność OLTP, postanowiliśmy wypróbować architektury Classic i SuperClassic. Jednym z kluczowych parametrów dla Classic i SuperClassic jest liczba buforów stron w pamięci podręcznej. W przeciwieństwie do SuperServer, Classic i SuperClassic przydzielają pamięć podręczną stron dla każdego połączenia.
Więcej szczegółów na temat architektur Firebirda w wersji 2.5 można znaleźć w tej tabeli: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf
Istnieje prosty wzór do obliczenia użycia pamięci podręcznej stron dla różnych architektur Firebirda:
- SuperServer - pojedyncza pamięć podręczna stron na bazę danych. Domyślny rozmiar pamięci podręcznej to 2048 stron, zalecane jest 10000 buforów. W naszym przypadku pamięć podręczna wynosiła 16k (rozmiar strony) x 10000 ~= 160 MB. To dla wszystkich połączeń.
- Classic i SuperClassic - silnik przydziela pamięć podręczną stron dla każdego połączenia. Domyślny rozmiar to 75 stron, więc 16 KB (rozmiar strony) x 75 = ~= 1,17 MB dla każdego połączenia.
Oczywiście rozmiar pamięci podręcznej stron powinien zostać zwiększony, ponieważ 75 stron na połączenie to zbyt mało. Poniżej pokażemy wyniki dla kilku różnych wartości rozmiaru pamięci podręcznej stron.
LockHashSlots
Wewnętrznie silnik Firebirda używa tabeli blokad do żądania i uzyskiwania blokad dla wewnętrznych obiektów w bazie danych, a dla Classic i SuperClassic istnieje parametr LockHashSlots (domyślna wartość to 1009). Należy go zwiększyć przy wysokim obciążeniu, aby zmniejszyć łańcuchy haszujące w tabeli blokad. Cóż, “wysokie obciążenie” wydaje się być każdą rzeczywistą aplikacją wieloużytkownikową, więc ustawiliśmy go na 30011 (dla wszystkich testów).
LockMemSize
Parametr LockMemSize służy do ustawienia początkowego rozmiaru tabeli blokad (domyślna wartość to 1048576). Silnik może zwiększyć rozmiar tabeli w razie potrzeby. Jednak zwiększenie tabeli blokad jest kosztowne pod względem CPU i innych zasobów, ponieważ odbywa się poprzez ponowne mapowanie pamięci. Dlatego ustawiliśmy go na 7 MB, aby zaoszczędzić trochę czasu i zasobów CPU.
Przebiegi testów
Wykonaliśmy kilka przebiegów testów z różnymi wartościami pamięci podręcznej stron, z następującymi wynikami:
| Bufor stron | Classic, punkty testowe | SuperClassic, punkty testowe |
|---|---|---|
| 256 | 299 | 372 |
| 512 | 371 | 359 |
| 768 | 362 | 386 |
| 1024 | 312 | 387 |
| 1500 | 390 | 392 |
| 2048 | 285 | 284 |
Tabela 1. Przebiegi testów dla Classic i SuperClassic
Jak widać, Classic i SuperClassic są znacznie bardziej efektywne niż Firebird SuperServer dla tego zadania: wyniki testów poprawiły się z 169 punktów do 300-400, co jest zbliżone do wyników, które uzyskaliśmy dla bazy 30 GB!
Lepiej zobaczyć wyniki na poniższym wykresie:
Rysunek 2. Wyniki testów dla bazy 1,7 terabajta
Można zauważyć, że najlepsza wydajność (zarówno w Classic, jak i SuperClassic) była przy 1500 stronach na połączenie, więc rozmiar pamięci podręcznej stron na połączenie wynosił:
1500x16k ~= 23,4 MB
Przy 2000 stronach na połączenie wydajność znacznie spadła. Wydaje się, że gdzieś w okolicach 1500-2000 stron przewaga buforowania stała się mniejsza niż narzut związany z interakcjami tabeli blokad między procesami w celu synchronizacji stron w pamięciach podręcznych każdego procesu serwera. Oczywiście dla większej liczby połączeń nastąpi to wcześniej, dlatego serwery Classic/SuperClassic są zwykle konfigurowane z wartościami takimi jak 256-512 stron.
Widać również spadek wydajności Classic w okolicach 768-1000 stron pamięci podręcznej - nie jesteśmy pewni, dlaczego tak się stało.
Podsumowanie
Nasze eksperymenty potwierdzają, że wydajność Firebirda może zostać zwiększona poprzez odpowiedni wybór architektury Firebirda (SuperServer, Classic lub SuperClassic) oraz odpowiednie dostrojenie kilku ważnych parametrów dla konkretnej architektury.
W rezultacie ogromna baza danych Firebird SQL o rozmiarze 1,7 TB może działać na sprzęcie niskiej klasy z wystarczająco dobrą wydajnością. Jako praktyczny wynik tych testów utworzyliśmy kilka plików konfiguracyjnych dla wszystkich wersji Firebirda i wszystkich architektur. Oczywiście nie są one dostrojone pod konkretną aplikację i/lub sprzęt, ale są lepsze niż domyślne pliki konfiguracyjne, które są przeznaczone do bardzo umiarkowanego obciążenia.
Pełny zestaw zoptymalizowanych plików konfiguracyjnych Firebirda: /pl/optimized-firebird-configuration/
Zachęcamy do zadawania pytań: [email protected]
Co dalej?
Pracujemy nad kompleksowym testem, który porówna wydajność Firebirda 2.5 i Firebirda 3.0, z symulacją rzeczywistego obciążenia i ogromną liczbą połączeń. Bądźcie na bieżąco!