Jak obliczyć max_connections dla PostgreSQL i default_pool_size dla pgbouncer?

Czy istnieje przepis lub coś mogę użyć aby obliczyć liczbę biorąc pod uwagę max_connections, default_pool_sizei max_client_conn?

Domyślne są nieparzyste. Domyślnie PostgreSQL to max_connections = 100, a pgbouncer domyślnie to default_pool_size = 20. Czy default_pool_size nie powinien zawsze być wyższy niż max_connections? W przeciwnym razie o co chodzi? Myślałem, że pgbouncer ma na celu umożliwienie obsługi większej liczby połączeń poprzez obniżenie ich obciążenia (poprzez ponowne użycie połączeń PostgreSQL). Jestem zmieszany.

Szukam porad podobnych do tych, które można znaleźć na wiki PostgreSQL , np. „Ten parametr powinien wynosić ~ 50% twojej pamięci”.

Pamiętam, że był arkusz kalkulacyjny dla MySQL, który pozwoliłby ci obliczyć tego rodzaju parametry. Byłoby wspaniale mieć coś takiego dla PostgreSQL / pgbouncer.

Najpierw przeczytaj nasze kanoniczne pytanie dotyczące planowania wydajności .
^{_{Konkretna rada, o którą prosisz, to porada dotycząca planowania zdolności i będziesz musiał ją wypracować samodzielnie dla swojego konkretnego środowiska.}}

Po drugie, patrzysz na to źle.
Ilość pamięci (lub jakiegokolwiek innego zasobu), który posiadasz, nie decyduje o liczbie ustawionych połączeń, liczba potrzebnych połączeń decyduje o tym, jak mocny jest serwer, który musisz kupić.
Wymagania dotyczące zasobów na połączenie są szczegółowo opisane w instrukcji , a także omówione na Wiki, z którą się łączysz. Dowiedz się, czego potrzebuje twoje środowisko (lub zgadnij) i upewnij się, że sprzęt, na którym będziesz działał, poradzi sobie z tym, co zamierzasz w to rzucić.

W szczególności: ograniczenia połączeń i wielkość puli, powinieneś mieć „wystarczającą” liczbę połączeń, aby spełnić wymagania aplikacji - na jednym serwerze lub za pośrednictwem puli / bouncera.

„Wystarczająca” jest liczbą względną: aplikacja, która tworzy (i stale wykorzystuje) jedno połączenie, wymaga tylko jednego połączenia. Aplikacja, która ustanawia połączenie dla każdego zalogowanego użytkownika końcowego, wymaga tylu połączeń DB, ile ma użytkowników.

Domyślne wartości dla obu Postgresów i pgbouncersą rozsądne jako domyślne :

• 100 połączeń z bazą danych to dużo dla typowej osoby wrzucającej Postgres do środowiska.
  Deweloperzy prawdopodobnie nie będą potrzebować więcej niż 10. Każdy inny będzie wiedział wystarczająco dużo, aby zwiększyć liczbę.

• 20 połączeń z pgbouncerjednej puli DB oznacza, że ​​możesz uzyskać 4 pule wskazujące na jeden serwer i nie przekraczać domyślnego limitu połączeń Postgres.
  Możliwe jest posiadanie wielu zasobów w puli pgbouncerwskazujących na jedną bazę danych zaplecza i zawsze chcesz mieć pewne dostępne połączenia na swoich serwerach zaplecza.

Jeśli wartości domyślne nie są odpowiednie dla środowiska, należy je zmienić.

Pamiętaj, że połączenia w puli nie oznaczają „zawsze wiążą wszystkie dostępne połączenia z bazą danych”.
Chodzi o to, pgbouncerjak zauważyłeś, aby ponownie wykorzystać połączenia. Wzrost wydajności tutaj nie wymaga wiązania każdego dostępnego połączenia, a jedynie odłączania, ponownego łączenia, ponownego negocjowania protokołu SSL, ponownego uwierzytelniania w bazie danych i ponownego uruchamiania zapytań dotyczących konfiguracji połączenia za każdym razem.

Zwróć uwagę na definicję dokumentacji dotyczącądefault_pool_size

Ile połączeń serwera zezwala na parę użytkowników / baz danych.

Jeśli więc domyślna konfiguracja ma wielkość puli 20, na 100 połączeń ogółem, oznacza to, że 5 różnych par użytkownik / baza danych będzie musiało określić maksymalną wielkość puli, zanim osiągnie ogólny limit. I odwrotnie, jeśli na przykład używasz pgbouncera do trasy do pojedynczej bazy danych przez jednego użytkownika, efektywny limit połączeń wynosi 20, a nie 100, więc musisz odpowiednio ustawić wielkość puli dla tego przypadku użycia. YMMV.