Příspěvky

61

Server / Re:Automatický restart PostgreSQL

« 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.

62

Server / Re:Automatický restart PostgreSQL

« kdy: 25. 01. 2023, 14:21:11 »

Tak se k tomuto vracim.

Vytazek z postgresql@15-main, kde je komentar k automatickemu restartu:

Kód: [Vybrat]

[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?

63

Server / Re:Automatický restart PostgreSQL

« kdy: 20. 01. 2023, 14:49:31 »

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

64

Server / Re:Automatický restart PostgreSQL

« kdy: 20. 01. 2023, 11:05:29 »

Tak byla to zrovna postgresql 13.

Konfigurace pameti je 4GB ram, 2.5GB swap.
Zmeny v postgresql.conf vs defaulut:

Kód: [Vybrat]

effective_cache_size = 2751MB
effective_io_concurrency = 200
random_page_cost = 1.1
shared_buffers = 982MB
work_mem = 12MB

Kód: [Vybrat]

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

Kód: [Vybrat]

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

65

Server / Re:Automatický restart PostgreSQL

« kdy: 20. 01. 2023, 09:15:35 »

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?

66

Server / Automatický restart PostgreSQL

« kdy: 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? Narazilo se pri automatickem restartu na nejake specificke stavy, kdy autorestart zpusobil vetsi problem, nez uzitek?

Diky

67

Distribuce / Re:Automatické aktualizace PHP v Debianu

« kdy: 17. 01. 2023, 12:12:02 »

Taky se mi to stalo. Jako reseni jsem zvolil nepouzivat php-neco moduly, ale ciste phpVERZE-neco moduly. Pak nevzniknou zavislosti, ktere tahaji i dalsi verze php.

68

Server / Re:Přístup k logům mailserveru

« kdy: 09. 01. 2023, 11:31:50 »

Narazil jsem na problem s predavanim logu do postgresql z rsyslogu.

Od Pg 9.1 je escapování zpětným lomítkem vypnuté. V tom template použij values(E' nebo option.stdsql.

Dik, vyzkousim option.stdsql. Se zdvojovanim ' nemam zkusenosti, tak jsem pouzil to defaultni option.sql.

69

Server / Re:Přístup k logům mailserveru

« kdy: 06. 01. 2023, 16:51:07 »

Narazil jsem na problem s predavanim logu do postgresql z rsyslogu.

mail.log:

Kód: [Vybrat]

Jan  6 00:07:50 SOMEHOST postfix/smtp[462873]: 4Np2F15wZMz1YK: to=<SOMEMAIL>, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=0.92, delays=0.1/0/0.79/0.02, dsn=5.7.1, status=bounced (host eur.olc.protection.outlook.com[104.47.18.161] said: 550 5.7.1 Unfortunately, messages from [SOMEIP] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [AM7EUR06FT064.eop-eur06.prod.protection.outlook.com] (in reply to MAIL FROM command))

postgresql.log:

Kód: [Vybrat]

2023-01-06 00:07:50.778 CET [3445242] USER@DB ERROR:  syntax error at or near "t" at character 390
2023-01-06 00:07:50.778 CET [3445242] USER@DB STATEMENT:  INSERT INTO SOMETABLE (message, timereported) values('Jan  6 00:07:50 SOMEHOST postfix/smtp[462873]: 4Np2F15wZMz1YK: to=<SOMEUSER>, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=0.92, delays=0.1/0/0.79/0.02, dsn=5.7.1, status=bounced (host eur.olc.protection.outlook.com[104.47.18.161] said: 550 5.7.1 Unfortunately, messages from [SOMEIP] weren\'t sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [AM7EUR06FT064.eop-eur06.prod.protection.outlook.com] (in reply to MAIL FROM command))','2023-01-05 23:07:50')

Predpokladam, ze je to zpusobeno

Kód: [Vybrat]

weren't

ktere je v sql dotazu jako

Kód: [Vybrat]

weren\t

.

Jaka je nejlepsi cesta? Funkce na strane postgre? Nejaka extra uprava (jaka?) na strane rsyslogu (viz ta ##postfix konfigurace o prispevek vyse)?

70

Server / Re:Proxmox a VMs si navzájem ovlivňují CPU

« kdy: 06. 01. 2023, 09:08:13 »

2 x fyzický XEON

Takze to shrneme.
Na tech VM se delaji vypocty vyzadujici cpu.
Mame tu 2x26 fyzickych jader, 2x26 htt jader. Tzn 52 fyzickych, 52 htt.
2 bezici VM kazda 30% cpu zatizeni = 64 jader
3 bezici VM kazda 90+% cpu zatizeni = 96 jader

Ani by mne neprekvapilo, ze v takovehle kombinaci by tam byly vysoke cpu steal/context switche, cili poddimenzovany HW ci predimenzovane VM konfigurace.

71

Server / Re:Proxmox a VMs si navzájem ovlivňují CPU

« kdy: 05. 01. 2023, 15:11:21 »

Ma to tedy 2x Xeon nebo 4x? Ten popis neni jednoznacny.

Urcite bych vypnul dynamicke/usporne nastavovani frekvence v biosu.

72

Server / Re:Provoz po HTTPS v produkci

« kdy: 14. 12. 2022, 12:43:14 »

Pro interní komunikaci (aplikace <> brána) používat interní CA a interní ceritifikáty.

A co v pripade, ze se vola aplikacni server mimo cestu skrz branu? To se vypina validace certifikatu?
Priklad:
 1] haproxy (example.com certifikat)
 2] 3x web server (interni certifikat)
 3] zaslani requestu primo na web serveru pro domenu example.com (napr. curl s parameterem --resolve)

73

Server / Re:Provoz po HTTPS v produkci

« kdy: 14. 12. 2022, 12:37:20 »

Manuální obnovování certifikátů je peklo, kvůli kterému jsem v dobách před Let's Encrypt vůbec HTTPS nenasazoval. Vede to k chybám a pokud máte stovky webů, tak se z toho zblázníte. Automatizace je cesta, která to celé řeší stylem „nasaď a zapomeň“. Není potřeba nic vyvíjet, všechno je hotové, připravené k nasazení. Já na produkci používám ACME.sh, nasazení je jednoduché, dá se krásně automatizovat.

To vse je hotove a da se krasne automatizovat funguje tak maximalne, pokud mate dany certifikat na jednom serveru/sluzbe. Co v pripade, kdy certifikat je na X serverech? To uz to nasazeni neni tak jednoduche, ze?

74

Hardware / Megaraid (LSI) řadiče a velikost virtual drive

« kdy: 08. 12. 2022, 16:22:57 »

Ahoj,

nahradili jsme disky v jednom serveru za vetsi a snazime se zvetsit kapacitu daneho pole. Momentalni stav je takovyto:

Kód: [Vybrat]

CLI Version = 007.1506.0000.0000 Aug 11, 2020
Operating system = Linux 4.19.0-0.bpo.19-amd64
Controller = 0
Status = Success
Description = None


EXPANSION INFORMATION :
=====================

-------------------------------------------
VD     Size OCE NoArrExp WithArrExp Status 
-------------------------------------------
 1 2.176 TB N   -        -          -      
-------------------------------------------

OCE - Online Capacity Expansion | WithArrExp - With Array Expansion 
 VD=Virtual Drive | NoArrExp - Without Array Expansion

Kód: [Vybrat]

PD LIST :
=======

----------------------------------------------------------------------------------------------------
EID:Slt DID State DG     Size Intf Med SED PI SeSz Model                                    Sp Type 
----------------------------------------------------------------------------------------------------
98:8     23 Onln   1 3.492 TB NVMe SSD N   N  512B KINGSTON SEDC1500M3840G                  U  -    
98:10    22 Onln   1 3.492 TB NVMe SSD N   N  512B KINGSTON SEDC1500M3840G                  U  -  

EID=Enclosure Device ID|Slt=Slot No.|DID=Device ID|DG=DriveGroup
DHS=Dedicated Hot Spare|UGood=Unconfigured Good|GHS=Global Hotspare
UBad=Unconfigured Bad|Sntze=Sanitize|Onln=Online|Offln=Offline|Intf=Interface
Med=Media Type|SED=Self Encryptive Drive|PI=Protection Info
SeSz=Sector Size|Sp=Spun|U=Up|D=Down|T=Transition|F=Foreign
UGUnsp=UGood Unsupported|UGShld=UGood shielded|HSPShld=Hotspare shielded
CFShld=Configured shielded|Cpybck=CopyBack|CBShld=Copyback Shielded
UBUnsp=UBad Unsupported|Rbld=Rebuild

Kód: [Vybrat]

VD LIST :
=======

-------------------------------------------------------------
DG/VD TYPE  State Access Consist Cache Cac sCC     Size Name 
-------------------------------------------------------------
1/1   RAID1 Optl  RW     No      NRWTD -   ON  2.176 TB      
-------------------------------------------------------------

VD=Virtual Drive| DG=Drive Group|Rec=Recovery
Cac=CacheCade|OfLn=OffLine|Pdgd=Partially Degraded|Dgrd=Degraded
Optl=Optimal|dflt=Default|RO=Read Only|RW=Read Write|HD=Hidden|TRANS=TransportReady|B=Blocked|
Consist=Consistent|R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack|
AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled
Check Consistency

Nemuzu se v online modu dostat pres 2TB. A ted otazka - je na techto radicich VD limitovana na 2TB? Nebo to vyzaduje offline expanzi? Nebo je nutne cele pole shodit a udelat znova?

Jedna se o Megaraid 9460-16i (tri-mode)

Diky

75

Server / Re:Samba nezobrazuje některé soubory

« kdy: 02. 12. 2022, 09:05:04 »

Nefunguje, ale dle ls v souborech není rozdíl:

Kód: [Vybrat]

-rw-rw-rw-    1 nobody   nogroup  475841830 Sep 19  2015 Zobrazuje_se.txt
-rw-rw-rw-    1 nobody   nogroup  367026176 Sep 19  2015 Take_se_zobrazuje.txt

-rw-rw-rw-    1 nobody   nogroup  2333177468 Nov 27 14:20 Nefunguje.txt

Jeden rozdil tam je, ten nefungujici soubor ma o rad vetsi velikost, nemuze to narazet na nejaky limit velikosti souboru?