Generator postgresql.conf
Rekomendowana konfiguracja PostgreSQL
-
1Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku. -
2Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce. -
3Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.
return "Wynik gotowy w 0.1s";
}
Oceń to narzędzie:
Powiązane narzędzia
Inne narzędzia, które mogą Ci się przydaćGenerator postgresql.conf
Domyślna konfiguracja PostgreSQL jest bardzo zachowawcza — zakłada mały serwer. Na większej maszynie warto dostroić kluczowe parametry, aby baza działała szybciej i stabilniej.
Najważniejsze parametry
| Parametr | Rola |
|---|---|
| shared_buffers | pamięć cache bazy (zwykle 25% RAM) |
| effective_cache_size | szacunek pamięci dostępnej dla cache systemu |
| work_mem | pamięć na operacje sortowania i joinów |
| maintenance_work_mem | pamięć dla VACUUM i tworzenia indeksów |
Zasady doboru
- shared_buffers — 25% RAM (na dedykowanym serwerze).
- effective_cache_size — 75% RAM (to tylko podpowiedź dla planisty).
- work_mem — ostrożnie: mnoży się przez liczbę operacji w zapytaniu i połączeń.
- random_page_cost — 1,1 na SSD, 4,0 na HDD.
Jak generator wylicza wartości
Generator sprowadza konfigurację do dwóch danych wejściowych: ilości pamięci RAM serwera oraz typu nośnika, na którym trzymane są dane. Na tej podstawie wylicza shared_buffers jako 25% RAM, a effective_cache_size jako 75% RAM. Wynik jest zapisywany w składni pliku postgresql.conf, więc można go wkleić bezpośrednio do konfiguracji klastra.
Warto rozróżnić charakter obu parametrów. shared_buffers to realnie przydzielana pamięć współdzielona — po jej zmianie wymagany jest restart serwera. effective_cache_size niczego nie rezerwuje; to jedynie deklaracja dla planisty zapytań, ile pamięci może on zakładać przy szacowaniu kosztu skanowania indeksów i tabel. Zawyżenie tej wartości nie zużyje RAM, ale może skłonić planistę do wyboru gorszych planów.
Pozostałe parametry zależą od charakteru obciążenia, a nie od samego rozmiaru RAM, dlatego generator traktuje je ostrożnie. work_mem mnoży się przez liczbę operacji sortowania i złączeń w zapytaniu oraz przez liczbę równoległych połączeń, więc nie da się go wyliczyć jednym wzorem. Podobnie maintenance_work_mem zależy od rozmiaru bazy i częstotliwości VACUUM. random_page_cost przełącza się między 1,1 dla SSD a 4,0 dla HDD. Wygenerowany plik to punkt startowy, który trzeba zweryfikować na produkcji.
Przykład krok po kroku dla 32 GB RAM
- Przyjmij serwer z 32 GB RAM i dyskiem SSD. Wpisujesz 32 GB jako dostępną pamięć.
- shared_buffers: 32 GB × 0,25 = 8 GB. Tyle pamięci współdzielonej trafi do konfiguracji.
- effective_cache_size: 32 GB × 0,75 = 24 GB. To wartość orientacyjna dla planisty, nie rezerwacja pamięci.
- random_page_cost: dla SSD narzędzie ustawia 1,1. Dla tego samego serwera z HDD byłoby to 4,0.
- Dla porównania maszyna z 16 GB RAM da shared_buffers = 4 GB i effective_cache_size = 12 GB, a z 64 GB — odpowiednio 16 GB i 48 GB.
- Po wklejeniu pliku zrestartuj PostgreSQL (zmiana shared_buffers), a kolejne korekty wprowadzaj pojedynczo i obserwuj ich wpływ na czas zapytań oraz zużycie pamięci.
Tabela referencyjna: RAM a parametry pamięci
| RAM serwera | shared_buffers (25% RAM) | effective_cache_size (75% RAM) |
|---|---|---|
| 4 GB | 1 GB | 3 GB |
| 8 GB | 2 GB | 6 GB |
| 16 GB | 4 GB | 12 GB |
| 32 GB | 8 GB | 24 GB |
| 64 GB | 16 GB | 48 GB |
| 128 GB | 32 GB | 96 GB |
Jak korzystać z wygenerowanej konfiguracji
- Traktuj wynik jako punkt startowy. Procentowe reguły 25% i 75% nie znają Twojego obciążenia; po wdrożeniu porównaj czasy najczęstszych zapytań i realne zużycie pamięci.
- Ustawiaj work_mem na poziomie sesji lub roli. Globalna wysoka wartość mnoży się przez liczbę równoległych sortowań, co łatwo prowadzi do wyczerpania RAM.
- Rozdziel zmiany wymagające restartu od reload. shared_buffers wymaga restartu, więc zaplanuj go w oknie serwisowym; pozostałe korekty wprowadzaj przez reload.
- Nie kopiuj konfiguracji między maszynami o różnym RAM. Plik wygenerowany dla 32 GB da inne wartości niż dla 16 GB; zawsze generuj od nowa dla docelowego serwera.
- Trzymaj plik w kontroli wersji. Zapisuj, kiedy i dlaczego zmieniłeś parametr — ułatwi to diagnozę ewentualnej regresji wydajności.
Ograniczenia narzędzia
- Nie zna profilu obciążenia. Generator nie odróżnia transakcyjnego OLTP od analitycznego OLAP; reguła 25%/75% jest uniwersalnym przybliżeniem, a nie dopasowaniem do konkretnych zapytań.
- Nie modeluje równoległości work_mem. Szczytowy popyt na pamięć zależy od liczby jednoczesnych połączeń i operacji w zapytaniu — tego nie da się wyliczyć z samego rozmiaru RAM.
- Nie uwzględnia innych procesów na serwerze. Jeśli na maszynie działa aplikacja, cache systemowy albo kontenery, pełne 25% i 75% RAM może być zbyt wysokie.
- Nie obejmuje parametrów specyficznych dla wersji. Nowe wydania PostgreSQL dodają własne opcje, a ustawienia zależne od platformy wymagają osobnej analizy.
Najczęstsze pytania
Czy work_mem może być za duży?
Tak — ustawiony zbyt wysoko może wyczerpać pamięć, gdy wiele równoległych zapytań wykona operacje sortowania. Zwiększaj ostrożnie.
Jak sprawdzić efekt zmian?
Włącz rozszerzenie pg_stat_statements i monitoruj najwolniejsze zapytania oraz cache hit ratio (docelowo powyżej 99%).
Czy zmiany wymagają restartu?
Zmiany shared_buffers wymagają restartu. Większość pozostałych można wprowadzić przez reload.
Jak dobrać shared_buffers na VPS z 8 GB RAM?
Zgodnie z regułą 25% wychodzi 2 GB, a effective_cache_size 6 GB. Na serwerze współdzielonym z innymi usługami rozważ niższą wartość i zostaw zapas dla systemu oraz procesów aplikacyjnych.
Czy effective_cache_size rezerwuje pamięć?
Nie. To wyłącznie podpowiedź dla planisty zapytań, ile pamięci może uwzględniać w szacowaniu kosztów. Zbyt wysoka wartość nie zużyje RAM, ale może prowadzić do błędnych planów.
Jaki random_page_cost przyjąć dla dysku NVMe?
Narzędzie rozróżnia tylko SSD (1,1) i HDD (4,0). Dysk NVMe traktuj jak SSD; przy bardzo szybkich odczytach losowych wartość 1,1 jest rozsądnym startem.
Czy wygenerowany plik zadziała na replice?
Reguły są takie same dla każdej instancji, ale replika może mieć inny rozmiar RAM i inny nośnik. Wygeneruj osobny plik dla każdego serwera w klastrze.
Czy generator obsługuje najnowsze wersje PostgreSQL?
Opiera się na parametrach o stabilnej semantyce, obecnych w kolejnych wydaniach. Opcje dodane w konkretnej wersji musisz uzupełnić samodzielnie.