tuning postgresql dla dużych ilości pamięci RAM

29

Mam dwa identyczne serwery (pod względem sprzętowym), oba są standardowymi instalacjami Windows Server 2008 R2 z minimalnym zainstalowanym oprogramowaniem (w zasadzie mój kod i wymagane rzeczy, takie jak JVM itp.).

Na jednym serwerze działam na serwerze SQL 2005, na drugim serwerze postgresql 9.1. Różnica w wydajności między tymi dwoma serwerami jest oszałamiająca, jest tak zły na postgresql, że żałuję mojej początkowej wypowiedzi „użyjmy postgresql zamiast płacić za licencję serwera SQL” mojemu szefowi. Mówimy o różnicach 30 sekund vs 15 minut dla tego samego polecenia i nie jest to tylko jedno polecenie, to dowolne zapytanie lub polecenie, które na niego rzucam. Oba mają prawie takie same dane (rekordy zostały wstawione w innej kolejności), a obie bazy danych mają dokładnie taką samą strukturę / indeksy itp.

Ale mam nadzieję, że to tylko kwestia strojenia wydajności. Chodzi o to, że serwer sql używa prawie 32 koncertów pamięci RAM na serwerze, podczas gdy postgresl nie używa niczego, zdecydowanie mniej niż koncert, chociaż tak naprawdę tego nie rozgryzłem.

Jak uzyskać postgresql do korzystania z ponad 20 koncertów pamięci RAM? Serwery te zostały zbudowane specjalnie dla tego rodzaju bazy danych, więc moim zdaniem RAM nieużywany przez bazę danych i procesy wspierające.

użytkownik85116
źródło
4
Czy zmieniłeś coś na początkowe strojenie? Krok 1: SET effective_cache_size=18G;(ustawienie domyślne jest bardzo niskie) BTW: zakładając, że jest to maszyna 64-bitowa (bez PTE)
1
Naprawdę nie dajesz nam wystarczająco dużo, aby pomóc. Poza „Powolnym” nie wiemy zbyt wiele o twoim zestawie danych, o tym, jak się do niego uzyskujesz, jakie rodzaje zapytań generalnie działają powoli, co już zrobiłeś, aby dostroić (i być może źle dostroić) serwer. Heck, na maszynie z Linuksem z dużą ilością rdzeni i kanałów pamięci, możesz uzyskać kiepską wydajność na długo przed zainstalowaniem postgresql. Czy jesteś związany procesorem lub IO? Jakie masz inne niż domyślne ustawienia? Jakie zapytania są powolne?
Scott Marlowe
2
Postgres nie „używa barana” tak, jak o nim mówisz. Opiera się on głównie na pamięci podręcznej strony systemu plików systemu operacyjnego, więc gdy oglądasz użycie pamięci RAM w systemie z uruchomionym postgres, zwykle widzisz wiele GB używanych przez bufory / pamięć podręczną systemu operacyjnego, a poszczególne procesy zaplecza postgres używają tylko kilku po kilkadziesiąt MB.
dbenhur
1
Zobacz ten link: tekadempiere.blogspot.ae/2014/09/... I znajdź wartości konf
Sajeev
powiązane pytanie, być może interesujące: stackoverflow.com/questions/47311485/…
wspinacz górski

Odpowiedzi:

41

Istnieje wiele możliwych do dostosowania stałych, zainicjowanych przez postgres.conf. Najważniejsze z nich to:

  • max_connections: liczba jednoczesnych sesji
  • work_mem : maksymalna ilość pamięci do wykorzystania dla wyników pośrednich, takich jak tabele skrótów i do sortowania
  • shared_buffers ilość pamięci poświęconej „przypiętej” przestrzeni buforowej.
  • effective_cache_size ilość pamięci przyjęta do użycia przez bufory LRU systemu operacyjnego.
  • random_page_cost : oszacowanie względnego kosztu poszukiwań dysku.

max_connectionspołączenia nie powinny być wyższe niż potrzebne, połączenia kosztują zasoby, nawet gdy są bezczynne; w większości przypadków połączenie spędziłoby więcej czasu czekając w środku niż czekając na zewnątrz. (w cenie współbieżności) Przyjemną formułą jest „liczba wrzecion + liczba procesorów + X”

work_memjest trudne: można zastosować do każdego podzapytania, więc zapytanie z 5 HASHJOINSmoże kosztować 5 * work_mem. W przypadku najgorszych scenariuszy powinieneś również pomyśleć o tym, że wiele sesji zużywa tę ilość (ponownie powód, aby utrzymać się na max_connectionsniskim poziomie).

shared_buffersjest przereklamowany (IMHO). Zwykle zaleca się ustawienie jej na około 1/4 ... 1/2 całej dostępnej „wolnej” pamięci, ale zazwyczaj utrzymuję ją na niskim poziomie i ustawienie effective_cache_sizecałej dostępnej „wolnej” pamięci.

random_page_costto koszt wyszukiwania + odczytu na dysku. Jest to wartość względna sequential_disk_cost, która wynosi 1. Domyślna wartość (4) dla random_page_costjest ustawiona zbyt wysoko dla nowoczesnych maszyn i pamięci sieciowej, zwykle można ją obniżyć do wartości od 2 do 1.x. W przypadku dysków SSD ustawiono go nawet na 1,0, ponieważ wyszukiwanie jest prawie bezpłatne na dyskach SSD.

wildplasser
źródło
Doskonały! Nigdy nie widziałem znaczenia efektywnego rozmiaru pamięci podręcznej, zawsze oszukiwanego tylko w przypadku współdzielonych buforów. To naprawdę zrobiło ogromną różnicę. Pracuję również z pgtune, który zalecił użycie 20 GB z 96 dla shard_buffers, ale 64 GB dla efektywnego_cache_size. Dzięki!
1
FWIW, przejrzałem te i inne ustawienia sugerowane w dokumentach Postgres i przeprowadziłem analizę dla naszego serwera .
mlissner,
Dziękuję bardzo za odpowiedź. Czy mogę zapytać, jaka work_memjest zalecana wartość max_connectionsdomyślna 100, a pamięć RAM serwera to 32 GB (dedykowany serwer Postgres)? Wiedziałem, że muszę go dostroić na podstawie codziennych zapytań. Zastanawiam się tylko, czy możesz mi powiedzieć, że wartość „jeden rozmiar pasuje do wszystkich odpowiedzi” (lub wartość punktu początkowego). Czy 50 MB jest za duże? Wielkie dzięki.
sgon00
Zależy to od typowej równoległej aktywności na komputerze. 100 sesji, z których każda potrzebuje 50 mln (ponad 10..20 mln), może się zmieścić. Lub może nie. Aby uzyskać wrażenie, monitoruj vmstat lub top. Plus: zależy od twojego zapytania (i innych). Spójrz tylko na plany.
wildplasser
@wildplasser bardzo dziękuję za szybką odpowiedź. Znalazłem ciekawą stronę internetową pgtune.leopard.in.ua . Myślę, że wykorzystam 40 MB jako punkt wyjścia od jego sugestii i dostrojenia na tej podstawie. Twoje zdrowie.
sgon00
20

Rozważ użycie pgtune, aby pomóc dostroić konfigurację PostgreSQL. Od PgFoundry:

pgtune przyjmuje domyślny postgresql.conf i rozszerza serwer bazy danych tak, aby był równie wydajny, jak sprzęt, na którym jest wdrażany

Domyślna konfiguracja PostgreSQL jest bardzo konserwatywna i to narzędzie ma pomóc w tej dokładnej sytuacji. Dokumentacja jest łatwa do odczytania, a korzystanie z narzędzia jest dość proste.

Pamiętaj, że nie ma potrzeby korzystania z dokładnych sugestii pgtune. Grając z jego ustawieniami i obserwując wynikające z tego zmiany w pliku conf, uzyskasz lepsze zrozumienie konfiguracji PostgreSQL i sposobu ręcznej modyfikacji.

Paul Bellora
źródło
8
Ostatnia aktualizacja pgtune miała miejsce w 2009 roku, czyli 5 lat temu i wciąż się liczy. Zastanawiam się, czy nadal obowiązuje dla serii 9.1-9.2-9.3.
sorin
9
pgtune jest już dostępny online
Alfabravo
3

Jeśli każde zapytanie lub polecenie działa powoli, podejrzewam, że:

  • łączysz się z bazą danych dla każdego uruchomionego zapytania;
  • masz skonfigurowaną metodę uwierzytelniania, która nie działa i zatrzymuje zapytania, dopóki ta metoda uwierzytelniania nie przekroczy limitu czasu.

Czy możesz nam powiedzieć, ile czasu zajmuje uruchomienie zapytania select version()? Jeśli powinno być natychmiastowe (0,16 ms na mojej stacji roboczej).

Tometzky
źródło
2

Jeśli KAŻDE zapytanie jest o wiele wolniejsze, coś jest strasznie nie tak z serwerem lub czymś innym. Z mojego doświadczenia wynika, że ​​każda baza danych ma kilka rzeczy, w których jest lepsza od innych, ale pod względem wydajności pgsql jest z łatwością w tej samej dziedzinie co serwer mssql.

Więc na jakim systemie operacyjnym używasz pgsql? Jaki sprzęt? Jakie ustawienia już zmieniłeś? Jak duży jest twój zestaw danych? Jaki jest przykład złej kwerendy i wynik wyjaśnienia analizy (Uruchom kwerendę w następujący sposób:

wyjaśnij analizuj wybierz ... resztę zapytania tutaj ...;

Opublikuj wynik na http://explain.depesz.com/ i opublikuj link tutaj.

Scott Marlowe
źródło
1
Tak, każde zapytanie / polecenie działa wolno i tak „coś” jest strasznie złe, stąd moje pytanie. Problem polega na tym, że mssql w pełni wykorzystuje dostępnego pamięci RAM na serwerze (tak duże buforowanie), podczas gdy psql nie. Doceniam komentarze i porady, ale musiałaś przeoczyć większość mojego pytania i samej linii tematu ... Chcę tylko wiedzieć, jak zdobyć psql, aby korzystać z dostępnego pamięci RAM; obecnie próbuję sugestii wymienionych przez innych ...
user85116
1
Używanie pamięci RAM NIE stanowi problemu. Postgresql polega na systemie operacyjnym, aby wykonać większość buforowania. Tak więc nie trzeba używać całej pamięci RAM. Znowu przegapiłeś większość mojego punktu. Dajesz nam niewiele cennego do pomocy. Prowadzę klastry postgresql 5000 TPS na życie. Możesz posłuchać mojej rady lub myśleć, że wiesz, jak działa pgsql i kłócić się.
Scott Marlowe
@ user85116, proszę usłyszeć Scott, mamy już przepływ pracy z MySQL, który jest zależny od super opóźnień, więc obecnie MySQL używa pamięci RAM 64 GB, aby szybko wykonywać zapytania, podczas gdy to samo można osiągnąć w Postgres 2G z tylko zmaterializowanymi widokami. Buforowanie całej bazy danych do pamięci RAM nie rozwiąże problemu, po prostu czyni go mniej widocznym. Jeśli masz takie same problemy ze strukturą DB, Postgres nie naprawi tego za ciebie ani nie spróbuje go ukryć.
kworr