Názor k článku PostgreSQL 17: pádící slon nezpomalí od Pavel Stěhule - To doporučení vychází z vlastností Postgresu - každý...

To doporučení vychází z vlastností Postgresu - každý připojený uživatel může spustit dotaz, který se začne okamžitě provádět. Ješte u desetinásobku běžících dotazů je zkušenost, že ten server se zpomalí, ale většinou úplně ne patologicky (záleží, co to bude za db). Pokud těch běžících dotazů bude víc, tak se můžete dostat do zátěže, že se k serveru nepřipojíte a budete muset udělat tvrdý reset (což vám může poškodit filesystém (zase v závislosti na kvalitě komponent v IO). Poškozený filesystém znamená, že můžete přijít o data. Jde primárně o to, jak se ten systém bude chovat při přetížení - jestli se nenechá přetížit nebo se utaví.

Realita je široká. Jsou aplikace, kde všechno vám běží s jednou prioritou, a případné čekání connectu ve frontě nic neudělá. Jsou aplikace, kde je to horší. Jsou aplikace, kde to třeba působí problémy, ale když aplikace neběží, tak se vám zastaví byznys, ale nenaskakují penále, a když to není moc často, tak to až tak moc neřeší.

Nedávno jsem viděl problém, který byl asi způsobený krátkodobým kousnutím síťového disku. To by samotné db nevadilo, ten zásek byl cca na 10sec. Větší problém byly Java servery, které si okamžitě otevřely nových 400 spojení - jelikož to bylo sesynchronizované, tak to dalo db docela dobrý kopanec. A pak stejně aplikace umřela jelikož narazila na max_connection. Mám pocit, že pak ještě ty aplikační servery šly do restartu (protože těch 400 spojení bylo alokovaných ale nepoužitých, a další už se vytvořit nedala). Výsledkem byl 10 min výpadek. Primárně způsobený použitím "chytrých" HA technologií.