Administrace komentářů

Suhlasim. Ale prave kvoli tomu, aby sa zabranilo swapovaniu a zaroven sa vyuzivalo vsetka dostupna pamat, treba globalne zdroje a zdroje "per session" posudzovat spolu. Odkial je ten 1MB? Hadam, ze je to defaultne nastavenie work_mem? Pokial si pamatam nase projekty, kde sme ladili PostgreSQL/EnterpriseDB, pamat "per session" bola vyrazne vyssia ako 1MB. Ono je dost rozdiel, ci sa napr. taky ORDER BY alebo JOIN urobi v pamati, alebo sa udaje musia presypat cez docastnu tabulku.

Prave EnterpriseDB to ma pekne vyriesene: staci urobit 3 veci:

1) Nastavit dostatocnu velkost shared memory v OS; niektore systemy maju defaultne nastavenie prilis nizke, alebo shared memory vobec nemusia mat. Nasledne zakomentovat shared_buffers v konfiguraku PostgreSQL; by default odkomentovana hodnota ja prilis nizka, aby databaza nastartovala aj na tych OS, ktore maju default limity pre zdielanu pamat nizke.

2) Specifikovat maximalny pocet spojeni; zlate pravidlo je "as many as necessary, as few as possible". Tym sa zabezpeci maximalizacia zdrojov pouzitelnych "per session". A ak sa bavime o nejakom kontajnerovom prostredi, kde sa pristup k databaze riesi cez connection pool-y, je zistenie potrebneho poctu spojeni trivialne.

3) Specifikovat, kolko percent fyzickej pamate sa moze pouzit pre instanciu. Podla toho sa "dopocitaju" globalne zdroje. Opat sa jedna o relativne trivialnu zalezitost, najma pokial ide o dedikovany databazovy stroj.

Podla mojich skusenosti je vysledna konfiguracia v EnterpriseDB velmi dobra, a to prakticky bez roboty.

Uz len dodam pre povodneho opytujuceho sa, ze to, co robi databazovu aplikaciu rychlou alebo pomalou, je zvycajne dobry resp. zly navrh udajovych struktur, nie ladenie cisel v konfiguraku. Ziadne fast=true nastavenie neexistuje.