Fórum Root.cz
Hlavní témata => Server => Téma založeno: czechsys 19. 01. 2023, 15:35:50
-
Ahoj,
mam nainstalovane postgresql z apt.postgresql.org. Koukal jsem po jednom padu postgresql, proc automaticky nerestartovala, no protoze dana unita (typ oneshot) od maintenera nema nastavene "Restart" apod. parametry.
Ma nekdo zkusenost s nastavenim napr. podle diskuze na DigitalOcean (https://www.digitalocean.com/community/questions/configuring-postgresql-to-auto-start-after-boot-using-systemd)? Narazilo se pri automatickem restartu na nejake specificke stavy, kdy autorestart zpusobil vetsi problem, nez uzitek?
Diky
-
Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.
-
Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.
Nemám pocit, že by někdo reportoval problémy s automatickým restartem, a přiznám se, že mám pocit, že se to v případě Postgresu ani nijak extra neřeší. Většina restartů je způsobená neodborným zásahem admina (použítím killu) nebo OOM killerem. Může se stát, že se hitne chyba Postgresu (ale to není časté). Ve zmíněných případech by k poškození db dojít nemělo a neslyšel jsem, že by docházelo. Osobně bych se restartu Postgresu nebál, protože co udělá normální admin - zkusí Postgres nastartovat co nejdřív a případnou investigaci nechá na později - nebo bude řešit, pokud Postgres nenastartuje. Dost firem používá dohledové systémy nebo různé stupně HA, které při nedostupnosti Postgresu samy zkusí Postgres nastartovat nebo restartovat. Nevidím moc rozdíl jestli restart udělá systém, HA nebo admin.
Samozřejmě, že po jakémkoliv restartu chce udělat investigaci proč - nemělo by k tomu docházet - a pokud by k tomu docházelo z hw problémů, tak je to průser. Mám pocit, že jsem to za posledních 10 let nezažil. Nějaké nechtěné restarty mohou způsobit chyby v extenzích nebo špatně použité extenze (untrasted languages), ale moc se to neděje. Často používané extenze už jsou poměrně odladěné a prověřené. Dneska se doporučuje zapnout kontrolní součty na datových stránkách (pozor by default jsou vypnuté), a pokud by docházelo k nechtěným restartům, tak je něco špatně a chce to investigovat. K poškození databáze by dojít nemělo, pokud nedojde k poškození filesystému.
U jednoho zákazníka jsem kdysi řešil restarty Postgresu cca 3x za den - zákazník provozoval aplikaci několik měsíců bez poškození databaze, ale s nepříjemnými důsledky na dostupnost. Dodavatel jen doporučil výkonnější hw, což byla samozřejmě blbost. Pak se ukázalo, že dost nešťastně používají untrusted pl perl, a že si nevědomky permanentně rozbíjejí obsluhu jednoho signálu. Dalo se to fixnout během několika minut, když člověk věděl, že jak to funguje a jaké jsou tam souvislosti.
-
Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.
K tomu poškození db by mělo dojít jen výjimečně, pokud dojde k poškození filesystému. Ale je fakt, že pokud admin musí explicitně nahodit db, tak ho to spíš dokope udělat nějakou investigaci. Na druhou stranu drtivá většina adminů tu investigaci stejně neudělá.
-
Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.
K tomu poškození db by mělo dojít jen výjimečně, pokud dojde k poškození filesystému. Ale je fakt, že pokud admin musí explicitně nahodit db, tak ho to spíš dokope udělat nějakou investigaci. Na druhou stranu drtivá většina adminů tu investigaci stejně neudělá.
Bylo to myšleno tak, že pokud dojde k samovolnému pádu databáze (tj. není to tak, že by ji něco odstřelilo), bude nejčastější příčinou chyba někde mimo PostgreSQL, třeba chyba HW – chyba paměti nebo chyba disku. Pokud je chybná paměť nebo disk vrací nesmysly, je docela pravděpodobné, že už máte v DB poškozená data. Pokud tu DB bude provozovat dál, je dost pravděpodobné, že se ty chyby budou dál šířit (např. protože přes vadnou paměť půjdou další data). Nebo aspoň zálohy obsahující chybná data vytlačí zálohy, které tu chybu ještě neměly.
Tj. je nějaká společná příčina (vadný disk, vadná RAM) a způsobí dvě nezávislé věci – poškození dat a pád DB enginu. Pád DB enginu by měl být varováním před tou chybou a je riskantní po tom jen tak znovu spustit databázi, protože pokud ta chyba dokázala jednou něco pokazit, nejspíš bude škodit dál a vedle viditelných pádů DB může neviditelně poškozovat další a další data.
Jinak samotný restart by DB samozřejmě měla přežít bez úhony, je to prakticky stejné, jako když vypadne napájení. Ale jde o to, že DB servery obvykle samy od sebe bez vnější příčiny nepadají.
-
Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.
K tomu poškození db by mělo dojít jen výjimečně, pokud dojde k poškození filesystému. Ale je fakt, že pokud admin musí explicitně nahodit db, tak ho to spíš dokope udělat nějakou investigaci. Na druhou stranu drtivá většina adminů tu investigaci stejně neudělá.
Diky, doufal jsem v komentar od Vas.
V tomto pripade zauradoval OOM killer. Asi do te automatiky pujdeme, poskozeni dat muze vzniknout i nenapadneji, nez restartem atd, od toho mame pak zalohy.
Dotaz na tu datovou integritu - netusite, jaky to ma vykonnostni dopad?
-
Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.
K tomu poškození db by mělo dojít jen výjimečně, pokud dojde k poškození filesystému. Ale je fakt, že pokud admin musí explicitně nahodit db, tak ho to spíš dokope udělat nějakou investigaci. Na druhou stranu drtivá většina adminů tu investigaci stejně neudělá.
Diky, doufal jsem v komentar od Vas.
V tomto pripade zauradoval OOM killer. Asi do te automatiky pujdeme, poskozeni dat muze vzniknout i nenapadneji, nez restartem atd, od toho mame pak zalohy.
Dotaz na tu datovou integritu - netusite, jaky to ma vykonnostni dopad?
Co myslíte datovou integritu? Kontrolní součty na datových stránkách? Na dnešních CPU by to nemělo mít viditelný dopad.
Jinak to, že byl Postgres zabit OOM killerem může znamenat špatnou konfiguraci Postgresu nebo chybějící swap. Nemělo by se to také stávat. U starších verzí byl občas problémový hash aggregate, ale to by od 13 mělo být pořešené.
-
Tak byla to zrovna postgresql 13.
Konfigurace pameti je 4GB ram, 2.5GB swap.
Zmeny v postgresql.conf vs defaulut:
effective_cache_size = 2751MB
effective_io_concurrency = 200
random_page_cost = 1.1
shared_buffers = 982MB
work_mem = 12MB
Out of memory: Killed process 543258 (postgres) total-vm:8059544kB, anon-rss:2024860kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:13904kB oom_score_adj:0
Jan 19 14:13:40 kernel: [1139300.451096] Free swap = 0kB
Jan 19 14:13:40 kernel: [1139300.451097] Total swap = 2670588kB
Jan 19 14:13:40 kernel: [1139300.451098] 1048441 pages RAM
Jan 19 14:13:40 kernel: [1139300.451098] 0 pages HighMem/MovableOnly
Jan 19 14:13:40 kernel: [1139300.451099] 41986 pages reserved
Jan 19 14:13:40 kernel: [1139300.451100] 0 pages hwpoisoned
Ja myslim, ze proste vyvojarum dosla pamet na jejich sql dotazy :)
-
Tak byla to zrovna postgresql 13.
Konfigurace pameti je 4GB ram, 2.5GB swap.
Zmeny v postgresql.conf vs defaulut:
effective_cache_size = 2751MB
effective_io_concurrency = 200
random_page_cost = 1.1
shared_buffers = 982MB
work_mem = 12MB
Out of memory: Killed process 543258 (postgres) total-vm:8059544kB, anon-rss:2024860kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:13904kB oom_score_adj:0
Jan 19 14:13:40 kernel: [1139300.451096] Free swap = 0kB
Jan 19 14:13:40 kernel: [1139300.451097] Total swap = 2670588kB
Jan 19 14:13:40 kernel: [1139300.451098] 1048441 pages RAM
Jan 19 14:13:40 kernel: [1139300.451098] 0 pages HighMem/MovableOnly
Jan 19 14:13:40 kernel: [1139300.451099] 41986 pages reserved
Jan 19 14:13:40 kernel: [1139300.451100] 0 pages hwpoisoned
Ja myslim, ze proste vyvojarum dosla pamet na jejich sql dotazy :)
4GB server se uz moc nevidi :-). Jeste je otazka, jak mate nastavene max_connection?
Postgres - stejně jako všechny ostatní databáze optimalizují dotaz i vůči dostupné paměti, a pokud by potřeboval víc paměti, tak se jede přes dočasné soubory. Takže za normálních okolností by se měl vejít jeden dotaz do nějakého nnasobku work_mem, což je u vás 12 MB. Postgres má hiearchickou správu paměti - dost paměti se uvolňuje při po dopočtu řádku, další po dopočtu dotazu a nakonec prakticky vše se uvolní po dokončení transakce. Je otázkou jak máte velkou db, a co tam vyvádíte.
-
Limit je 100, ale ten vyuzity ani nebyl. Jo, 4GB neni moc, ten server je ale v dev vetvi, takze to zatim nebyl problem. Momentalni obsah je cca 7GB v databazich.
Kdovi, co tam vyvojari najoinovali dohromady a tak :) Zvlast s tim, ze OOM zabil primo postgre, pricemz mel z logiky veci nejdrive zabit netdata. Nj :)
-
Tak se k tomuto vracim.
Vytazek z postgresql@15-main, kde je komentar k automatickemu restartu:
[Service]
Type=forking
# -: ignore startup failure (recovery might take arbitrarily long)
# the actual pg_ctl timeout is configured in pg_ctl.conf
ExecStart=-/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i start
# 0 is the same as infinity, but "infinity" needs systemd 229
TimeoutStartSec=0
ExecStop=/usr/bin/pg_ctlcluster --skip-systemctl-redirect -m fast %i stop
TimeoutStopSec=1h
ExecReload=/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i reload
PIDFile=/run/postgresql/%i.pid
SyslogIdentifier=postgresql@%i
# prevent OOM killer from choosing the postmaster (individual backends will
# reset the score to 0)
OOMScoreAdjust=-900
# restarting automatically will prevent "pg_ctlcluster ... stop" from working,
# so we disable it here. Also, the postmaster will restart by itself on most
# problems anyway, so it is questionable if one wants to enable external
# automatic restarts.
#Restart=on-failure
# (This should make pg_ctlcluster stop work, but doesn't:)
#RestartPreventExitStatus=SIGINT SIGTERM
Mam to chapat tak, ze pokud se nastavi automaticky restart v ramci override, tak prestane fungovat i napr. ExecStop?
-
Mas to prepaleny a nevejdes se do ramek, zacne ti to swapovat a vyteces jak z pameti tak z disku, zacni s necim jako tohle:
effective_cache_size = 2048MB
effective_io_concurrency = 200
random_page_cost = 1.1
shared_buffers = 768MB
work_mem = 12MB
max_connections = 100
“work_mem*max_connections + shared_buffers” <= 80% RAM
Jinak neexistuje universalni rovnice, zalezi co mas za dotazy atd. V zasade, kdyz ti databazovej server swapuje, tak mas neco blbe, bud to mas blbe nastaveny, nebo potrebujes vic ramek nebo jader (popr. obojiho). Tu io_concurrency mas taky pekne prepalenou, ale jak je libo.
-
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.
-
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ů.
-
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.
-
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.
-
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.
-
neviem co chce checksys... minimalne tu swap bych dal na = RAM.
swap by měl být vždy.
-
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.
-
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?
-
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.