Przewodnik po sprzęcie dla Firebird

_by Alexey Kovyazin, ostatnia aktualizacja: 30 listopada 2015

Często można zobaczyć następujące pytanie w grupach wsparcia technicznego Firebird: “Jaki sprzęt wybrać dla systemu DBMS Firebird?”. Ten temat pozostaje stale popularny, ponieważ wymagania sprzętowe różnią się w zależności od zadań, a sam sprzęt zmienia się z czasem.

Postanowiliśmy napisać ten przewodnik, aby zapewnić niezbędną wiedzę każdemu, kto chce wybrać naprawdę wydajny sprzęt dla swojej bazy danych Firebird. Aby to zrobić, musisz poznać kilka podstawowych szczegółów na temat tego, jak działają Firebird, system operacyjny i, oczywiście, sprzęt.

Trochę Teorii

Aby dowiedzieć się, jaki sprzęt będzie najlepiej pasował do Twojej bazy danych Firebird, musimy zrozumieć, jak Firebird wykorzystuje swoje komponenty: CPU, RAM, HDD/SSD oraz jak te komponenty współdziałają z systemem operacyjnym (na przykład z pamięcią podręczną plików).

Moduły Funkcjonalne Serwera Firebird

Przede wszystkim przyjrzymy się modułom funkcjonalnym Firebird za pomocą Rysunku 1:

Rysunek 1. Moduły Firebird

Firebird zawiera następujące główne moduły funkcjonalne:

Obiekty metadanych: widoki, tabele, indeksy, wyzwalacze, procedury składowane i inne obiekty bazy danych. Obiekty metadanych znajdują się w przestrzeni adresowej procesu Firebird (może to być fbserver, fb_inet_server lub firebird.exe).
Pamięć podręczna buforów stron zawiera strony bazy danych odczytane z dysku i znajduje się w przestrzeni adresowej procesu serwera. Mechanizm buforowania stron jest dość skomplikowany, więc powiemy tylko, że Firebird buforuje najczęściej używane strony bazy danych.
Firebird sortuje rekordy w pamięci (w przestrzeni adresowej procesu serwera), dopóki ilość pamięci używanej dla wszystkich równoczesnych operacji sortowania nie osiągnie limitu ustawionego przez parametr TempCacheLimit (firebird.conf). Po przekroczeniu tego limitu tworzony jest plik tymczasowy (z odpowiednią flagą systemu operacyjnego) w folderze z plikami tymczasowymi i jest on używany do sortowania. Jeśli w systemie jest wolna pamięć RAM, plik sortowania będzie buforowany przez system operacyjny, a sortowanie będzie wykonywane w pamięci.
Globalne Tabele Tymczasowe (GTT) są tworzone jako pliki tymczasowe w systemie operacyjnym. Jeśli system operacyjny ma wolną pamięć, operacje na GTT są wykonywane w pamięci RAM.

Podstawowe Operacje na Sprzęcie

Zobaczmy, jak moduły funkcjonalne Firebird współdziałają z komponentami sprzętowymi podczas operacji wykonywanych w trakcie pracy z bazami danych.

Po uruchomieniu Firebird proces serwera zajmuje minimalną ilość pamięci RAM (kilka megabajtów) i nie wykonuje żadnych intensywnych operacji na CPU lub RAM.

Gdy nawiązywane jest połączenie z bazą danych, serwer zaczyna odczytywać jej metadane i tworzyć odpowiednie obiekty w pamięci, co powoduje, że proces zużywa tym więcej zasobów, im więcej tabel, indeksów, wyzwalaczy i innych metadanych jest używanych. Użycie pamięci wzrasta, ale CPU praktycznie nie jest używany na tym etapie.

Gdy klient zaczyna wykonywać zapytania SQL (w tym procedury składowane), serwer wykonuje odpowiednie operacje z użyciem sprzętu. Można wyróżnić następujące podstawowe operacje obejmujące interakcję ze sprzętem:

odczytywanie stron bazy danych z dysku twardego,
zapisywanie stron bazy danych na dysk twardy,
odczytywanie stron bazy danych z pamięci podręcznej,
zapisywanie stron bazy danych do pamięci podręcznej,
odczytywanie danych z i zapisywanie danych do globalnych tabel tymczasowych,
przetwarzanie zapytań SQL (na przykład JOIN),
sortowanie rekordów w zestawach wynikowych.

Każda z tych operacji wymaga określonej ilości zasobów systemowych. Poniższa tabela pokazuje zużycie zasobów w jednostkach intensywności (1 oznacza najmniej intensywne, 10 najbardziej intensywne):


	Odczyt strony z dysku	Zapis strony na dysk	Odczyt strony z pamięci podręcznej buforów stron	Zapis strony do pamięci podręcznej buforów stron	Odczyt z GTT	Zapis do GTT	Sortowanie rekordów	Przetwarzanie zapytań SQL
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
I/O dysku	10	10	1	1	1	1	1	1

Jak widać, najbardziej zasobożerne operacje to te, które obejmują dostęp do dysku, ponieważ dyski pozostają najwolniejszym komponentem sprzętowym pomimo postępu w ostatnich latach związanego z dyskami SSD.

Prowadzi to do jednego ze sposobów optymalizacji wydajności, który jest całkowicie związany ze sprzętem - przeniesienie wszystkich operacji odczytu-zapisu do pamięci RAM. Należy jednak zauważyć, że podejście polegające na zwiększaniu pamięci podręcznej stron nie działa. Zajmiemy się tym problemem szczegółowo w sekcji RAM.

Operacje Wykonywane Równocześnie

Zazwyczaj konieczne jest wybranie sprzętu dla serwera, który będzie obsługiwał wielu klientów, więc naprawdę ważne jest zrozumienie, jak implementowana jest równoległość operacji.

Z punktu widzenia komponentów sprzętowych możemy mówić o równoległym użyciu CPU, dysku i RAM. Nowoczesne CPU mają kilka rdzeni, które mogą wykonywać zestawy instrukcji równolegle, więc serwer DBMS rozdziela operacje między rdzenie, co oznacza wniosek, że im więcej rdzeni ma CPU, tym więcej klientów będzie mogło pracować na tym serwerze.

Nie jest to takie proste z punktu widzenia dysków. Gdy tradycyjne dyski twarde (HDD) odczytują informacje, fizycznie przesuwają głowicę nad materiałem magnetycznym z pewną skończoną prędkością. Baza danych może być dość duża, tj. 3 terabajty, a jeśli zapytania SQL od klientów uzyskują dostęp do jej danych znajdujących się w różnych obszarach dysku równolegle, głowica dysku będzie przeskakiwać między różnymi obszarami dysku, poważnie spowalniając operacje odczytu i zapisu. Znacznie zwiększy to kolejkę dysku, podczas gdy pozostałe zasoby (CPU, RAM) będą bezczynne. Oczywiście pamięć podręczna dysku (pamięć podręczna HDD lub kontrolera RAID) w pewnym stopniu rekompensuje to spowolnienie, ale to nie wystarczy.

W przeciwieństwie do tradycyjnych dysków HDD, dyski półprzewodnikowe (SSD) są znacznie mniej podatne na degradację wydajności w przypadku równoległego dostępu do danych. Zaleta dysku SSD jest szczególnie widoczna podczas równoległego zapisu danych - nasze testy pokazują, że SSD jest 7 razy szybszy niż dysk SATA (link!). Jednak dyski SSD mają pewne problemy, które należy wziąć pod uwagę podczas ich użytkowania (patrz Wybór dysków), aby uniknąć spowolnień, wczesnych awarii i utraty danych.

Operacje na pamięci RAM są wykonywane bardzo szybko na nowoczesnych komputerach, są praktycznie ograniczone tylko przepustowością magistrali danych, więc operacje te nie stanowią wąskiego gardła nawet przy wielu równoległych zapytaniach SQL.

Przepływy Danych

Podczas wykonywania zapytań SQL Firebird odczytuje i zapisuje dużo danych, przesyła je między modułami funkcjonalnymi a odpowiednimi komponentami sprzętowymi. Aby zidentyfikować możliwe wąskie gardła, musimy zrozumieć, jak odbywa się wymiana danych. Pomoże nam w tym Rysunek 2 poniżej:

Rysunek 2. Przepływy danych między RAM a trwałym magazynem

Oczywiście przesyłanie danych z trwałego magazynu do RAM i z powrotem jest najbardziej czasochłonną operacją. Tworzy ona dwa przepływy danych: odczytywanie/zapisywanie stron danych z plików bazy danych oraz odczytywanie/zapisywanie plików sortowania. Ponieważ może być kilka plików sortowania i mogą być one dość duże, mogą one powodować dość duże obciążenie dysków, dlatego zaleca się skierowanie tych przepływów wejścia/wyjścia na różne dyski.

Kopia Zapasowa

Firebird oferuje dwie metody tworzenia kopii zapasowych: zweryfikowaną kopię zapasową za pomocą narzędzia gbak oraz niezweryfikowaną przyrostową kopię zapasową za pomocą narzędzia nbackup.

Zalecamy połączenie tych metod tworzenia kopii zapasowych: uruchamiaj nbackup często (na przykład co godzinę, dzień i tydzień) i twórz zweryfikowaną kopię zapasową każdej nocy za pomocą gbak.

Niezależnie od metody tworzenia kopii zapasowej, plik bazy danych jest odczytywany (w całości lub częściowo), a kopia zapasowa (pełna lub przyrostowa) jest zapisywana. Operacje zapisu są wykonywane sekwencyjnie podczas procesu tworzenia kopii zapasowej, co oznacza, że zwykłe niedrogie dyski twarde z interfejsem SATA (HDD SATA) będą dobre do tworzenia kopii zapasowych, ponieważ zapisują sekwencyjnie dość szybko.

Wybór Odpowiedniego Sprzętu

Teraz, gdy mamy pojęcie, jak Firebird współdziała ze sprzętem, powinniśmy omówić czynniki, które wpływają na wybór każdego konkretnego komponentu i jego specyfikacji.

Czasami rzeczywiste statystyki konkretnej bazy danych silnie wpływają na wybór komponentów sprzętowych, więc użyjemy narzędzi z HQbird (profesjonalnego pakietu dystrybucyjnego Firebird od IBSurgeon), aby uzyskać te statystyki. Możesz pobrać wersję próbną HQbird pod adresem http://hqbird.com/en/hqbird/.

CPU

Wybierając CPU, należy wziąć pod uwagę trzy rzeczy:

Jakie zapytania przeważają w aplikacji,
Liczba aktywnych połączeń z bazą danych średnio i przy szczytowym obciążeniu,
Wersja i architektura Firebird.

Jakie Zapytania Przeważają w Aplikacji?

Firebird zawsze wykonuje jedno zapytanie na jednym rdzeniu, więc złożone i słabo zoptymalizowane zapytania mogą używać jednego rdzenia w 100%, wypychając inne zapytania na mniej obciążone rdzenie, a im więcej jest rdzeni, tym mniejsze są szanse, że cały CPU będzie wykorzystany i że użytkownicy zauważą jakiekolwiek pogorszenie wydajności aplikacji.

Jeśli aplikacja wykonuje głównie proste krótkie zapytania SQL, wszystkie zapytania są dobrze zoptymalizowane i nie są generowane żadne zapytania ad hoc (na przykład do raportów), CPU nie będzie stanowić wąskiego gardła dla wydajności i można wybrać CPU z niższej półki z mniejszą liczbą rdzeni.

Jeśli aplikacja zawiera generator raportów lub wiele wolnych zapytań zwracających dużą ilość danych, potrzebujesz CPU z większą liczbą rdzeni.

Liczba Aktywnych Połączeń z Bazą Danych Średnio i przy Szczytowym Obciążeniu

Liczba połączeń (aktywnych użytkowników) również wpływa na wybór CPU. Niestety, nawet programiści aplikacji nie mają pojęcia, ile dokładnie połączeń, zapytań i transakcji jest aktywnych w danym momencie. Aby uzyskać dokładniejsze informacje na ten temat, zalecamy użycie narzędzia MON$ Logger z HQbird i wykonanie kilku zrzutów podczas jego działania, na których zobaczysz, ile połączeń jest faktycznie nawiązanych.

Rysunek 3. MON$ Logger: liczba połączeń

Na przykład tutaj widać, że liczba połączeń wynosi 296. Oczywiście zbyt optymistyczne jest użycie w tym przypadku CPU z czterema rdzeniami, podczas gdy rozwiązanie z 24 rdzeniami będzie całkiem odpowiednie. Wskazane jest również policzenie liczby jednocześnie uruchomionych zapytań, ponieważ połączenia mogą być bezczynne bez żadnych uruchomionych zapytań SQL.

Możesz użyć współczynnika od 10 do 30 połączeń na 1 rdzeń, aby z grubsza oszacować niezbędną liczbę rdzeni w CPU. 10 połączeń na rdzeń dla aplikacji z przewagą skomplikowanych i wolnych zapytań, 30 połączeń na rdzeń dla aplikacji z przewagą prostych dobrze zoptymalizowanych zapytań.

Wersja i Architektura Firebird

Jeśli używasz Firebird w wersji 2.5, pamiętaj, że powinieneś używać architektury Classic lub SuperClassic, aby móc rozdzielić przetwarzanie między kilka rdzeni. W wersji 2.5 architektura SuperServer może używać tylko jednego rdzenia dla jednej bazy danych, więc nie powinna być używana w systemach zużywających dużo zasobów.

W Firebird w wersji 3.0 SuperServer, Classic i SuperClassic wykorzystują możliwości wielordzeniowych CPU. Firebird 3.0 SuperServer wykazuje najlepszą wydajność.

RAM

Wybierając pamięć RAM, należy zwrócić uwagę na dwie rzeczy:

moduł pamięci musi mieć kod korekcji błędów (ECC RAM)
ilość pamięci RAM musi być poprawnie obliczona

ECC RAM

Pamięć ECC RAM znacznie zmniejsza liczbę błędów występujących podczas pracy z pamięcią i jest zdecydowanie zalecana do stosowania w systemach przemysłowych.

Obliczanie Wymaganej Ilości RAM

Aby obliczyć ilość pamięci, musimy przyjrzeć się specyfice różnych architektur Firebird. Firebird 2.5 Classic i Firebird 3.0 Classic uruchamiają osobny proces do obsługi każdego połączenia, SuperClassic uruchamia osobny wątek dla każdego połączenia, ale praktycznie z taką samą strukturą zużycia pamięci - każde połączenie ma własną, niezależną pamięć podręczną stron.

Firebird SuperServer uruchamia jeden proces z jedną pamięcią podręczną stron dla wszystkich połączeń.

Zatem następujące parametry wpływają na całkowite zużycie pamięci:

Liczba połączeń
Rozmiar strony bazy danych
Rozmiar metadanych (proporcjonalny do liczby tabel, triggerów, procedur składowanych itp.; niemożliwy do regulacji; określony przez fizyczne użycie)
Dla Classic i SuperClassic - na połączenie
Dla SuperServer - na instancję otwartej bazy danych
Rozmiar pamięci podręcznej stron (określany przez parametry w nagłówku bazy danych lub w firebird.conf lub we właściwościach konkretnego połączenia)
Dla Classic i SuperClassic - na połączenie
Dla SuperServer - na instancję otwartej bazy danych
Rozmiar pamięci podręcznej sortowania (określany przez parametr w firebird.conf). Należy zauważyć, że pamięć do sortowania jest przydzielana nie od razu, ale w miarę potrzeby.
Dla Classic - na połączenie
Dla SuperServer i SuperClassic - na proces (tj. jedna pamięć podręczna sortowania)
Dla Classic/SuperClassic - rozmiar tabeli blokad (jest zwykle mały, więc pominiemy go w naszych obliczeniach).

Firma IBSurgeon przeprowadziła kilka testów i uzyskała zestaw optymalnych wartości dla liczby stron w pamięci podręcznej stron Firebird:

Classic/SuperClassic - od 256 do 2000 stron
SuperServer 2.5 - 10000 stron
SuperServer 3.0 - 100000 stron

Na podstawie tych testów stworzyliśmy zoptymalizowane pliki konfiguracyjne Firebird dla serwerów z 4-6 GB pamięci. Możesz je pobrać tutaj: /pl/optimized-firebird-configuration/

Wzory do Obliczania Wymaganej Ilości RAM

Poniżej znajdują się wzory używane do oszacowania przybliżonej ilości pamięci, która będzie wymagana przez Firebird. Rzeczywiste zużycie pamięci może się różnić, ponieważ to oszacowanie nie uwzględnia ilości pamięci wymaganej dla metadanych, masek bitowych indeksów itp., co może zwiększyć zużycie pamięci. Zakłada się jednak również, że pamięć sortowania będzie w pełni wykorzystana we wszystkich połączeniach, co zwykle nie ma miejsca.

Gdy Twoja baza danych jest już w użyciu, możesz sprawdzić średnią ilość pamięci używanej przez proces Firebird (za pomocą Menedżera zadań lub ProcessExplorer).

Szacunek dla Classic:

Liczba połączeń * ( (Liczba stron w pamięci podręcznej * Rozmiar strony) + Rozmiar pamięci podręcznej sortowania )

Przykład dla Classic: załóżmy, że spodziewamy się 100 aktywnych użytkowników, rozmiar strony bazy danych jest ustawiony na 8 KB, a liczba stron w pamięci podręcznej stron jest ustawiona na 256, rozmiar pamięci podręcznej sortowania jest zwiększony z 8 MB (wartość domyślna dla Classic i SuperClassic) do 64 MB:

((256.8 KB)+64) = 6600 MB

Szacunek dla SuperClassic:

Liczba połączeń * (Liczba stron w pamięci podręcznej * Rozmiar strony) + Rozmiar pamięci podręcznej sortowania

Przykład dla SuperClassic: 100 użytkowników, rozmiar strony bazy danych to 8 KB, liczba stron w pamięci podręcznej to 256, rozmiar pamięci podręcznej sortowania to 1024 MB

100.(256.8 KB) + 1024 MB = 2024 MB

Szacunek dla SuperServer:

(Liczba stron w pamięci podręcznej * Rozmiar strony) + Rozmiar pamięci podręcznej sortowania

Przykład dla SuperServer (Firebird 2.5): 1 baza danych, 100 użytkowników, rozmiar strony bazy danych to 8 KB, liczba stron w pamięci podręcznej to 10000, rozmiar pamięci podręcznej sortowania to 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Przykład dla SuperServer (Firebird 3.0): 1 baza danych, 100 użytkowników, rozmiar strony bazy danych to 8 KB, liczba stron w pamięci podręcznej to 100000, rozmiar pamięci podręcznej sortowania to 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Nadmiarowa Pamięć”

Firebird jest często obwiniany za nieefektywne wykorzystanie pamięci - gdy działający proces serwera zużywa małą ilość RAM, a reszta pamięci pozostaje rzekomo niewykorzystana.

W rzeczywistości to nieprawda. Ten wniosek wynika zasadniczo z niezrozumienia działania mechanizmu buforowania Firebird oraz z niedoskonałości narzędzi monitorujących system operacyjny.

Przede wszystkim musisz mieć całkowitą jasność, że Firebird w dużym stopniu korzysta z pamięci podręcznej plików systemu operacyjnego. Gdy strona jest ładowana do pamięci podręcznej stron Firebird, przechodzi przez pamięć podręczną plików systemu operacyjnego. Gdy Firebird zwalnia stronę ze swojej pamięci podręcznej, system operacyjny nadal przechowuje ten fragment bazy danych w swojej pamięci RAM, pod warunkiem że ma wystarczająco wolnej pamięci.

Rysunek 4. Poziomy pamięci podręcznej: Firebird, system operacyjny i pamięć masowa

Jednak jeśli tylko na to spojrzysz, system operacyjny nie pokazuje pamięci przydzielonej do pamięci podręcznej plików jako używanej. Na przykład, oto typowa sytuacja rozkładu pamięci podczas działania serwera Firebird, pokazana przez Menedżera zadań:

Rysunek 5. Menedżer zadań nie pokazuje użycia pamięci podręcznej plików

Wygląda to tak, jakby używane było tylko 6,3 GB z 16 GB.

Jednak jeśli użyjesz narzędzia RAMMap (z SysInternals firmy Microsoft), wszystko wygląda znacznie bardziej logicznie:

Rysunek 6. RAMMap pokazuje szczegóły dotyczące użycia pamięci: zmapowane pliki to buforowane bazy danych

Pliki bazy danych (dbw350.fb252x64.fdb i dbw250.fb252x64.fdb) są buforowane przez system operacyjny i zajmują całą pamięć zadeklarowaną przez Menedżera zadań jako wolną:

Rysunek 7. RAMMap: szczegóły dotyczące użycia pamięci podręcznej plików

Stąd wniosek, że system operacyjny efektywnie wykorzystuje całą dostępną pamięć do buforowania bazy danych, aż do całkowitego załadowania bazy danych do pamięci.

Podsystem Dyskowy

Prawidłowa konfiguracja podsystemu dyskowego odgrywa ważną rolę w wyborze i konfiguracji sprzętu dla Firebird, ponieważ wszelkie błędy na tym etapie spowodują poważne awarie, które są trudne do naprawienia.

Osobne Dyski dla Wszystkiego

Aby zmniejszyć konkurencję o wejście/wyjście dysku między operacjami na pliku bazy danych oraz zmniejszyć ryzyko jednoczesnej utraty bazy danych i kopii zapasowej, zaleca się posiadanie trzech różnych dysków (lub macierzy RAID): jednego dla bazy danych, jednego dla plików tymczasowych i jednego do tworzenia i przechowywania kopii zapasowych.

Kiedy mówimy “osobne dyski”, oznacza to, że strumienie danych muszą przechodzić przez różne kanały wejścia/wyjścia. Jeśli utworzysz trzy dyski logiczne na jednym dysku fizycznym, nie będzie wzrostu wydajności. Jednak jeśli zorganizujesz trzy dyski logiczne na urządzeniu pamięci masowej wyposażonym w kontrolery wielokanałowe, wydajność najprawdopodobniej wzrośnie, ponieważ urządzenie może rozdzielić strumienie danych między kontrolery. Czasami mówi się, że wydzielenie osobnego dysku do przechowywania plików systemu operacyjnego i pliku wymiany systemu operacyjnego zwiększa wydajność.

SSD dla Bazy Danych

SSD to najlepszy wybór do pracy z bazą danych, ponieważ zapewniają doskonałe skalowanie podczas równoległego wejścia/wyjścia. Konieczne jest używanie dysków klasy enterprise ze zwiększoną liczbą cykli odczytu/zapisu, w przeciwnym razie istnieje duże prawdopodobieństwo utraty danych z powodu awarii SSD.

Jakiś czas temu dyski SSD były podatne na zwiększone zużycie, gdy na dysku było mało wolnego miejsca (mniej niż 30%). Mówiąc prosto, każda modyfikacja na SSD jest zapisywana do nowej wolnej komórki, więc brak wolnego miejsca prowadził do zwiększonego zużycia komórek, które pozostały wolne, i do krótszej żywotności dysku.

Producenci nowoczesnych kontrolerów SSD deklarują, że problem ten został rozwiązany poprzez prewencyjne przenoszenie danych statycznych i obecnie zużycie komórek jest mniej więcej wyrównane. Jednak dokładne specyfikacje i algorytmy działania dysków SSD są utrzymywane w tajemnicy przez producentów, dlatego nadal zalecamy pozostawienie 30% wolnego miejsca na dyskach SSD, a także zmniejszenie ich oczekiwanej żywotności i planowanie wymiany nie rzadziej niż raz na trzy lata.

Załóżmy, że rozmiar Twojej bazy danych wynosi obecnie 100 GB i rośnie o 1 GB miesięcznie. W takim przypadku nie należy kupować SSD o minimalnym rozmiarze (120 GB), ale lepiej wybrać kolejne urządzenie w linii produktów - 250 GB. Jednocześnie zakup dysku SSD o pojemności 512 GB będzie marnowaniem pieniędzy, ponieważ zaleca się wymianę dysku po trzech latach.

Najlepszą praktyką jest wydzielenie SSD wyłącznie do pracy z bazą danych, ponieważ wszelkie operacje wejścia/wyjścia skracają żywotność dysków.

Dysk dla Plików Tymczasowych

Ponieważ pliki tymczasowe pojawiają się na dysku tylko wtedy, gdy brakuje ilości RAM, najlepszym sposobem jest oczywiście uniknięcie tej sytuacji. Możliwe jest ocenienie liczby i rozmiaru plików tymczasowych w systemie produkcyjnym tylko poprzez monitorowanie folderu z plikami tymczasowymi. FBDataGuard z pakietu dystrybucyjnego HQbird wykonuje tego rodzaju monitorowanie. Gdy już wiesz, ile tymczasowych plików sortowania jest tworzonych na dysku i kiedy są tworzone, będziesz w stanie zwiększyć ilość RAM i zmienić konfigurację w firebird.conf.

W każdym przypadku Firebird wymaga określenia folderu, w którym będą przechowywane pliki tymczasowe. Zwykle pozostawia się wartość domyślną, tj. używany jest folder systemu operacyjnego dla plików tymczasowych. Jeśli wolnego RAM jest wystarczająco, jest to dobry wybór.

Istnieje jednak kolejna ważna kwestia dotycząca lokalizacji plików tymczasowych na dysku - tworzenie indeksów podczas przywracania zweryfikowanej kopii zapasowej (utworzonej za pomocą narzędzia gbak). Gdy tworzony jest indeks, tworzony jest również plik tymczasowy zawierający wszystkie klucze z tego indeksu. Jeśli baza danych jest dość duża, rozmiar indeksu dla niektórych dużych tabel może być również dość duży. Na przykład indeks największej tabeli zawierającej 3,2 miliarda rekordów w bazie danych o rozmiarze 1 terabajta wynosi 29 GB, ale utworzenie tego indeksu zajęło 180 GB wolnego miejsca:

Aby zapobiec brakowi wolnego miejsca na dysku systemowym, można określić dodatkowy dysk jako dodatkową zarezerwowaną przestrzeń w firebird.conf:

TempDirectories =C:\temp; H:\Temp

Jeśli na pierwszym dysku nie ma miejsca, Firebird będzie kontynuować korzystanie z drugiego dysku dla plików tymczasowych i tak dalej.

HDD dla Kopii Zapasowych

Zwykłe dyski HDD z interfejsem SATA lub nSAS będą odpowiednie do tworzenia i przechowywania kopii zapasowych. Zapewniają szybkie sekwencyjne operacje zapisu i odczytu dla plików kopii zapasowych i są wystarczająco tanie, aby nie oszczędzać na ich rozmiarze i przechowywać kilka kopii zapasowych.

Dyski do kopii zapasowych muszą zawsze mieć dodatkową wolną przestrzeń: rozmiar najnowszej kopii zapasowej + 10%. W takim przypadku możliwe jest utworzenie świeżej kopii zapasowej, upewnienie się, że proces tworzenia kopii zapasowej zakończył się pomyślnie (proces ten może zająć kilka godzin dla bazy danych o rozmiarze kilku terabajtów), a dopiero potem usunięcie poprzedniej kopii zapasowej.

Jeśli usuniesz poprzednią kopię zapasową przed utworzeniem nowej, możliwe jest, że nowa kopia zapasowa nie zostanie utworzona, podczas gdy stara zostanie już usunięta, a baza danych zostanie uszkodzona, na przykład z powodu awarii dysku.

Jeśli używasz zalecanej powyżej metody tworzenia kopii zapasowych (połączenie przyrostowej kopii zapasowej trzypoziomowej i zweryfikowanej kopii zapasowej raz dziennie, przechowując tylko jedną najnowszą kopię), użyj następującego wzoru do obliczenia minimalnego miejsca na kopię zapasową:

Rozmiar_bazy*3+0.2.Rozmiar_bazy

Rozważmy następujące przykładowe obliczenie miejsca niezbędnego do kopii zapasowej:

Załóżmy, że mamy bazę danych o rozmiarze 100 GB, dla której przechowujemy trzypoziomową kopię przyrostową (tydzień-dzień-godzina - po jednej kopii) oraz jedną kopię dziennej zweryfikowanej kopii zapasowej. W takim przypadku kopie zapasowe zajmą następującą przestrzeń:

Nbackup_level_0.weekly - 100 GB
Nbackup_level_1.daily - 5 GB (w przybliżeniu)
Nbackup_level_2.hourly - 200 MB (w przybliżeniu)
Dzienna zweryfikowana kopia zapasowa - 100 GB (w przybliżeniu)
Dodatkowo potrzebujesz zarezerwowanych 110 GB, aby móc utworzyć następną kopię zapasową.

Razem - 316 GB.

! rozmiar pliku przyrostowego pierwszego poziomu lub wyższego zależy od liczby zmodyfikowanych stron od momentu ostatniego uruchomienia nbackup. Rozmiar tych plików można określić tylko eksperymentalnie, ponieważ ilość zmian w bazie danych zależy od aplikacji.

Oczywiście, szacowanie miejsca na kopie zapasowe powinno uwzględniać możliwy nieprawidłowy wzrost rozmiaru bazy danych i odpowiednio zwiększać ilość wolnego miejsca, w przeciwnym razie proces tworzenia kopii zapasowej może zostać nieoczekiwanie przerwany z powodu braku miejsca.

Naturalnie, inteligentne narzędzia do tworzenia kopii zapasowych (FBDataGuard od HQbird) zauważą brak miejsca na kopie zapasowe i wyślą odpowiednią wiadomość do administratora.

Dysk twardy dla bazy danych

Dysk SSD może okazać się zbyt drogim rozwiązaniem lub baza danych może być zbyt duża i konieczne będzie zastosowanie tańszych metod. W takim przypadku należy użyć dysku twardego z interfejsem SAS. Jeśli nie jest to możliwe, użyj dysków SATA z interfejsem nSAS lub najtańszej opcji - zwykłych dysków SATA.

Aby zwiększyć szybkość (a także niezawodność - patrz poniżej) dysków twardych, należy połączyć je w RAID10. RAID10 to połączenie bloków dublowanych (RAID1) i przesyłanych naprzemiennie (RAID0). Dobry i dobrze skonfigurowany kontroler RAID z dużą pamięcią podręczną jest dobrą alternatywą dla dysków SSD.

Niezawodność i RAID

Oczywiście konieczne jest zwiększenie niezawodności podsystemu dyskowego poprzez łączenie dysków w RAID we wszystkich wyżej wymienionych wariantach (z wyjątkiem dysku przeznaczonego wyłącznie na pliki tymczasowe).

• W przypadku dysków SSD upewnij się, że używasz RAID1 - czyli dwóch dublowanych dysków, na które zmiany są zapisywane jednocześnie, co znacznie zmniejsza szanse na utratę wszystkich danych. RAID 10 składający się z dysków SSD będzie najprawdopodobniej zbędny, ponieważ magistrala RAID ograniczy przepustowość. Na przykład interfejs 6 Gbit/s ma przepustowość 600 megabajtów na sekundę, podczas gdy nowoczesne pojedyncze dyski SSD osiągnęły już tę prędkość. W związku z tym otrzymamy ten sam limit 600 MB/s dla RAID 10.

Z wyjątkiem tego, że można użyć PCI Express 3.0 do połączenia dysków SSD w RAID 10, ponieważ przepustowość tej magistrali wynosi już 16 gigabitów na sekundę i więcej.

• Jeśli używasz dysków twardych do celów tworzenia kopii zapasowych, wystarczy RAID1, który zapewni bezpieczeństwo kopii zapasowych oraz akceptowalną prędkość odczytu i zapisu.

• Dyski twarde używane do bazy danych powinny być połączone w RAID10 (co najmniej 4 dyski), co zapewnia optymalne połączenie kosztów, niezawodności i wydajności. Niektórzy użytkownicy używają również RAID5, poświęcając wydajność na rzecz większej przestrzeni.

Konfiguracja RAID dla Firebird

Przede wszystkim należy upewnić się, że w RAID znajduje się prawidłowo naładowana bateria podtrzymująca (BBU). Jeśli takiej baterii nie ma, większość RAID przełącza się w tryb bezpiecznego zapisu (pamięć podręczna dysku jest całkowicie wyłączona), co zapewnia niższą prędkość wejścia/wyjścia niż zwykły dysk SATA!

Ten fakt powoduje większość sfrustrowanych wiadomości do wsparcia technicznego od użytkowników, którzy kupili drogi serwer i odkryli, że działa wolniej niż komputer stacjonarny. Niestety, niektórzy dostawcy nie dołączają baterii domyślnie, dlatego jest to pierwsza rzecz, którą należy sprawdzić i naprawić, jeśli to konieczne.

Następnie należy skonfigurować pamięć podręczną odczytu i zapisu. Często pamięć podręczna jest wyłączona domyślnie i jeśli chcesz, aby RAID działał dość szybko, musisz ją włączyć.

Oprócz włączenia pamięci podręcznej należy sprawdzić, jak działa - może być write through (zapis przez) i write back (zapis wsteczny). Szybkim sposobem pracy z pamięcią podręczną jest write back - w tym przypadku wszelkie zmiany są zapisywane do kontrolera pamięci podręcznej, a po chwili bezpośrednio na dysk.

Możesz użyć narzędzi od producentów dostarczanych z RAID, aby sprawdzić baterię, pamięć podręczną i tryb.

Nowoczesne kontrolery RAID mogą również precyzyjnie dostroić pamięć podręczną - można ją dostosować do ułatwienia odczytu lub zapisu. Zwykle jest podzielona 50%/50% na odczyt i zapis.

Aby dowiedzieć się, jak dokładnie skonfigurować pamięć podręczną, możesz również użyć narzędzia MON$ Logger z zaawansowanego pakietu dystrybucyjnego HQbird. Pokazuje ono proporcję operacji odczytu i zapisu do siebie (zagregowaną od momentu pierwszego połączenia z serwerem):

Rysunek 8. HQbird MON$Logger: proporcja odczytu/zapisu

Jak widać, w tym przykładzie jest znacznie więcej operacji odczytu niż zapisu, więc warto skonfigurować kontroler RAID na 80% operacji odczytu i 20% operacji zapisu.

SAN i bazy danych

Zintegrowane macierze dyskowe stały się ostatnio popularne. Obejmują one elastycznie konfigurowalną macierz dysków (wszystkie typy RAID) z zaawansowanymi funkcjami buforowania. Zazwyczaj SAN mają kilka kontrolerów wejścia/wyjścia, co umożliwia obsługę kilku serwerów jednocześnie i pracę dość szybko.

Wiele organizacji kupuje SAN i używa ich w pracy z bazami danych Firebird. Jeśli SAN jest poprawnie skonfigurowany, można osiągnąć dobrą wydajność. Należy wziąć pod uwagę następujące kwestie, jeśli używasz SAN:

Musi być dostępnych kilka wydajnych kontrolerów dyskowych zapewniających wielokanałową wymianę danych.
Muszą być obecne baterie podtrzymujące (BBU), jeśli są przewidziane konstrukcyjnie.
Dyski bazy danych muszą być połączone w RAID10.
Pamięć podręczna musi być włączona, tryb zapisu musi być przełączony na write back.
Jeśli do SAN podłączonych jest kilka komputerów, każdy z nich musi mieć własny kontroler.
Zainstalowane są najnowsze sterowniki SAN. Spotkaliśmy się z przypadkami, gdy późniejsze sterowniki zapewniały 30% wzrost wydajności.
Jeśli na SAN znajduje się kilka dysków logicznych (dla baz danych, kopii zapasowych, systemu operacyjnego), mają one różne kanały wejścia/wyjścia. Próba użycia jednego kanału dla wszystkich dysków naraz spowoduje niższą wydajność.
Podobnie, jeśli kilka serwerów i baz danych korzysta z SAN w tym samym czasie, wydajność może być niższa z powodu zwiększonej przepustowości kontrolerów wejścia/wyjścia.
Często stosuje się metody łączone - gdy system operacyjny i pliki tymczasowe są przechowywane na dyskach lokalnych, a baza danych i pliki kopii zapasowych na SAN.

Często SAN są używane jako “dwa serwery - jeden SAN” w celu utworzenia klastra odpornego na awarie. Należy zauważyć, że taki klaster może rozwiązać problemy związane tylko z awariami sprzętu na jednym z serwerów, przełączając się natychmiast na drugi serwer. Jeśli problem dotyczy SAN lub samej bazy danych, to rozwiązanie nie pomoże.

Aby zbudować naprawdę odporne na awarie rozwiązanie, należy użyć rozwiązań replikujących dane między dwiema instancjami bazy danych. Możesz skontaktować się z [email protected], aby dowiedzieć się więcej o dostępnych rozwiązaniach dla Firebird.

Krótkie wnioski i zalecenia

Podsumujmy wnioski i zalecenia dotyczące sprzętu dla Firebird.

Procesory wielordzeniowe muszą być używane do obsługi dużej liczby użytkowników.
Minimalna ilość pamięci RAM jest obliczana na podstawie liczby użytkowników i konfiguracji bazy danych, nadmiarowa ilość pamięci RAM będzie efektywnie wykorzystywana przez system operacyjny do buforowania pliku bazy danych.
Używaj oddzielnych dysków dla baz danych, plików tymczasowych i plików kopii zapasowych.
Raczej używaj dysków SSD dla baz danych.
Zarezerwuj co najmniej 30% wolnego miejsca na dyskach SSD.
Wskazane jest poświęcenie dysku dla bazy danych.
Używaj dysków SSD klasy enterprise (z dużą liczbą cykli zapisu/odczytu).
Upewnij się, że używasz RAID.
Dla SSD - RAID 1, dla HDD - RAID10, dla dysków twardych do kopii zapasowych - RAID1. i. SAS, SATA, nSAS
Upewnij się, że bateria RAID jest obecna i naładowana.
Upewnij się, że jest przełączony na write back.
Niektóre kontrolery RAID mają już skonfigurowany rozmiar pamięci podręcznej, na przykład 75% dla odczytu, 25% dla zapisu, lub 50/50 itp. Dlatego konieczne jest zainstalowanie MON$Logger - oprogramowania, które będzie kontrolować parametry RAID, sprawdzać proporcję odczytu/zapisu i zmieniać ustawienia RAID.
Używanie SAN ma swoje zalety i wady. Aby w pełni wykorzystać jego możliwości, należy poprawnie skonfigurować SAN.
Aby zbudować odporne na awarie rozwiązanie, należy użyć rozwiązań z replikami działającymi na różnych serwerach.

Kontakt

Firma IBSurgeon/IBase.ru opracowuje zaawansowany pakiet dystrybucyjny HQbird dla przedsiębiorstw, zapewniając kompleksowe wsparcie techniczne dla Firebird oraz opracowując niestandardowe pakiety dystrybucyjne, a także rozwiązując inne skomplikowane problemy.

IBSurgeon oferuje również usługę optymalizacji Firebird w celu poprawy wydajności baz danych Firebird.

Skontaktuj się z nami: [email protected]