Súborový systém pre PostgreSQL 14

4.7.2022 12:47 | Přečteno: 2911× | linux | poslední úprava: 6.7.2022 09:46

Chystáme sa nasadzovať nový databázový server PostgreSQL (v14.2) a potreboval som pre neho vybrať súborový systém.

Server dorazil minulý týždeň a po prvotnej inštalácii som začal premýšľať, akým spôsobom súborové systémy vlastne otestovať. Prístup z predošlého článku nevyhovoval, pretože v prípade databázy ide o úplne inú záťaž než file storage. Výsledky dnešného testu túto obavu v plnej miere podporili, ale nepredbiehajme.

Testovací postup

Testoval som takto: nad SW RAID1 z linuxového jadra som najprv vytvoril súborový systém. Ten som pripojil (mount) do adresára /var/lib/postgres a nechal balíčkovací systém (gentoo portage) nakonfigurovať balíček dev-db/postgresql. Všetky parametre som nechal na východzích hodnotách, s týmito výnimkami:

• SW RAID1 z linuxového jadra bol vytvorený s formátom metadát 0.90
• pri BTRFS bol použitý natívny profil RAID1 pre dáta aj metadáta a tým bol nahradený SW RAID1 z linuxového jadra

Takto inicializovanú databázu som spustil a následne do nej importoval zálohu našich interných dát, aby som odmeral rýchlosť importu, až budem server migrovať. Týmto som dostal údaj o počte sekúnd, kde nižšie číslo predstavuje lepší výsledok. Potom prišiel na rad pgbench. V prvej fáze som meral rýchlosť inicializácie s faktorom 10000 (tzn. miliarda riadkov v tabuľke pgbench_accounts). Výsledkom je opäť číslo, počet sekúnd, kde nižšie je lepšie.

pgbench -i pgbench -s 10000 -U postgres

Nakoniec som spustil pgbench s tridsiatimi dvoma klientami po dobu dvoch minút a meral jednak výkon v TPS (Transactions per second, vyššie číslo je lepší výsledok) a priemernú latenciu v milisekundách (nižšia je lepšia).

pgbench -c 32 -j 32 -n -T 120 -r pgbench -U postgres

Tabuľka s výsledkami

Tentoraz nie je potrebné jednotlivým testom dávať váhy, pretože výsledok je beztak očividný. Ako predtým, najlepší a najhorší výsledok majú svoju farbu, výsledky medzi tým sú rozdelené na tie, ktoré sú lepšie než medián a tie, ktoré sú horšie.

 

Update z dňa 6.7.2022: pridaný riadok btrfs+nocow

 

Tentoraz sa nebudem snažiť komentovať všetko, napíšem len to, čo určite stojí za zmienku.

xfs

Súborový systém, ktorý som minule chcel hodiť do koša, tentoraz spravil suverénny comeback. Xfs si viedol vo všetkých týchto testoch najlepšie, i keď niekde len marginálne. Pre PostgreSQL 14 sa xfs javí ako ideálny súborový systém.

btrfs

Naopak, šampión z minula úplne prepadol. PostgreSQL implementuje vlastný copy-on-write, takže keď sa skĺbi so súborovým systémom, ktorý tiež má copy-on-write, výsledkom je copy-on-write na druhú, so všetkými negatívami takejto dupľovanej operácie. Tu sa ukazuje, aké dôležité je poznať svoju záťaž a zohľadniť ju pri výbere súborového systému.

Update z dňa 6.7.2022: v diskusii som bol upozornený, že existuje atribút chattr +C, ktorý potláča copy-on-write. Tento parameter na testy importu a inicializácie pgbench nemal príliš vplyv, ale TPS a priemernú latenciu dokázal oproti východzím hodnotám podstatne zlepšiť. Napriek tomu, btrfs pre účely PostgreSQL 14 zostáva aj s "nocow" výkonnostne v tej horšej polovici súborových systémov.

nilfs2

Logovací súborový systém Nilfs2, ktorý minule naznačoval určitý prísľub, nezvládol opakované prepisy. Časté zmeny, ktoré si databázová záťaž vyžaduje, čoskoro zaplnili celý disk a nilfs2 v jednom momente jednoducho nechal databázu spadnúť s tým, že požadovaný zápis už nevykoná. Bol schopný dokončiť aspoň úvodný import, ale aj v tom bol významne pomalší než všetky ostatné súborové systémy. Očakávam, že ak by bol schopný tento test dokončiť, bol by v ňom ešte pomalší než btrfs.

ext4

Tak ako minule, aj tento test ukázal vyváženosť a všestrannosť súborového systému ext4. Ak aj v niečom nie je najrýchlejší, väčšinou výkonom nie je od toho najlepšieho ďaleko. Nemá výrazné slabiny, nerobí mu problém databáza, ani úložisko súborov. Ak nad tým nechcete premýšľať a nebojíte sa bit rot-u, ext4 zostáva dobrou východzou voľbou.

V ďalšom dieli uvidíte...

Najbližšie pre Vás chystám test key-value databáz. Okrem tradičných DB4, gdbm, Memcached, či Redisu, sa pokúsime na účely key-value úložiska ohnúť aj SQLite, MongoDB, či MariaDB. Už teraz je zaručené, že zase niekomu stúpim na otlak.

 

 

 

 

 

Použitý hardvér

Lenovo ThinkSystem SR630 v konfigurácii:

• 1x CPU Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz (16 jadier + HT)
• 2x RAM 64GB DDR4 ECC buffered
• radič Adaptec Smart Storage PQI SAS
• 2x SSD Seagate Nytro 3732 800GB

Použitý softvér

Čistá inštalácia Gentoo linux s týmito verziami relevantných balíčkov:

• dev-db/postgresql-14.2-r1
• sys-fs/btrfs-progs-5.15.1
• sys-fs/f2fs-tools-1.14.0
• sys-fs/jfsutils-1.1.15-r1
• sys-fs/mdadm-4.1
• sys-fs/nilfs-utils-2.2.2-r1
• sys-fs/reiserfsprogs-3.6.27-r1
• sys-fs/xfsprogs-5.14.2
• sys-kernel/gentoo-sources-5.15.41

       

Komentáře

[Max]

Zajímavá snaha. Pokud ale chceš dělat test pro konkrétní nasazení, tak default options je to, co člověk nechce a tím pádem takový test nemá smysl.
Každopádně můj názor je takový, že kdo nechce, nebo nemůže použít btrfs, ten by měl použít XFS. Ostatní FS pak patří do archivu.
Zdar Max

[AraxoN]

Existuje v prípade btrfs spôsob, ako ho vyladiť pre postgres? Môžem to ešte skúsiť a doplniť...

[Max]

Myslím, že nodatacow se dá u btrfs použít nad určitou složkou s daty. Na zbytek FS pak bude CoW + snapshoty půjdou dělat také (četl jsem, že se jednorázově provede při tvorbě snapshotu CoW), tím pádem by výkonnostní impact neměl být tak velký a některé výhody btrfs stále ještě budou s nodatacow fungovat.
Zdar Max

[Max]

Ještě doplním, že nejlépe by ti asi odpověděl Heron. A to nemyslím jen ohledně btrfs, ale i ohledně jiných fs ve spolupráci s Postrgresem.
Zdar Max

[AraxoN]

To znie rozumne, vyskúšam to a doplním do blogu.

[a1bert]

chattr +C

[AraxoN]

Doplnil som aj test btrfs+nocow, ale naďalej to pre btrfs nevyzerá priaznivo.

[Zaphod]

Pozri na testy. Dobrý, aj keď starší test.

[čavo]

Z iného súdka. Doporučoval by som hneď tam dať Postgresql 14.4, od 14.0, po 14.3 je tam chyba v generovaní indexov.

https://www.postgresql.org/about/news/postgresql-144-released-2470/

https://www.migops.com/blog/important-postgresql-14-update-to-avoid-silent-corruption-of-indexes/

[AraxoN]

Vďaka za upozornenie. Po zbežnom preskúmaní to chápem tak, že problém je len pri budovaní indexu za použitia kľúčového slova "CONCURRENTLY". To nie je náš prípad.

PostgreSQL 14.4 je zatiaľ v Gentoo len v stave testing, nie stable. V ostrom nasadení mi ide predovšetkým o stabilitu, takže ak by to bolo nutné, radšej by som išiel do 13.x, než do testing balíčka. Ale zdá sa, že nás sa tento bug netýka.

[skajrajdr]

Sorry ze kibicuju, ale podle me je ten test k nicemu. Teda takhle, je dobry pro toho, kdo provozuje defaultne nastavenou postgres databazi a dela presne to, co pgbench. Jenze ten fakt nepotrebuje resit filesystem ...

Co tim chci rict - vykonnost postgres je strasne zavisla na tom, co s nim planuju delat a jak ho nakonfiguruji. Teprve pak ma vubec smysl resit filesystem pod nim. Spravnou konfiguraci se da vykonnost (nekdy) ovlivnit i nasobne bez ohledu na to, co pod nim bezi...

[AraxoN]

Tak samozrejme, že do ostrého nasadenia ešte pár parametrov upravím. Ale dovolím si namietať, že test nie je k ničomu. Minimálne z neho vidno, že výber súborového systému má vplyv (aj) na výkonnosť PostgreSQL. Samozrejme, na rôznu záťaž ten vplyv bude rôzne veľký, ale nečakám, že by sa od trendov v tomto teste líšil diametrálne.

[skajrajdr]

No to prave klidne bude diametralni. Protoze hrozne bude zalezet na pomeru realneho hrabani na disk, a zda jen cteni nebo zapisu. Uplne v klidu to pro produkcni nasazeni vyhraje jiny filesystem.

Tak tady se testuje worst case - tj. vzdy hodne zapisu a hodne cteni a to oboji naraz. Takze produkce neprodukce, tenhle test ukaze "kam az" se (jakakoliv) produkce dostane pokud tam vyvojari najednou pridaji nejaky chat ci notifikace ci logovani atd.

Proto se tenhle blog nejmenuje "chovani postgres v produkci nad ruznymi fs", nybr "test fs pro postgres".

[skajrajdr]

... tenhle test ukaze "kam az" se (jakakoliv) produkce dostane pokud tam vyvojari najednou pridaji nejaky chat ci notifikace ci logovani atd.

Sorry, tohle a i zbytek proste neni pravda. Pokud nekdo potrebuje resit postgres na produkci na urovni filesystemu (absolutni marginal gains), tak ...

1. uz davno ma dobre nastavene table spaces
2. ma dobre nastavene cache a hit rates
3. ma vyreseny clustering dat
4. ... (sorry, jsem linej dalsi parametry a techniky)

Jinymi slovy uz vyresil veci, kterymi muze z postgres dostat nasobky vykonu. Pak muze zacit dumat nad filesystemem pro tech poslednich par procent vykonu v zavislosti treba na tablespace a jeho typickem pouziti (jiny pro index a jiny pro masivni zapis). A ten konkretni nejlepsi filesystem muze zrovna v obecnych testech byt horsi.

Protoze pro obecne pouziti nedava vubec smysl s necim takovym jako specialni filesystem sachovat. Tam at si vybere admin co je mu nejblizsi a bude se nejlepe spravovat. To prevazi uplne vsechny ostatni aspekty.

Ano, to co pises plati pro specialni pripad provozu PostreSQL kdy jsou splneny obe nasledujici podminky:

1. mam jednu (ano, jednu) aplikaci (nebo soubor vzajemne velmi podobnych aplikaci)

2. tato aplikace je svym I/O chovanim docela uzce zamerena

A ano, mnohe produkcni systemy to takhle maji (tzn. jedou mnoho ruzne nastavenych instanci PostgreSQL - kazdou pro jinou aplikaci). Ale osobne znam vetsi mnozstvi produkcnich systemu, kdy tyto obe podminky nejsou splneny a jede se jedna instance PostgreSQL a ta musi resit worst case.

[MP]

The Worst case ale v drtive vetsine neni vykon fs jako takoveho, ale uzke hrdlo jsou vetsinou disky nebo nastaveni db neodpovidajici provozovane aplikaci (za coz casto muzou vyvojari)...

[skajrajdr]

Bingo, skvele jsi popsal pripady, kdy ma smysl resit filesystem pod Postgres, protoze zdimu posledni procenta vykonu pro specialni uziti. (a ve kterych ma smysl sit na miri filesystem designovane zatezi)

V jinem pripade filesystem smysl resit nema (ostatni aspekty provozu filesystemu prevazuji nad jeho teoreticky marginalne lepsi vykonnosti), tedy test nedava smysl. A je jen takovym teoretickym cvicenim. Protoze rozumny admin si na server soupne neco, co dobre umi (on a jeho team) a zapada do zbytku ekosystemu...

[okbobcz]

Pro všechny syntetické testy platí, že jimi generovaná zátěž téměř nepodobá skutečné zátěži. Přesto mají svůj smysl.

Namátkou - výkonnostní porovnání hw, případně verzí Postgresu. Normalizovaná zátěž docela dost pomáhá s identifikací hrdel. Nastavuje měřítka, kterých se můžete chytit.

U mého posledního nejmenovaného zákazníka kvůli neoptimálně nastavené virtualizaci docházelo ke kolapsu výkonu IO. Díky pgbenchi šlo docela jednoduše porovnat výkon v různých konfiguracích. Pro vlastní aplikaci zákazník ani neměl podobný test. Syntetické testy nemá cenu přeceňovat, ale nemá cenu je také úplně zatracovat. Pomocí syntetických testů můžete jednoduše simulovat a sledovat chování systému při hraničních situací. V praxi opravdu nebudu chtít, aby se mi systém vůbec do takovéto situace dostal. Nicméně dostat se vám tam může - a pak může být výhodou, když podobnou situaci máte otestovanou, a víte, že to Váš systém ještě dává.

V praxi se vám může pseudo náhodně spustit VACUUM FREEZE nad velkou tabulkou - a pak máte i v reálném provozu zátěž hodně podobnou tomu, co vygeneruje pgbench.

[skajrajdr]

Az na to, ze ty pises o obecnem smyslu syntetickych testu, o testovani Postgres atd. V tom bych toho moc nerozporoval.

Jenze autor si timhle syntetickym testem vybira filesystem pro Postgres. Viz:

Chystáme sa nasadzovať nový databázový server PostgreSQL (v14.2) a potreboval som pre neho vybrať súborový systém.

A tam uz plati, to co jsem napsal vyse - cely tenhle test nedava vubec smysl. Pro realne nasazeni s potrebou zdimat filesystem muze byt vsechno uplne jinak dle daneho uziti (jinymi slovy - tenhle test o nem nerika vubec nic). A pokud potreba zdimat Postgres na absolutni hranu neni, tak vubec nema smysl tohle testovat - nasadit se ma filesystem podle uplne jinych kriterii nez marginal gains Postgres/filesystem.

[okbobcz]

Jasně, ale když není čeho se chytit, tak se snažíš chytit alespoň něčeho. Minimálně ti to může dát signál, že někde něco smrdí. Napsat dobrý test je dost pracné, a čím ten test je komplexnější a věrohodnější, tak je pracnější ho interpretovat. Navíc ty výsledky závisí na kontextu. Pokud se ten test nezopakuje na jiném železe, tak se nedá z jistotou říct nakolik ten výsledek platí pro konkrétní železo a nakolik je obecný. Je fakt, že asi kdybych chtěl otestovat filesystém, tak sáhnu po specializovaném benchmarku jako bonie++, ale stejně může mít smysl pgbench, který specificky při write vynucuje fsync. Dost lidí ani netuší, jak funguje databáze, a těžko by něco nějak simulovali.

[skajrajdr]

No k cemu je dobre se chytat neceho co je uplne nevypovidajici pro moje uziti nevim... Tak mozna aby me to vic zmatlo, az budu resit realny problem:)

Promin, porad popisujes obecnou realitu nejakych syntetickych testu, ale unika ti to hlavni - autor si myslel, ze udelal test na vyber vhodneho filesystemu pro Postgres. Neudelal. Ten test neni dobry. Neni vypovidajici. Nemel by si podle nej vybrat filesystem. Neplni to, co si stanovil jako vstupni podminku (neodpovida na to, ktery filesystem je vhodny) Proc? To uz bych se opakoval...

[AraxoN]

Počuj, čo keby si prestal hovoriť mojím menom? Test splnil podmienky, ktoré som na neho kládol. Ukázalo sa, že pre univerzálne použitie je naďalej najlepšou voľbou ext4. Aká bude v budúcnosti záťaž na databázový server vie len Pán Boh, takže pgbench mi príde ako dostatočná aproximácia.

Keď so mnou nesúhlasíš, napíš vlastný blog. Navrhni vlastnú metodiku, ukáž nám ju. Doteraz som sa od Teba nedozvedel nič prínosné. Nič v zlom, ale toto nikam nevedie.

[skajrajdr]

Sorry, ale ja nemluvim tvym jmenem - to nevim kdes sebral. Nic takoveho jsem ani naznakem neudelal. Jen kritizuji to co jsi sepsal, protoze - viz vyse - ten test neplni to, co jsi myslel ze plni.

Pokud jsi kritiku nepochopil a nic noveho ses nedozvedel, je mi to sice lito, ale neumim s tim nic lepsiho udelat. Zduvodneni je tam nekolikrat. Klic lezi v tom, ze chyba neni v metodice testu, ale rovnou ve tve prvotni uvaze o zpusobu jak vybrat optimalni filesystem pro Postgres.

Chapu, ze se te kritika dotkla, ale tak to holt v diskuzich chodi. Nebyla nijak podla ani sprosta. I proto nevidim duvod, proc bych mel psat vlastni blog, kdyz v tom tvem je napsany nesmysl.

[Margzen]

Vždyť i postgresí initdb řve, že na btrfs musíš na jeho data dir nastavit chattr +C, jinak to bude katastrofa.

[AraxoN]

initdb řve

Zjavne nie dosť nahlas!

Ale vážne, nikde to tam nevidím. Nič také mi initdb nepíše:

postgres@hades ~ $ initdb -D ~/14/data -E UTF8
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "C.UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /var/lib/postgresql/14/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Europe/Prague
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    pg_ctl -D /var/lib/postgresql/14/data -l logfile start

[Boo]

Niekde som cital ze XFS v kombinacii s Postgresom moze dojst k strate dat pre nestandardny handling fsync. Takze radsej chod na istotu s ext4

[AraxoN]

Ja sa tiež kloním skôr k ext4 ako konzervatívnej, rokmi oskúšanej voľbe. XFS sľubuje len marginálne zisky, ale potenciálne nepredvídané problémy.

[kralyk z abclinuxu]

Zajímavost: PureStorage dopočuruje XFS na jejich FlashArray (byť na druhém místě ext4 taky).

Osobně mi XFS přijde jako asi konzervativnější volba než ext4...

[Max]

Těžko může být konzervativnější volba, když XFS patří mezi tři nejvyvíjenější filesystémy současnosti, kam padá od Redhatu hafec změn.
Největší vývoj je kolem btrfs, zfs on linux a xfs.
Např. reflink přišel do xfs s kernelem 4.9, taktéž se čas od času mění formát fs, aktuálně je ve verzi 5 (přinesl např. XFS Self Describing Metadata).
Zdar Max

[jemi 15nact]

offtopic ale mam takovej filozofickej dotaz kdyz mate cisty kernel jak na tom neco zkompilujete? nemate cc, gcc a podobne a nemuzete je nainstalovat protoze nemate to udelatko. Neni to paradox vejce slepice?

[Metuselach]

Neni. Prvni prekladac se naderoval rucne v strojaku na derne stitky a pak to uz byla evoluce.

[kralyk z abclinuxu]

offtopic ale mam takovej filozofickej dotaz kdyz mate cisty kernel jak na tom neco zkompilujete? nemate cc, gcc a podobne a nemuzete je nainstalovat protoze nemate to udelatko. Neni to paradox vejce slepice?

Bootstrapping

[cbrpnk]

chyba mi tam test iba v RAM nad tmpfs

[AraxoN]

Bohužiaľ, databáza v tomto prípade je väčšia než RAM.

[AraxoN]

Koho by to zaujímalo, celý týždeň som skúšal rôzne kombinácie nastavení za účelom zvýšenia dosiahnutých čísel. Nakoniec som dospel k tejto sade, ktorá vykazovala najlepšie zlepšenie vo všetkých týchto testovaných hodnotách na tomto konkrétnom serveri so 128GB RAM a 2x SAS SSD:

# pre 2x SAS SSD
effective_io_concurrency = 4
random_page_cost = 1

# pre 128GB RAM
effective_cache_size = 64GB
shared_buffers = 32GB

Zmeny ostatných parametrov (work_mem, maintenance_work_mem, ...), prinajmenšom v týchto testoch, výkon skôr zhoršovali.

S touto kombináciou som dosiahol zrýchlenie okolo 4% pri importe a pgbench init a 16% v TPS a avg. latency. Rozhodne som výberom správneho súborového systému získal viac výkonu, než ladením parametrov.

To ukazuje, že východzie hodnoty sú nastavené veľmi dobre.

[trekker.dk]

To, co se vám tady někteří opakovaně pokoušejí říct, je, že jste výběrem správného souborového systému získal víc výkonu pro pgbench. O tom, jestli jste získal víc výkonu pro tu aplikaci, která vám tam bude běžet, pořád nevíte vůbec nic.

[AraxoN]

Ten databázový server nie je len pre jednu aplikáciu. Staršie aplikácie končia, nové sa nasadzujú, naozaj je vo hviezdach, čo bude o pol roka. Pgbench je nejaký mix, ktorý má aspoň tú výhodu, že je opakovateľný a nemenný, takže to je jediný pevný bod, o ktorý sa dá oprieť.

[okbobcz]

Tak zrovna tyhle hodnoty bych do produkce nedával (mohou zafungovat s pgbenchem). random_page_cost by mělo být vždy větší než seq_page_cost, a pokud máte shared_buffers větší než 10-15GB tak je dobré zvýšit agresivitu background writeru. Pro reálnou aplikaci - pgbench generuje jenom jednoduché selecty a jednoduché updates je potřeba si pohrát s nastavením work_mem, a samozřejmě mít všude indexy, kde jsou potřeba - dost pomůže extenze pg_stat_statements - podívejte se na prováděcí plány častých nebo pomalých dotazů.

U reálné aplikace, která pouští joiny, agregace, sorty (nic z toho pgbench nedělá) vám mnohem víc pomůže nastavení work_mem, a správné indexy než cokoliv jiného.

[AraxoN]

Indexy samozrejme sú, pomalé dotazy logujeme a spracovávame cez pgfouine. Nastavenia našich postgresových serverov ladím podľa svojich poznámok z P2D2 (aj z Vašich prednášok).

Toto je prvýkrát, čo som na to mal dosť času a robil pred nasadením aj nejaké syntetické testy. Trochu ma prekvapilo, že na pgbench nemali veci ako maintenance_work_mem vplyv, ale vďaka Vašej odpovedi konečne aspoň tuším prečo.

Idem z pgfouine povyťahovať nejaké najobludnejšie dotazy z reálnej prevádzky a prehnať ich cez rôzne nastavenia. Bohužiaľ, čas sa mi kráti a čoskoro to potrebujem dať do produkcie.

[AraxoN]

pardon, nie pgfouine, teraz tam máme pgbadger...

[okbobcz]

Doporučuji udělat základní nastavení max_connection, work_mem, maintainance_work_mem, možná effective_cache_size, a pokud máte ssd, tak zredukovat random_page_cost. Zbytek pak doladit podle provozu, nebo pokud by se vyskytlo něco fatálního. Provoz databáze je dost dynamický systém - rychlost dotazů ovlivňuje i souběh dotazů, obsah cache, a mám zkušenost, že Postgres není až tak moc citlivý na konfiguraci. Důležité je aby VACUUM vakuovalo, a ANALYZE analyzovalo, a ty indexy. Na větších datech dost často chybějí vícesloupcové indexy. A to vypadne z toho reálného provozu. A pokud se vám podaří redukovat zbytečnou zátěž, tak většinou pak máte dost výkonu na cokoliv.

Syntetickým testům se rozhodně nebráním - mohou vám pomoct identifikovat problémy s hw, a zahořet hw. Pro finální tuning už pak nemají smysl. Předprodukční konfiguraci také moc neřeším. Databáze se dost mění - za rok někde máte 2x tolik dat, a trochu jiný typ provozu, a za 2 roky zas třeba jiné železo. Co pokládám za nejdůležitější je doladění během prvních pár dnů (týdnů) produkce, kdy už jsou vidět skutečná hrdla - je nutné přidat pár indexů, přepsat pár dotazů, a pak už to většinou jede parádně.

[AraxoN]

V tomto prípade ide o upgrade PG servera, takže indexy a dotazy v nejakej ako-tak optimálnej forme už fungujú. Nový server sa stane masterom, z pôvodného master sa stane nový standby, starý standby poslúži ako nový devel a starý devel sa vyradí. Takto servery priebežne otáčame každých pár rokov, len predtým som na to nemal toľko času, takže som sa s výberom fs a nastaveniami príliš nehral.

K tomu záveru, že PG nie je až tak citlivý na konfiguráciu, som došiel aj ja.

Vybral som medzitým pár veľkých dotazov z pgbadgeru a vyzerá to tak, že tento nový server bude vďaka SSD rádovo rýchlejší než ten starý. Takže o celkový výkon v reále nemám žiadne obavy.

[MP]

To by me zajimalo, proc menit background writer pri tech shared_buffers >10-15GB?

[okbobcz]

Tam hodně záleží jak moc zapisujete - pokud hodně, tak může častěji docházet k vynuceným checkpointům - což vám může krátkodobě způsobovat zahlcení systému - jednak máte peaky v zápisu, druhak čtení musí počkat až se dokončí zápis a uvolní se datové stránky. Čím máte větší shared buffers, tím lagy způsobené vynucenými checkpointy mohou být horší. Může se stát, že vám zalaguje proces, který drží zámky, a pak celá db začne lagovat.

[MP]

Hm, tohle info nikde v tuning manualech neni. Vsude uvadi doporucenych 25% pro shared_buffers, coz u 128GB RAM stroje je 32GB...nez sahat do bgwriteru(neznam jeho chovani), byla by jednodussi cesta nastavit vetsi WAL rozsah (za cenu mista na disku)?

[okbobcz]

Tohle je jiný problém - checkpoint se nastartuje nikoliv, že narazíte na limit WAL rozsahu, ale protože vám dojdou volné stránky v shared buffers.

[skajrajdr]

Sorry, ale tady delas velkou chybu na ktere se da krasne demonstrovat proc je tvuj test k nicemu. Totiz tvoje nastaveni je pro produkci nejspise uplne spatne a s nejvetsi pravdepodobnosti jsi timhle vykon produkce ZHORSIL. Ty sis to maximalne vyladil pro tvuj synteticky test, ktery ale na 99% neodpovida tomu co potrebujes. Takze se chytas nejake chimery "pevneho bodu", ktera ti nejenom nic nerekla o realnem stavu, ale jeste navic te poslala na uplne zcesti...

Jeste jinak - pokud jsi vyvojar pgbench, a db bude provadet izolovane jeden pgbench, tak jsi to nastavil skoro spravne.

Abych jen nekibicoval - pokud o postgres nevis nic, vygeneruj si nastaveni tady https://pgtune.leopard.in.ua Vetsinou to dava dobre vysledky, se kterymi se da zacit.

 

[trekker.dk]

https://pgtune.leopard.in.ua

Ehm... total memory - must be less or equal to 9999.

[skajrajdr]

Jako zes chtel poradit jak defaultne nastavit svuj stroj s cca 10 tb ram a ono to selhalo?:) Myslim/doufam ze clovek s pristupem k takovemu stroji uz trochu vi co dela a proc a jak nakonfigurovane na nem ma bezet Postgres:)

[trekker.dk]

Myslim/doufam ze clovek s pristupem k takovemu stroji

Pro vás je stroj s více než 10GB RAM "takový stroj"?

[skajrajdr]

Vzdyt se tam da nastavit 9999GB:) Ale faktem je, ze clovek s pristupem k takovemu stroji zvladne prepnout jednotky ve formulari:)

[trekker.dk]

"Dá se" nemění nic na faktu, že to pro platný vstup hází chybu. Rady ohledně nastavení databáze od někoho, komuhle tohle nevadilo, brát s velkou rezervou.

[skajrajdr]

Ty ses komik. Nejdriv neumis pouzit plne funkcni formular (ktery se normalne validuje, zadnou chybu nehlasi). Kdyz ti to nekdo ukaze, tak zacinas okopavat kotniky se zaverem, ktery je uplne nesmyslny a s formularem nijak nesouvisi... :)

[trekker.dk]

Řeknu vám to jednoduše, soudruhu - formulář, který umožňuje stejný vstup zadat dvěma způsoby, ale funguje jen pro jeden z nich a pro druhý vypisuje chybové hlášení, není plně funkční. Můžete se o tom dohadovat, jak chcete, ale prostě a jednoduše není.

[deda.jabko]

Dekujeme za nazor a posilame klicenku.

Pokud maji problem vyplnit spravne ten formular, nemeli by se poustet do konfigurace Postgresu. Mohou se o tom dohadovat, jak chteji, ale tak to proste a jednoduse je.

[trekker.dk]

Jenže, což vám nejspíše uniklo, formulář byl vyplněn správně.

[skajrajdr]

Hele sorry, ale ty mas nejaky vnitrni problem, proc tady soudruhujes? Vzdyt tu meles nesmysly uplne z cesty... Smir uz se prosimte s tim, zes jen nedokazal pouzit normalni formular a pritom z toho faktu vubec nic nevyplyva:) (narozdil od tveho nasledneho projevu) Tim bych to asi za me ukoncil.

[trekker.dk]

Soudruhu, ten formulář normálně obsahuje chybu, to se tak vývojářům stává. To, jak se k té chybě postaví, je vypovídající.

[AraxoN]

Okej, beriem. Za link ďakujem, už to pozerám.

[skajrajdr]

Neni zac. Kdybys chtel ladit dal, az to zapnes produkcne, tak doporucuji zapnout slow query log pro prvnich par tydnu. Uvidis, co ti zere vetsinu zdroju a muzes autory upozornit, eventuelne upravit konfiguraci.

[AraxoN]

Slow logy mám v produkcii zapnuté priebežne (aktuálne nad 500ms), vývojári občas prejdú aktuálny report z pgbadgeru a ladia.

Som si vedomý toho, že tam môže bežať neoptimálny dotaz kratší než 500ms, ale milión-krát za deň a teda s väčším dopadom na výkon než všetky ostatné.

Preto mám v pláne po nasadení nového servera aspoň na jeden deň nechať zalogovať úplne všetko, ale tie logy sú potom fakt obrovské. Sledovať takto dlhšie obdobie neprichádza do úvahy.

[okbobcz]

Drtivá většina rychlých dotazů je pod 30ms, a to většinou nemá cenu logovat, a nemá cenu je opravovat (i když ORMka dotazy tohoto typu umí umlátit server). Je možné nastavit limit 10ms, nebo v nové verzi Postgresu nastavit vzorkování - např. pod 10ms 1%m, nad 10ms vše

[AraxoN]

Zaujímavé... len pre kontrolu, ten príklad by bol nejak takto?

log_min_duration_statement = 10
log_min_duration_sample = 0
log_statement_sample_rate = 0.01

[okbobcz]

nezkoušel jsem, ale myslím si, že by to mohlo být ok.

[alkoholik]

Dva dotazy:
Disky umi 512, 520, 528, 4096, 4160, or 4224 bytes per logical block. Zkusil jsi neco jineho nez default?
Pouzivas hugepages?

[AraxoN]

Že by som mohol mať inú veľkosť logického bloku sa dozvedám až teraz, takže nie, neskúšal.

HugePages sú v linuxe povolené a v postgresi je huge_pages = try, ale podľa /proc/meminfo ich nikto nepoužíva.

[alkoholik]

Kolik vidis v /proc/meminfo HugePages_Total?

[AraxoN]

Prepáč, nebol som tu. Niesol som nasadiť ten server do Bratislavy, bola to viacdňová akcia.

Teraz už s tým experimenty robiť nebudem, server už je v ostrej prevádzke. Ale HugePages_Total je nula... Znamená to, že kernel predsa len žiadne hugepages nie je ochotný poskytnúť?

[alkoholik]

Podle me sis o zadne nerekl.
Pouzivaji se kernel parametry hugepagesz=2M hugepages=123 nebo v runtime echo cisla do /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages. Alokace v runtime samozrejme muze selhat.
Mozna se ti to trosku spleto s transparent_hugepage, ktere kernel resi na pozadi. Ty na produkcnim db serveru naopak vypinam.