Automatický restart PostgreSQL

Re:Automatický restart PostgreSQL
« Odpověď #15 kdy: 27. 01. 2023, 18:22:53 »
este by sa mozno oplatilo nastavit naky rozumny statement_timeout. samozrejme po dohovore s developermy.
ono to nejaky cas trva kym sa RAM zaplni ale ked tam na tom experimentuju tak sa to moze stat.

Paměť se i na dnešních velkých serverech zaplnit během několika málo desítek sec. 4GB server tak cca za 3sec. Timeouty nejsou ochranou vůči vyčerpání paměti, ale jsou ochranou proti nechtěnému nadužívání CPU a držení zámků neoptimálně prováděných dotazů.
tak to kazdopadne. ale...
1. potom sa ale nakopne swap a tam uz to tak rychle neni.
2. timouty su ochranou pred long running queries a to okrem CPU vytazuje aj RAM.
3. tazatel riesi development server a nejake sepalenie systemu kvoli nerealistickym queries je viac ako pravdepodobnost.

preto trvam na tom ze ten timeout by predsa len bolo dobre nastavit.

Timeoutem nic nezkazíte - otázkou je kolik? A otázkou je kolik času strávit s laděním konfigurace serveru, kde není hw odpovídající produkci, a kde asi není ani moc dat. V GoodData měl každý vývojář vlastní server ve vlastní virtuální mašině a staral se o něj (rozbíjel si ho) sám. V dev prostředí, pokud nemáte k dispozici slušné železo, a běží to na chcípačích, tak má smysl řešit jedině stabilitu provozu, zvlášť ve sdíleném prostředí. V dev prostředí každý může být super user, a dlouhoběžící dotazy může jednoduše zabít.

Performance testy jsou neskutečně důležité, a dost se podceňují, ale nemá cenu si hrát na bechmarking na poddimenzovaném hw a neadekvátně velkých testovacích datech.


e3k

  • ****
  • 255
    • Zobrazit profil
    • E-mail
Re:Automatický restart PostgreSQL
« Odpověď #16 kdy: 27. 01. 2023, 19:15:29 »
este by sa mozno oplatilo nastavit naky rozumny statement_timeout. samozrejme po dohovore s developermy.
ono to nejaky cas trva kym sa RAM zaplni ale ked tam na tom experimentuju tak sa to moze stat.

Paměť se i na dnešních velkých serverech zaplnit během několika málo desítek sec. 4GB server tak cca za 3sec. Timeouty nejsou ochranou vůči vyčerpání paměti, ale jsou ochranou proti nechtěnému nadužívání CPU a držení zámků neoptimálně prováděných dotazů.
tak to kazdopadne. ale...
1. potom sa ale nakopne swap a tam uz to tak rychle neni.
2. timouty su ochranou pred long running queries a to okrem CPU vytazuje aj RAM.
3. tazatel riesi development server a nejake sepalenie systemu kvoli nerealistickym queries je viac ako pravdepodobnost.

preto trvam na tom ze ten timeout by predsa len bolo dobre nastavit.

Timeoutem nic nezkazíte - otázkou je kolik? A otázkou je kolik času strávit s laděním konfigurace serveru, kde není hw odpovídající produkci, a kde asi není ani moc dat. V GoodData měl každý vývojář vlastní server ve vlastní virtuální mašině a staral se o něj (rozbíjel si ho) sám. V dev prostředí, pokud nemáte k dispozici slušné železo, a běží to na chcípačích, tak má smysl řešit jedině stabilitu provozu, zvlášť ve sdíleném prostředí. V dev prostředí každý může být super user, a dlouhoběžící dotazy může jednoduše zabít.

Performance testy jsou neskutečně důležité, a dost se podceňují, ale nemá cenu si hrát na bechmarking na poddimenzovaném hw a neadekvátně velkých testovacích datech.
neviem co chce checksys... minimalne tu swap bych dal na = RAM.

Re:Automatický restart PostgreSQL
« Odpověď #17 kdy: 27. 01. 2023, 19:50:40 »
neviem co chce checksys... minimalne tu swap bych dal na = RAM.

swap by měl být vždy.

Re:Automatický restart PostgreSQL
« Odpověď #18 kdy: 30. 01. 2023, 12:30:15 »
este by sa mozno oplatilo nastavit naky rozumny statement_timeout. samozrejme po dohovore s developermy.
ono to nejaky cas trva kym sa RAM zaplni ale ked tam na tom experimentuju tak sa to moze stat.

Paměť se i na dnešních velkých serverech zaplnit během několika málo desítek sec. 4GB server tak cca za 3sec. Timeouty nejsou ochranou vůči vyčerpání paměti, ale jsou ochranou proti nechtěnému nadužívání CPU a držení zámků neoptimálně prováděných dotazů.
tak to kazdopadne. ale...
1. potom sa ale nakopne swap a tam uz to tak rychle neni.
2. timouty su ochranou pred long running queries a to okrem CPU vytazuje aj RAM.
3. tazatel riesi development server a nejake sepalenie systemu kvoli nerealistickym queries je viac ako pravdepodobnost.

preto trvam na tom ze ten timeout by predsa len bolo dobre nastavit.

Timeoutem nic nezkazíte - otázkou je kolik? A otázkou je kolik času strávit s laděním konfigurace serveru, kde není hw odpovídající produkci, a kde asi není ani moc dat. V GoodData měl každý vývojář vlastní server ve vlastní virtuální mašině a staral se o něj (rozbíjel si ho) sám. V dev prostředí, pokud nemáte k dispozici slušné železo, a běží to na chcípačích, tak má smysl řešit jedině stabilitu provozu, zvlášť ve sdíleném prostředí. V dev prostředí každý může být super user, a dlouhoběžící dotazy může jednoduše zabít.

Performance testy jsou neskutečně důležité, a dost se podceňují, ale nemá cenu si hrát na bechmarking na poddimenzovaném hw a neadekvátně velkých testovacích datech.
neviem co chce checksys... minimalne tu swap bych dal na = RAM.

On ten swap taky neni zadarmo (storage,backupy, propagace do test/prod tieru atd). Ja ho tam ma jako nouzovku pro vycerpani ram, ale rovnice swap=ram uz davno pozbyla smysl.

Re:Automatický restart PostgreSQL
« Odpověď #19 kdy: 30. 01. 2023, 12:35:30 »
Ale zpatky k otazce - zejmena p. Stehule prosim - mate nejake informace ohledne dopadu automatickeho restartu vzhledem k tomu, co je za komentar v dane systemd service?


Re:Automatický restart PostgreSQL
« Odpověď #20 kdy: 30. 01. 2023, 19:10:28 »
Ale zpatky k otazce - zejmena p. Stehule prosim - mate nejake informace ohledne dopadu automatickeho restartu vzhledem k tomu, co je za komentar v dane systemd service?
Ten komentář se vztahuje patrně k nastavení postgresu (postgresql.conf) restart_after_crash, které na redhatu je v defaultu on. Pokud zrovna není zabitý (nebo havarovaný) postmaster, tak se postgres restartne po havárii libovolného procesu. Pokud je zabitý rodičovský proces, tak tato volba už nezafunguje (a OOM killer může zabít hlavní proces).

Nastavil jsem Restart=on-failure - a systemctl stop funguje naprosto bez problemů. Po killiu postmastera mi systemd nastartoval postmastera automaticky. Myslím si, že ten komentář se může vztahovat na management postavený nad příkazem pg_ctl, což je i debianní skript pg_ctlcluster. S tím že je on-failure tak mi přišlo, že i příkaz pg_ctl stop se chová korektně a podle očekávání. Ale jakmile jsem začal používat pg_ctl tak se mi pid utrhl a i když Postgres běžel, tak o tom systemd nevěděl (jelikož měl jiný pid).

Nejsem expert na debian a jeho skripty pro Postgres jsem se nikdy nenaučil, takže mi může něco uniknout. Teď jsem zkoušel chování na RH, a přišlo mi, že se to chová logicky. Ale aby v tom nebyl zmatek, tak by člověk neměl kombinovat pro nastartování, restart a zastavení Postgresu systemd a pg_ctl (což teoreticky je možné). V systemd pak nebude sedět status.