Konfigurowanie optymalnego środowiska dla PostgreSQL

Witamy w PostgreSQL, potężnym systemie baz danych o otwartym kodzie źródłowym, który może obsługiwać wszystko, od kilku megabajtów danych klientów dla małych firm po setki terabajtów „dużych danych” dla międzynarodowych korporacji. Niezależnie od aplikacji, prawdopodobnie potrzebna będzie pomoc w konfiguracji i konfiguracji, aby przygotować bazę danych do działania.

Po zainstalowaniu nowego serwera ustawienia PostgreSQL są bardzo minimalne, ponieważ są zaprojektowane do działania na jak najmniejszej ilości sprzętu. Jednak bardzo rzadko są one optymalne. Tutaj omówimy podstawową konfigurację dla nowych projektów i jak skonfigurować PostgreSQL, aby działał optymalnie w nowych projektach.

Hosting

Hosting lokalny

W przypadku lokalnej bazy danych najlepszą opcją jest host bare metal, ponieważ maszyny wirtualne generalnie działają wolniej, chyba że mówimy o wysokiej klasy maszynach wirtualnych na poziomie korporacyjnym. Pozwala to również na ściślejszą kontrolę nad konfiguracjami procesora, pamięci i dysków. Wiąże się to jednak z koniecznością posiadania eksperta pod ręką (lub kontraktu) do konserwacji serwera.

Chmura

Hosting bazy danych w chmurze może być pod pewnymi względami cudowny, a pod innymi być koszmarem. O ile wybrana platforma chmurowa nie jest wysoce zoptymalizowana (co generalnie oznacza wyższą cenę), może mieć problemy ze środowiskami o większym obciążeniu. Miej oko na to, czy serwer w chmurze jest współdzielony lub dedykowany (dedykowany, umożliwiając pełną wydajność serwera dla aplikacji), a także poziom IOPS (Operacje wejścia/wyjścia na sekundę) zapewniany przez serwer w chmurze. Kiedy (lub jeśli) aplikacja rozrośnie się do tego stopnia, że ​​większość danych nie może być przechowywana w pamięci, szybkość dostępu do dysku ma kluczowe znaczenie.

Ogólna konfiguracja hosta

Główne filary potrzebne do niezawodnej konfiguracji PostgreSQL opierają się na możliwościach procesora, pamięci i dysku hosta. W zależności od potrzeb aplikacji odpowiedni host, a także dobrze dostrojona konfiguracja PostgreSQL będą miały niesamowity wpływ na wydajność systemu bazodanowego.

Wybór systemu operacyjnego

PostgreSQL można skompilować na większości systemów operacyjnych typu Unix, a także na Windows. Jednak wydajność w systemie Windows nie jest nawet porównywalna z systemem uniksopodobnym, więc jeśli nie jest to mały projekt do wyrzucenia, trzymanie się ustalonego systemu uniksopodobnego będzie drogą do zrobienia. W tej dyskusji będziemy trzymać się systemów opartych na Linuksie.

Pozornie najczęściej używana dystrybucja Linuksa wykorzystywana do hostowania PostgreSQL to system oparty na Red Hat, taki jak CentOS lub Scientific Linux, a nawet sam Red Hat. Ponieważ Red Hat i CentOS koncentrują się na stabilności i wydajności, społeczność stojąca za tymi projektami ciężko pracuje, aby upewnić się, że ważne aplikacje, takie jak bazy danych, są w najbezpieczniejszej i najbardziej niezawodnej wersji systemu Linux.

UWAGA:Linux ma wiele wersji jądra, które nie są optymalne do uruchamiania PostgreSQL, więc zdecydowanie zaleca się ich unikanie, jeśli to możliwe (szczególnie w aplikacjach, w których najważniejsza jest maksymalna wydajność). Benchmarki wykazały, że liczba transakcji na sekundę spada z wersji jądra 3.4 – 3.10, ale poprawia się i znacznie poprawia w wersji jądra 3.12. To niestety wyklucza użycie CentOS 7, jeśli idziesz na trasę CentOS. CentOS 6 jest nadal ważną i obsługiwaną wersją systemu operacyjnego, a CentOS 8 ma zostać wydany, zanim 6 przestanie być obsługiwany.

Instalacja

Instalację można wykonać według źródła lub przy użyciu repozytoriów utrzymywanych przez wybraną dystrybucję Linuksa lub jeszcze lepiej przez PostgreSQL Global Development Group (PGDG), która utrzymuje repozytoria dla systemów opartych na Red Hat (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux i Fedora), a także pakiety dla Debiana i Ubuntu. Korzystanie z pakietów PGDG zapewni, że aktualizacje PostgreSQL będą dostępne do aktualizacji po wydaniu, zamiast czekać na zatwierdzenie i dostarczenie wbudowanych repozytoriów dystrybucji Linuksa.

Procesor

W dzisiejszych czasach nie jest trudno mieć wiele rdzeni dostępnych dla hosta bazy danych. Sam PostgreSQL dopiero niedawno zaczął dodawać możliwości wielowątkowości na poziomie zapytań i będzie się znacznie poprawiał w nadchodzących latach. Ale nawet bez tych nowych i nadchodzących ulepszeń sam PostgreSQL tworzy nowe wątki dla każdego połączenia klienta z bazą danych. Te wątki będą zasadniczo używać rdzenia, gdy będą aktywne, więc liczba wymaganych rdzeni będzie zależeć od poziomu potrzebnych jednoczesnych połączeń i jednoczesnych zapytań.

Dobrym punktem odniesienia na początek jest 4-rdzeniowy system dla małej aplikacji. Zakładając, że aplikacje tańczą między wykonywaniem zapytań a uśpieniem, 4-rdzeniowy system może obsłużyć kilkadziesiąt połączeń, zanim zostanie przeciążony. Dodanie większej liczby rdzeni pomoże skalować wraz ze wzrostem obciążenia. Nie jest niczym niezwykłym, że bardzo duże bazy danych PostgreSQL mają ponad 48 rdzeni do obsługi wielu setek połączeń.

Wskazówki dotyczące strojenia: Nawet jeśli hiperwątkowość jest dostępna, transakcje na sekundę są zazwyczaj wyższe, gdy hiperwątkowość jest wyłączona. W przypadku zapytań do bazy danych, które nie są zbyt złożone, ale mają większą częstotliwość, większa liczba rdzeni jest ważniejsza niż szybsze rdzenie.

Pamięć

Pamięć jest niezwykle ważnym aspektem ogólnej wydajności PostgreSQL. Głównym ustawieniem PostgreSQL pod względem pamięci jest shared_buffers, który jest fragmentem pamięci przydzielonym bezpośrednio do serwera PostgreSQL w celu buforowania danych. Im większe prawdopodobieństwo, że potrzebne dane znajdują się w pamięci, tym szybsze zapytania są zwracane, a szybsze zapytania oznaczają bardziej wydajną konfigurację rdzenia procesora, jak omówiono w poprzedniej sekcji.

Zapytania również czasami potrzebują pamięci do wykonywania operacji sortowania danych przed ich zwróceniem do klienta. To albo wykorzystuje dodatkową pamięć ad-hoc (oddzieloną od shared_buffers), albo pliki tymczasowe na dysku, co jest znacznie wolniejsze.

Wskazówki dotyczące strojenia: Podstawowym punktem wyjścia do ustawienia shared_buffers jest ustawienie go na 1/4 wartości dostępnej pamięci systemowej. Dzięki temu system operacyjny może również wykonywać własne buforowanie danych, a także wszelkie uruchomione procesy inne niż sama baza danych.

Zwiększenie work_mem może przyspieszyć operacje sortowania, jednak zbytnie jego zwiększenie może zmusić hosta do całkowitego wyczerpania pamięci, ponieważ zestaw wartości może być częściowo lub całkowicie przypisywany wiele razy na zapytanie. Jeśli wiele zapytań żąda wielu bloków pamięci do sortowania, może to szybko dodać do większej ilości pamięci niż ta, która jest dostępna na hoście. Utrzymuj ją nisko i powoli podnoś, aż wydajność będzie tam, gdzie chcesz.

Używając polecenia „wolne” (takiego jak „wolne -h”), ustaw Effective_cache_size sumę pamięci, która jest wolna i buforowana. Dzięki temu planista zapytań wie, jaki poziom buforowania systemu operacyjnego może być dostępny, i może uruchamiać lepsze plany zapytań.

Dysk

Wydajność dysku może być jedną z ważniejszych rzeczy, które należy wziąć pod uwagę podczas konfigurowania systemu. Prędkości wejścia/wyjścia są ważne w przypadku dużych obciążeń danych lub pobierania ogromnych ilości danych do przetworzenia. Określa również, jak szybko PostgreSQL może synchronizować pamięć z dyskiem, aby utrzymać optymalną pulę pamięci.

Niektóre przygotowania na dyskach mogą pomóc natychmiast poprawić potencjalną wydajność, a także zabezpieczyć system baz danych w przyszłości pod kątem wzrostu.

• Oddzielne dyski

  Świeża instalacja PostgreSQL utworzy katalog danych klastra gdzieś na głównym (i prawdopodobnie jedynym) dostępnym dysku w systemie.

  Podstawową konfiguracją wykorzystującą więcej dysków byłoby dodanie oddzielnego dysku (lub zestawu dysków przez RAID). Ma tę zaletę, że wszystkie transfery danych związane z bazą danych działają na innym kanale I/O niż główny system operacyjny. Pozwala także na rozwój bazy danych bez obawy, że niewystarczająca ilość miejsca powoduje problemy i błędy w innych miejscach systemu operacyjnego.

  W przypadku baz danych o ekstremalnej aktywności, katalog dziennika transakcji PostgreSQL (xlog) można umieścić na jeszcze innym dysku, oddzielając cięższe operacje we/wy do innego kanału z dala od głównego systemu operacyjnego oraz głównego katalogu danych. Jest to zaawansowana miara, która pomaga wycisnąć większą wydajność z systemu, który w przeciwnym razie może być blisko swoich limitów.

• Korzystanie z RAID

  Skonfigurowanie macierzy RAID dla dysków bazy danych nie tylko chroni przed utratą danych, ale może również poprawić wydajność przy użyciu odpowiedniej konfiguracji RAID. RAID 1 lub 10 są ogólnie uważane za najlepsze, a 10 oferuje parzystość i ogólną szybkość. Jednak RAID 5, chociaż ma wyższy poziom nadmiarowości, cierpi na znaczny spadek wydajności ze względu na sposób, w jaki rozkłada dane na wielu dyskach. Zaplanuj najlepszą dostępną opcję z dużą ilością miejsca na wzrost danych, a będzie to konfiguracja, której nie trzeba będzie często zmieniać, jeśli w ogóle.

• Korzystanie z dysku SSD

  Dyski SSD są doskonałe pod względem wydajności, a jeśli mieszczą się w budżecie, dyski SSD klasy korporacyjnej mogą przyspieszyć intensywne przetwarzanie danych w nocy i w dzień. Mniejsze i średnie bazy danych z mniejszym lub średnim obciążeniem mogą być przesadą, ale w walce o najmniejszy procentowy wzrost w dużych aplikacjach dysk SSD może być tą srebrną kulą.

Wskazówki dotyczące strojenia: Wybierz konfigurację dysku, która jest najlepsza dla danej aplikacji i ma dużo miejsca na rozbudowę wraz ze wzrostem ilości danych.

W przypadku korzystania z dysku SSD ustawienie random_page_cost na 1,5 lub 2 (wartość domyślna to 4) będzie korzystne dla planisty zapytań, ponieważ losowe pobieranie danych jest znacznie szybsze niż na obracających się dyskach.

Ustawienia konfiguracji początkowej

Podczas konfigurowania PostgreSQL po raz pierwszy istnieje kilka ustawień konfiguracyjnych, które można łatwo zmienić w zależności od mocy hosta. Ponieważ aplikacja wysyła zapytania do bazy danych w miarę upływu czasu, można dokonać konkretnego dostrojenia w zależności od potrzeb aplikacji. Będzie to jednak temat na osobny blog poświęcony tuningowi.

Ustawienia pamięci

shared_buffers:Ustaw na 1/4 pamięci systemowej. Jeśli system ma mniej niż 1 GB całkowitej pamięci, ustaw ~ 1/8 całkowitej pamięci systemowej

work_mem:Wartość domyślna to 4 MB, a może nawet wystarczyć na daną aplikację. Ale jeśli pliki tymczasowe są tworzone często, a te pliki są dość małe (dziesiątki megabajtów), warto zwiększyć to ustawienie. Konserwatywnym ustawieniem poziomu podstawowego może być (1/4 pamięć systemowa / max_connections). To ustawienie zależy w dużej mierze od rzeczywistego zachowania i częstotliwości zapytań do bazy danych, dlatego należy je zwiększać ostrożnie. Bądź gotowy, aby zredukować go z powrotem do poprzednich poziomów, jeśli wystąpią problemy.

Effective_cache_size:Ustawia sumę pamięci, która jest wolna i buforowana, zgłaszana przez polecenie „free”.

Ustawienia punktu kontrolnego

Dla PostgreSQL 9.4 i niższych:
segmenty_punktu kontrolnego:Liczba segmentów punktów kontrolnych (każdy po 16 megabajtów), które dają system dziennika zapisu z wyprzedzeniem. Wartość domyślna to 3 i można ją bezpiecznie zwiększyć do 64 nawet dla małych baz danych.

Dla PostgreSQL 9.5 i nowszych:
max_wal_size:To zastąpiło checkpoint_segments jako ustawienie. Wartość domyślna to 1 GB i może pozostać tutaj, dopóki nie będą potrzebne dalsze zmiany.

Bezpieczeństwo

listen_address:To ustawienie określa, na jakich osobistych adresach IP / kartach sieciowych nasłuchiwać połączeń. W prostej konfiguracji prawdopodobnie będzie tylko jedna, podczas gdy bardziej zaawansowane sieci mogą mieć wiele kart do łączenia się z wieloma sieciami. * Oznacza słuchać wszystkiego. Jeśli jednak aplikacja uzyskująca dostęp do bazy danych ma działać na tym samym hoście, co sama baza danych, wystarczy zachować ją jako „localhost”.

Logowanie

Niektóre podstawowe ustawienia rejestrowania, które nie przeciążają dzienników, są następujące.

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0