Vlákno názorů k článku PostgreSQL 19: zmenšení tabulek pomocí REPACK bez obav od Marek - Teď v nedávné době proletěla internetem zpráva, že...

Teď v nedávné době proletěla internetem zpráva, že PostgreSQL má výkonnostní problém na Linuxu 7.0. Příčinou je změna defaultního scheduleru v kernelu. Respektive odstranění jednoho z existujících a nahrazení jiným, novým. Přidali nový scheduler a odebrali jeden stávající. Ten starý tam měli ještě chvíli ponechat, ať si ten nový lidé dostatečně vyzkouší.

PostgreSQL si alokuje velký buffer v paměti a při přístupu k němu používá spin lock. Při použití starého scheduleru bylo vše v pořádku, vždyť PostgreSQL bylo léta odladěné a předpokládalo nějaké chování kernelu. S novým schedulerem kernel přepíná vlákna častěji. Například i v okamžiku, kdy jedno vlákno zrovna drží zamknutý zámek a řeší soft page fault (minor page fault). Ostatní vlákna dostanou příležitost běžet (se starým schedulerem nedostali) a jediné co mohou dělat, je točit se na spin locku. A plýtvat tak výkonem CPU.

Řešením je zapnout large pages / huge pages. Tím se razantně sníží počet page faults.

Možná by to stálo za zprávičku.

Zdroj například tady: https://read.thecoder.cafe/p/linux-broke-postgresql a nebo tady: https://mydbanotebook.org/posts/postgres-performance-regression-are-we-there-yet/

https://lore.kernel.org/lkml/yr3inlzesdb45n6i6lpbimwr7b25kqkn37qzlvvzgad5hfd7ut@xv4cihno76wu/

Andres Freund se k tomu vyjádřil a nevypadá to jako vážný problém. V případě, že máte relativně málo paměti, a málo shared_buffers (hodnotu určujete vy), tak se ten problém neprojevuje, a pokud máte vyšší shared buffers (vyšší desítky GB), tak by se mělo používat huge pages.