Skalowanie w pionie PostgreSQL

PostgreSQL może dość dobrze skalować się w pionie. Im więcej zasobów (procesora, pamięci, dysku) możesz udostępnić swojemu serwerowi PostgreSQL, tym lepiej może on działać. Jednak podczas gdy niektóre części Postgresa mogą automatycznie korzystać ze zwiększonych zasobów, inne części wymagają zmian w konfiguracji, zanim zostaną zauważone ulepszenia.

Czytaj dalej, aby dowiedzieć się więcej o tym, jak upewnić się, że PostgreSQL w pełni wykorzystuje system, na którym go używasz.

procesor

Co skaluje się automatycznie

PostgreSQL ma tradycyjną architekturę procesów, składającą się z procesu nadrzędnego (zwanego postmaster ), który tworzy nowy proces (nazywanybackendem ) dla każdego nowego połączenia klienta. Oznacza to, że jeśli dostępnych jest więcej rdzeni procesora, więcej procesów może działać jednocześnie, a zatem backendy nie muszą walczyć tak bardzo o dostępność procesora. Zapytania związane z procesorem zakończą się szybciej.

Możesz dostosować maksymalną dozwoloną liczbę jednoczesnych połączeń na poziomie całego systemu, bazy danych lub użytkownika:

-- system level
ALTER SYSTEM SET max_connections = 200;

-- database level
ALTER DATABASE dbname CONNECTION LIMIT 200;

-- user level
ALTER ROLE username CONNECTION LIMIT 20;

aby nieuczciwe aplikacje nie blokowały zbyt wielu połączeń.

Co wymaga poprawienia

Serwer PostgreSQL może odrodzić się proces, aby zająć się zadaniami porządkowymi, takimi jak odkurzanie, replikacja, subskrypcje (dla replikacji logicznej) itp. Liczba takich procesów roboczych nie jest określana dynamicznie, ale po prostu ustawiana w konfiguracji i domyślnie wynosi 8.

Ustawienie konfiguracji najwyższego poziomu dla liczby procesów roboczych to:

# typically specified in postgresql.conf
max_worker_processes = 16

Zwiększenie tej wartości może skutkować przyspieszeniem zadań konserwacji, równoległych zapytań i tworzenia indeksów.

Zapytania równoległe

Począwszy od wersji 9.6, Postgres może wykonywać zapytania równolegle, jeśli queryplanner uzna, że ​​to pomoże. Wykonywanie zapytań równoległych obejmuje tworzenie pracowników, dystrybucję pracy między nimi, a następnie zbieranie (zbieranie) wyników. Z zastrzeżeniem ogólnego limitu max_worker_processes ustawione wcześniej, Postgres określi, ile procesów roboczych może zostać spawnowanych dla zapytań równoległych w zależności od wartości dwóch ustawień konfiguracyjnych:

# the maximum number of workers that the system can
# support for parallel operations
max_parallel_workers = 8

# the maximum number of workers that can be started
# by a single Gather or Gather Merge node
max_parallel_workers_per_gather = 8

Jeśli masz bezczynne procesory i zapytania, które można zrównoleglać, zwiększenie tych wartości może przyspieszyć takie zapytania.

Tworzenie indeksu równoległego

W Postgres 11 dodano obsługę równoległego tworzenia indeksów B-Tree. Jeśli regularnie tworzysz indeksy B-Tree lub REINDEX je, zwiększenie tej wartości może pomóc:

# the maximum number of parallel workers that can be
# started by a single utility command
max_parallel_maintenance_workers = 8

Umożliwi to Postgresowi odrodzenie tak wielu pracowników (z zastrzeżeniem ogólnego limitu max_worker_processes ), aby przyspieszyć tworzenie indeksów B-Tree.

Replikacja logiczna

Replikacja logiczna (dostępna w Postgres 10 i nowszych) opiera się na procesach roboczych po stronie subskrypcji w celu pobierania zmian od wydawcy. Prosząc Postgres o wygenerowanie większej liczby pracowników replikacji logicznej, zmiany mogą być pobierane i stosowane równolegle, zwłaszcza jeśli jest więcej tabel. To ustawienie konfiguracyjne zwiększa całkowitą liczbę pracowników replikacji:

# maximum number of logical replication workers
max_logical_replication_workers = 8

W przypadku replikacji strumieniowej można rozpocząć synchronizację od podstawowej kopii zapasowej. Replikacja forlogiczna jednak zmiany muszą być wprowadzane za pośrednictwem samego protokołu replikacji przez sieć. Może to być czasochłonne. Dopuszczenie większej liczby pracowników w fazie synchronizacji może przyspieszyć ten proces:

# basically the number of tables that are synced in
# parallel during initialization of subscription
max_sync_workers_per_subscription = 8

Autoodkurzacz

Okresowo, w oparciu o szereg ustawień konfiguracyjnych, Postgres będzie uruchamiał mnóstwo pracowników, którzy będą ODKURZAĆ tabele bazy danych. Nazywa się to oczywiście autovacuum, a liczbę robotników odradzających się za każdym razem można ustawić w ustawieniach konfiguracyjnych:

# the maximum number of autovacuum processes
autovacuum_max_workers = 8

Kompresja WAL

Jeśli masz wolny procesor, możesz wymienić procesor na przepustowość dysku, kompresując strony zapisane w plikach WAL. Zmniejsza to ilość danych, które należy zapisać na dysku, kosztem większej liczby cykli procesora w celu skompresowania danych. Zmniejsza również rozmiar danych, które należy przesłać przez sieć w celu strumieniowej replikacji.

Praktycznie korzyści z kompresji WAL są warte bardzo rozsądnych kosztów ogólnych. Aby go włączyć, użyj:

# compresses full page images written to WAL
wal_compression = on

Pamięć

Co skaluje się automatycznie

System operacyjny automatycznie zarządza pamięcią, która nie jest używana przez żadną aplikację, i używa jej do buforowania danych ostatnio odczytanych i zapisanych na dysku. To znacznie przyspiesza aplikacje intensywnie korzystające z dysku, a na pewno PostgreSQL.

W systemie Linux, najpopularniejszym hoście dla Postgresa, rozmiar pamięci podręcznej dysku systemu operacyjnego nie może być ustawiony przez użytkownika. Jego zarządzanie jest wewnętrzne w Linuksie. Pod presją pamięci udostępni aplikacjom pamięć podręczną dysku.

Co wymaga poprawienia

Planer zapytań

Planer zapytań musi uwzględnić ilość pamięci podręcznej dysku dostarczonej przez system operacyjny jako czynnik w swoich szacunkach. Jeśli udało Ci się znacznie zwiększyć pamięć podręczną systemu operacyjnego (poprzez zwiększenie dostępnej pamięci), zwiększenie tego ustawienia konfiguracji może pomóc w poprawie szacunków planisty:

# the planner's assumption about the effective size
# of the disk cache that is available to a single query.
effective_cache_size = 64GB

Współdzielona pamięć

PostgreSQL używa zestawu buforów, które są współdzielone przez wszystkie procesy robocze i procesy zaplecza. Są to tak zwane współdzielone bufory , a ilość pamięci przydzielonej dla buforów współdzielonych jest ustawiana za pomocą ustawienia konfiguracyjnego:

shared_buffers = 32GB

Bufory tymczasowe

Gdy zapytanie uzyskuje dostęp do tabel tymczasowych, bufory są przydzielane do buforowania wczytanej zawartości. Rozmiar tego bufora jest ustawiany za pomocą ustawienia konfiguracyjnego:

# the maximum number of temporary buffers used
# by each database session
temp_buffers = 100MB

Jeśli masz zapas pamięci i zapytania, które intensywnie używają tabel tymczasowych, zwiększenie tej wartości może przyspieszyć takie zapytania.

Pamięć robocza

Pamięć robocza jest przydzielana lokalnie i prywatnie przez backendy. Jest używany do wykonywania sortowań i łączeń bez konieczności tworzenia tabel tymczasowych. Zwiększenie tego z domyślnych 4 MB może przyspieszyć wykonywanie zapytań podczas tworzenia tabel tymczasowych:

# the amount of memory to be used by internal sort
# operations and hash tables before writing to temporary disk files
work_mem = 16MB

Operacje konserwacyjne

Pamięć wykorzystywana przez VACUUM, tworzenie indeksów i inne tego typu polecenia konserwacyjne są kontrolowane przez ustawienie konfiguracyjne maintenance_work_mem . Zwiększenie tej kwoty może przyspieszyć te operacje, zwłaszcza w przypadku indeksów lub tabel, które należy odtworzyć.

Pamięć używana przez pracowników autovacuum może zostać pobrana z pamięci prac konserwacyjnych (poprzez ustawienie autovacuum_work_mem = -1 ) lub skonfigurowane niezależnie.

# the maximum amount of memory to be used by
# maintenance operations
maintenance_work_mem = 128MB

# maximum amount of memory to be used by each
# autovacuum worker process
autovacuum_work_mem = -1

Dysk

Co skaluje się automatycznie

Dyski mogą być większe, szybsze lub bardziej współbieżne. Rozmiar dysku to jedyna rzecz, o której PostgreSQL nie musi być instruowany. Domyślnie PostgreSQL nie ogranicza się do wykorzystania dostępnego miejsca na dysku. Zwykle jest to w porządku.

Możesz jednak ograniczyć całkowity rozmiar tworzonych plików tymczasowych, aby zapewnić pewną ochronę przed zapytaniami, które próbują sortować miliardy wierszy i tym podobne:

# the maximum amount of disk space that a process
# can use for temporary files
temp_file_limit = 500GB

Co wymaga poprawienia

Współbieżność

Dyski RAID i systemy plików, takie jak ZFS, można skonfigurować tak, aby obsługiwały większą współbieżność. To znaczy, możesz mieć kilka odczytów/zapisów na dysku obsługiwanych jednocześnie przez takie systemy plików ze względu na sposób, w jaki przechowują lub obsługują dane wewnętrznie.

Możesz pozwolić Postgresowi na wykonywanie wielu współbieżnych operacji we/wy dysku, korzystając z tego ustawienia konfiguracyjnego:

# the number of concurrent disk I/O operations that
# PostgreSQL expects can be executed simultaneously
effective_io_concurrency = 4

Jest to obecnie używane tylko przez skanowanie sterty bitmap.

Koszt losowej strony

Planer zapytań Postgres zakłada, że ​​odczyty sekwencyjne są szybsze niż odczyty losowe. Dokładnie o ile szybsza jest wartość, którą możesz dostosować. Domyślnie zakłada, że ​​odczyty losowe są 4 razy droższe.

W zależności od konfiguracji dysku, obciążenia i testów porównawczych, jeśli masz pewność, że odczyty losowe są, powiedzmy, tylko dwa razy droższe niż odczyty sekwencyjne, możesz to powiedzieć Postgresowi:

# the planner's estimate of the cost of a disk page
# fetch that is part of a series of sequential fetches
seq_page_cost = 1

# the planner's estimate of the cost of a
# non-sequentially-fetched disk page
random_page_cost = 2

Przestrzenie tabel

Aby skorzystać z wielu dysków, które nie są zamontowane jako jeden duży pojedynczy system plików, możesz użyć przestrzeni tabel. Dzięki przestrzeniom tabel możesz umieszczać tabele lub indeksować różne systemy plików. Może to poprawić współbieżność i zapewnia łatwy sposób obsługi wzrostu tabeli.

CREATE TABLESPACE disk2 LOCATION '/mnt/disk2/postgres';

Przeczytaj więcej o przestrzeniach tabel tutaj.

Sieć

Sieć jest zwykle najmniej używanym zasobem na serwerze PostgreSQL i rzadko jest nasycona. Jeśli potrzebujesz skalować, łatwo jest dodać więcej interfejsów sieciowych, każdy z własnym adresem IP i sprawić, by PostreSQL nasłuchiwał na nich wszystkich:

listen_addresses = '10.1.0.10,10.1.0.11'

Klienci będą musieli być zrównoważeni obciążeniem na wszystkich adresach IP, na których Postgreslists.

Inne

Istnieje kilka innych ustawień konfiguracyjnych, które można dostosować, z których większość zużywa więcej procesora i pamięć.

Operacje na partycjach

W Postgres 10 wprowadzono partycjonowanie tabel, które zostało ulepszone w Postgres 11. Niektóre optymalizacje zapytań na partycjach nie są domyślnie włączone, ponieważ mogą powodować większe zużycie procesora i pamięci. Są to:

# allow a join between partitioned tables to be
# performed by joining the matching partitions
enable_partitionwise_join = on

# allow grouping or aggregation on a partitioned
# tables performed separately for each partition
enable_partitionwise_aggregate = on