Jak vypočítat max_connections pro PostgreSQL a default_pool_size pro pgbouncer?

Nejprve si prosím přečtěte naši kanonickou otázku o plánování kapacit.

Za druhé, díváte se na to špatně.
Množství paměti (nebo jakéhokoli jiného zdroje), které máte, neurčuje počet připojení, která nastavíte, počet připojení, která potřebujete určuje, jak silný server musíte zakoupit.
Požadavky na zdroje pro jednotlivá připojení jsou uvedeny v manuálu do značné míry podrobně a také jsou diskutovány na Wiki, na kterou jste odkazovali. Zjistěte, co vaše prostředí potřebuje (nebo proveďte kvalifikovaný odhad) a ujistěte se, že hardware, na kterém budete provozovat, zvládne to, co na něj budete házet.

Konkrétně pokud jde o limity připojení a velikost fondu, měli byste mít „dostatek“ připojení, abyste splnili požadavky vaší aplikace – buď na jediném serveru, nebo prostřednictvím fondu/vyhazovače.

"Dost" je relativní číslo:Aplikace, která vytváří (a neustále znovu používá) jedno připojení, vyžaduje pouze jedno připojení. Aplikace, která naváže připojení pro každého přihlášeného koncového uživatele, vyžaduje tolik připojení k databázi, kolik má uživatelů.

Výchozí hodnoty pro Postgres i pgbouncer jsou rozumné jako výchozí :

• 100 databázových připojení je pro typického člověka, který vrhá Postgres do prostředí, hodně.
  Vývojáři pravděpodobně nebudou potřebovat více než 10. Kdokoli jiný bude vědět dost, aby počet zvýšil.

• 20 připojení z pgbouncer na fond DB znamená, že můžete získat 4 fondy směřující na jeden server a nepřekročit výchozí limit připojení Postgres.
  V pgbouncer je možné mít více sdružených zdrojů ukazující na jednu back-end databázi a vždy chcete nějaká dostupná připojení na vašich back-end serverech.

Pokud je výchozí nejsou vhodné pro vaše prostředí, očekává se, že je změníte.

Pamatujte, že sdružená připojení neznamená "vždy spojit každé dostupné připojení k databázi".
Bod pgbouncer jak jste poznamenali, je znovu použít spojení. Zvýšení efektivity zde nevyžaduje, abyste vázali všechna dostupná připojení, pouze abyste se pokaždé neodpojovali, znovu nepřipojovali, znovu nevyjednávali SSL, znovu se neověřovali v databázi a znovu nespouštěli dotazy na nastavení připojení.