Degradacja wydajności Firebird: testy, mity i prawda
Alexey Kovyazin, 16 maja 2014
Możesz pobrać ten artykuł w formacie PDF.
Ostatnio w IBSurgeon przeprowadziliśmy serię testów wydajnościowych z Firebird 2.5.2. Firebird 2.5.2 to najpopularniejsza wersja bazy danych Firebird, a jej użytkownicy często mają pytania związane z wydajnością Firebird.
Jedną z najważniejszych kwestii dotyczących wydajności bazy danych jest jej degradacja. Wielu użytkowników twierdzi, że ich aplikacje bazodanowe mają problemy z wydajnością po osiągnięciu pewnej wartości progowej: może to być 3 GB, 5 GB, rozmiar pamięci RAM, 20 GB itp. Najpopularniejsze twierdzenie to „rozmiar bazy danych jest większy niż rozmiar pamięci RAM”: gdy rozmiar bazy danych Firebird osiągnie rozmiar pamięci RAM, podobno staje się bardzo wolna… Czy to prawda?
Postanowiliśmy przeprowadzić serię testów, aby sprawdzić, czy istnieje taka degradacja wydajności związana ze wzrostem bazy danych. Zdecydowaliśmy się zasymulować wzrost bazy danych w czasie przy tym samym obciążeniu na tym samym sprzęcie. W tym celu uruchomiliśmy 11 testów z bazami danych o rozmiarach od 9 GB do 30 GB:
Rysunek 1. Rozmiary baz danych do testów
Sprzęt testowy i konfiguracja Firebird
Sprzęt testowy miał następujące kluczowe cechy:
CPU AMD-FX8350, RAM 16 GB, SATA software RAID1 2x4TB dyski Seagate, system operacyjny Windows Server 2008R2 (2008R2 jest 64-bitowy).
Jak widać, jest to konfiguracja sprzętowa z niższej półki; można ją kupić za mniej niż 1000 USD w tej chwili (maj 2014) i można ją uznać za typową konfigurację niskopoziomową - może z wyjątkiem dużych dysków SATA, ale według raportu producenta prędkość dysków SATA 1 TB i 4 TB jest prawie taka sama.
Ponieważ celem testu było zmierzenie zmian wydajności typowego systemu, użyliśmy Firebird (64-bit) z architekturą SuperServer, a nie Classic, aby w pełni zasymulować sytuację w małej firmie - używają tego, co było pierwotnie zainstalowane przez lata. Jak wiadomo, SuperServer używa tylko 1 rdzenia CPU, więc prawdopodobnie Classic lub SuperClassic (które mogą używać wszystkich rdzeni CPU) mogłyby pokazać lepsze wyniki pod względem wydajności, ale naszym celem nie było strojenie wydajności.
Jednak dostroiliśmy firebird.conf z oczywistymi zmianami, które zalecamy dla wszystkich instalacji Firebird SuperServer: zwiększyliśmy bufory stron do 10000 i przestrzeń tymczasową do sortowania.
Wszystkie testowe bazy danych zostały utworzone z rozmiarem strony 16384, tylko dla spójności.
Testowanie
Ładowanie
Każdy test składał się z 2 kroków: ładowania i symulacji 20 terminali wykonujących operacje wstawiania, aktualizacji i usuwania.
Krok ładowania jest wykonywany przez aplikację ładującą (load.exe), która wstawia dane do kilku tabel. Jak widać na rysunku 2, dane są ładowane z różną prędkością; waha się ona od ~35 MB/s do 1 MB/s.
Rysunek 2. Prędkość ładowania bazy danych (czerwony wykres)
Jest to związane z projektem aplikacji ładującej, a nie z Firebird: loader szybko wstawia 70% bazy danych, a następnie powoli wypełnia resztę danych, i powtarza się to dla baz danych o wszystkich rozmiarach. Ważne jest dla nas, że loader wykonuje te same operacje, więc możemy użyć jego średniej prędkości do zmierzenia szybkości ładowania.
Ważne jest, aby powiedzieć, że loader wstawia tylko dane, a indeksy są tworzone po zakończeniu ładowania.
Spójrzmy na tabelę z wynikami kroku ładowania dla 11 baz danych między 9 a 30 GB:
| # | rozmiar bazy danych, GB | czas ładowania, s | prędkość ładowania SATA, MB/s |
|---|---|---|---|
| 1 | 9,04 | 2535 | 3,65166075 |
| 2 | 10,80 | 3197 | 3,45924304 |
| 3 | 13,00 | 4057 | 3,281242297 |
| 4 | 15,50 | 4698 | 3,378458919 |
| 5 | 17,30 | 5455 | 3,24751604 |
| 6 | 19,90 | 6037 | 3,375451383 |
| 7 | 21,60 | 6473 | 3,417024564 |
| 8 | 24,20 | 7539 | 3,287014193 |
| 9 | 26,00 | 7779 | 3,422547885 |
| 10 | 28,60 | 8851 | 3,308823862 |
| 11 | 30,30 | 9266 | 3,348499892 |
Rysunek 3. Czas i prędkość ładowania
Lub lepiej pokazać to na wykresie na rysunku 4:
Rysunek 4. Wyniki testów: prędkość ładowania.
Jak widać, wykres jest dość stabilny, a średnia prędkość procesu ładowania waha się wokół 3,3-3,4 MB/s. Nie ma również oznak spadku prędkości ładowania, gdy rozmiar bazy danych przekracza rozmiar pamięci RAM (po bazie danych #5, o rozmiarze 17,3 GB).
Wydajność
Czasy ładowania wyglądają więc obiecująco, a co z rzeczywistymi wynikami wydajności?
Zanim przejdziemy do wyników wydajności, szybko przejrzyjmy proces symulacji.
Symulacja uruchamia 20 wątków, a każdy z nich losowo wykonuje kilka operacji biznesowych: utworzenie nowego zamówienia, przetworzenie płatności, zliczenie produktów w magazynie, przetworzenie dostawy zamówienia itp. (szczegóły można zobaczyć w tekstach SQL rzeczywistych procedur składowanych). Jak widać, jest to zwykły zestaw operacji biznesowych abstrakcyjnej aplikacji magazynowo-sprzedażowej.
Aplikacja testowa mierzy liczbę operacji biznesowych na sekundę i raportuje średnią liczbę. Oczywiście jest to sztuczny parametr, ale wystarczająco dobry do porównania.
Wyniki testów wydajności:
| # | rozmiar bazy danych, GB | wydajność na SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
Rysunek 5. Tabela z wynikami testów wydajności.
Lub lepiej zobaczyć wyniki w reprezentacji graficznej:
Rysunek 6. Wykres wyników wydajności
Jak widać, następuje powolna degradacja wydajności wraz ze wzrostem rozmiaru bazy danych - im większa baza, tym wolniej będzie działać (na tym samym sprzęcie). Nie ma również dużego spadku wydajności, gdy rozmiar bazy danych przekracza pamięć RAM. Wzrost bazy danych z 9 GB do 30 GB prowadzi do około 20% utraty wydajności.
Bazy danych Firebird o rozmiarze 30 GB są teraz wszędzie i rosną z czasem. Jednak co się stanie z wydajnością bazy danych, gdy będzie jeszcze większa? Mamy na myśli - WIĘKSZA! Co się stanie z wydajnością, gdy baza danych stanie się NAPRAWDĘ DUŻA?
Mr.Big
Aby odpowiedzieć na to pytanie, postanowiliśmy zajrzeć na sam koniec tabeli testowej i przeprowadzić test z bazą danych o rozmiarze 1,7 TB (1813 GB), na tym samym sprzęcie, z tymi samymi ustawieniami.
Ładowanie
Stworzyliśmy więc taką bazę danych:
Rysunek 7. Rozmiar bazy danych - teraz z bazą 1813 GB
Ładowanie zajęło 566448 sekund - 157 godzin, 6,55 dnia. To długi czas, ale średnia prędkość ładowania wynosiła… 3,28 MB/s!
| # | rozmiar bazy danych, GB | czas ładowania, s | prędkość ładowania SATA, MB/s |
|---|---|---|---|
| 12 | 1813,969025 | 566448 | 3,279214122 |
Rysunek 8. Czas i prędkość ładowania dla bazy danych Firebird 1,7 TB
Na wykresie wygląda to bardzo dobrze: ostatni punkt (#12). Firebird pokazuje więc bardzo dobre wyniki swoich algorytmów wstawiania.
Rysunek 9. Prędkość ładowania - punkt #12 dotyczy bazy danych Firebird 1,7 TB
Wydajność Mr.Big
Następnie uruchomiliśmy ten sam test wydajności - linia 12 dotyczy bazy danych 1,7 TB.
| # | rozmiar bazy danych, GB | wydajność na SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
| 12 | 1813,969025 | 169,33 |
Rysunek 10. Wyniki testów wydajności - linia 12 dotyczy bazy danych 1,7 TB
I na wykresie:
Rysunek 11. Wydajność, punkt #12 dotyczy bazy danych 1,7 TB
Wynik potwierdza, że w Firebird następuje powolna i stabilna degradacja wydajności - podczas gdy rozmiar bazy danych wzrósł 60-krotnie (z 30 GB do 1813 GB), utrata wydajności wyniosła 2,4 razy (z 407 do 169 punktów).
To nie jest częsta sytuacja, gdy baza danych (na tym samym sprzęcie z niższej półki) rośnie z 30 GB do 1,7 TB, ale Firebird będzie działać nawet w tej sytuacji.
Duża baza danych w szczegółach
Aby lepiej zrozumieć bazę danych 1,7 TB, zebraliśmy statystyki bazy danych dla bazy Mr.Big i przeanalizowaliśmy je w IBAnalyst:
Rysunek 12. Tabele bazy danych 1,7 TB w IBAnalyst
Jak widać, są 2 duże tabele - ORDER_LINE (~600 GB) z 6,3 miliarda rekordów i STOCK (~680 GB) z 2,1 miliarda rekordów.
Dla tych tabel istnieją 2 indeksy o głębokości = 4 - oznacza to, że każde żądanie wykonuje 4 odczyty stron indeksu przed rzeczywistym odczytem danych. Indeks ORDER_LINE_PK ma rozmiar 50 GB.
Rysunek 13. Indeksy bazy danych Firebird 1,7 TB
Pomimo ogromnej liczby rekordów, statystyki bazy danych wyglądają dobrze, więc nie jest zaskoczeniem, że Firebird pokazuje całkiem dobre wyniki nawet dla dużej bazy danych na sprzęcie z niższej półki.
Testowanie Firebird z dyskiem SSD
Po zakończeniu serii testów Firebird na sprzęcie z niższej półki postanowiliśmy sprawdzić, jakie będą wyniki na drugim końcu technologii przechowywania danych i zainstalowaliśmy dysk SSD na tym samym serwerze.
Zainstalowaliśmy dysk SSD Plextor PX-256M M5 Pro i uruchomiliśmy tę samą serię testów (z wyjątkiem bazy danych 1,7 TB), z tymi samymi ustawieniami. Wyniki zostały dodane do wykresów z urządzeniami SATA, zobacz je poniżej.
Ładowanie
Jak widać, czas ładowania na SSD jest taki sam jak na SATA. Jest to oczekiwany wynik: prędkość sekwencyjnych operacji zapisu jest prawie taka sama na dyskach SATA i SSD.
Rysunek 14. Ładowanie na SSD i SATA
Wydajność
Zobacz wyniki wydajności:
Rysunek 15. Wydajność na SSD i SATA
Jak widać, wydajność przy losowych operacjach wejścia/wyjścia pokazuje ~8x lepsze wyniki dla dysku SSD. Wiedzieliśmy z naszego doświadczenia z bazami danych klientów, że SSD jest 30-50% szybszy w rzeczywistych aplikacjach, ale wzrost 8x jest bardzo wysoki.
Jednak ten test jest sztuczny i specjalnie zaprojektowany do symulacji operacji OLTP o wysokim obciążeniu, z wieloma aktualizacjami/usunięciami, ale bez dużych pobrań. Zwykła aplikacja bazodanowa nie pracuje w tym trybie przez cały czas. To wyjaśnia, dlaczego SSD pokazuje tak wysokie wyniki w tym konkretnym przypadku.
Podsumowanie
Czego więc dowiedzieliśmy się z tych testów?
Po pierwsze - wydajność Firebird nie ma dużych spadków związanych z jakimś ograniczeniem rozmiaru. Na tym samym sprzęcie wydajność będzie powoli spadać wraz ze wzrostem rozmiaru bazy danych. Taki spadek wydajności można skompensować dostrojeniem konfiguracji Firebird lub mądrym ulepszeniem sprzętu.
To dobre miejsce, aby wspomnieć, że IBSurgeon oferuje usługę optymalizacji wydajności Firebird - wykorzystując dane eksperymentalne zebrane z testów takich jak ten, możemy znacząco zwiększyć wydajność baz danych Firebird i InterBase.
Po drugie, dowiedzieliśmy się, że nawet bardzo duże bazy danych Firebird (1,7 terabajta) będą działać na sprzęcie z niższej półki ze znaczną, ale akceptowalną utratą wydajności.
I po trzecie, SSD jest naprawdę dobry dla aplikacji OLTP. Prawdopodobnie jest to najtańszy sposób na ulepszenie wydajności bazy danych w tej chwili. Oczywiście użycie SSD nie naprawi problemów ze złymi planami zapytań i nieefektywnymi indeksami, ale może ogólnie podnieść wydajność.
Ciąg dalszy nastąpi: Więcej szczegółów na temat bazy danych Firebird o rozmiarze 1,7 terabajta.