Před několika týdny byly odhaleny dvě vážné bezpečnostní chyby (kódové názvy Meltdown a Spectre). Počáteční testy naznačovaly, že dopad zmírnění (přidaných v jádře) na výkon může být u některých úloh až ~30 % v závislosti na rychlosti syscall.
Tyto prvotní odhady musely být provedeny rychle, a tak byly založeny na omezeném množství testů. Kromě toho se opravy v jádře vyvíjely a zlepšovaly v průběhu času a nyní máme také retpoline který by měl řešit Spectre v2. Tento příspěvek představuje data z důkladnějších testů, doufejme, že poskytuje spolehlivější odhady pro typické pracovní zatížení PostgreSQL.
Ve srovnání s raným hodnocením oprav Meltdown, které Simon zveřejnil 10. ledna, jsou data prezentovaná v tomto příspěvku podrobnější, ale obecně odpovídají nálezům uvedeným v tomto příspěvku.
Tento příspěvek je zaměřen na pracovní zátěž PostgreSQL, a i když může být užitečný pro jiné systémy s vysokou rychlostí přepínání systémových volání/kontextu, rozhodně není nějak univerzálně použitelný. Pokud máte zájem o obecnější vysvětlení zranitelností a posouzení dopadů, Brendan Gregg před pár dny publikoval vynikající článek KPTI/KAISER Meltdown Initial Performance Regressions. Ve skutečnosti by mohlo být užitečné si jej nejprve přečíst a poté pokračovat v tomto příspěvku.
Poznámka: Tento příspěvek vás nemá odradit od instalace oprav, ale poskytnout vám určitou představu, jaký to může mít dopad na výkon. Měli byste nainstalovat všechny opravy, aby bylo vaše prostředí bezpečné, a pomocí tohoto příspěvku se rozhodnout, zda budete potřebovat upgradovat hardware atd.
Jaké testy provedeme?
Podíváme se na dva obvyklé základní typy zátěže – OLTP (malé jednoduché transakce) a OLAP (složité dotazy zpracovávající velké objemy dat). Většinu systémů PostgreSQL lze modelovat jako kombinaci těchto dvou typů zátěže.
Pro OLTP jsme použili pgbench, známý nástroj pro benchmarking, který je součástí PostgreSQL. Oba jsme testovali v režimu pouze pro čtení (-S ) a čtení i zápis (-N ) režimy se třemi různými stupnicemi – zapadají do sdílených_bufferů, do RAM a větší než RAM.
V případě OLAP jsme použili benchmark dbt-3, který je poměrně blízký TPC-H, se dvěma různými datovými velikostmi – 10 GB, která se vejde do RAM, a 50 GB, která je větší než RAM (s ohledem na indexy atd.).
Všechna prezentovaná čísla pocházejí ze serveru s 2x Xeon E5-2620v4, 64GB RAM a Intel SSD 750 (400GB). Na systému bylo spuštěno Gentoo s jádrem 4.15.3, zkompilovaným s GCC 7.3 (potřebné k povolení plného retpoline opravit). Stejné testy byly provedeny také na starším/menším systému s CPU i5-2500k, 8GB RAM a 6x Intel S3700 SSD (v RAID-0). Ale chování a závěry jsou v podstatě stejné, takže zde nebudeme uvádět data.
Jako obvykle jsou kompletní skripty/výsledky pro oba systémy dostupné na github.
Tento příspěvek je o dopadu zmírnění na výkon, takže se nezaměřujme na absolutní čísla a místo toho se podívejme na výkon ve vztahu k neopravenému systému (bez zmírnění kernelu). Všechny grafy v sekci OLTP ukazují
(throughput with patches) / (throughput without patches)
Očekáváme čísla mezi 0 % a 100 %, přičemž vyšší hodnoty jsou lepší (nižší dopad zmírňování), 100 % znamená „žádný dopad“.
Poznámka: Osa y začíná na 75 %, aby byly rozdíly viditelnější.
OLTP / pouze pro čtení
Nejprve se podívejme na výsledky pro pgbench pouze pro čtení, spouštěný tímto příkazem
pgbench -n -c 16 -j 16 -S -T 1800 test
a znázorněno na následujícím grafu:
Jak můžete vidět, vliv pti na výkon u vah, které se vejdou do paměti, je zhruba 10-12 % a téměř neměřitelné, když se pracovní zátěž stane I/O vázána. Kromě toho je regrese výrazně snížena (nebo zcela zmizí), když pcid je povoleno. To je v souladu s tvrzením, že PCID je nyní kritickou funkcí výkonu/zabezpečení na x86. Vliv retpoline je mnohem menší – v nejhorším případě méně než 4 %, což může být snadno způsobeno hlukem.
OLTP / čtení-zápis
Testy čtení a zápisu byly provedeny pomocí pgbench příkaz podobný tomuto:
pgbench -n -c 16 -j 16 -N -T 3600 test
Doba trvání byla dostatečně dlouhá, aby pokryla více kontrolních bodů a -N byl použit k odstranění sporu o zámek na řádcích v (malé) tabulce větví. Relativní výkon ilustruje tento graf:
Regrese jsou o něco menší než v případě pouze pro čtení – méně než 8 % bez pcid a méně než 3 % s pcid povoleno. To je přirozený důsledek trávení více času prováděním I/O při zápisu dat do WAL, vyplachování upravených vyrovnávacích pamětí během kontrolního bodu atd.
Existují však dva zvláštní kousky. Za prvé, dopad retpoline je neočekávaně velké (téměř 20 %) pro stupnici 100 a totéž se stalo pro retpoline+pti na stupnici 1000. Důvody nejsou zcela jasné a budou vyžadovat další šetření.
OLAP
Analytická zátěž byla modelována pomocí benchmarku dbt-3. Nejprve se podívejme na výsledky měřítka 10 GB, které se zcela vejdou do paměti RAM (včetně všech indexů atd.). Podobně jako u OLTP nás opravdu nezajímají absolutní čísla, což by v tomto případě byla doba trvání jednotlivých dotazů. Místo toho se podíváme na zpomalení ve srovnání s nopti/noretpoline , tedy:
(duration without patches) / (duration with patches)
Za předpokladu, že zmírnění povede ke zpomalení, dostaneme hodnoty mezi 0 % a 100 %, kde 100 % znamená „žádný dopad“. Výsledky vypadají takto:
Tedy bez pcid regrese je obecně v rozsahu 10-20% v závislosti na dotazu. A s pcid regrese klesne na méně než 5 % (a obecně blízko 0 %). Opět to potvrzuje důležitost pcid funkce.
Pro 50GB datovou sadu (což je asi 120 GB se všemi indexy atd.) dopad vypadá takto:
Takže stejně jako v případě 10 GB jsou regrese pod 20 % a pcid výrazně je snižuje – ve většině případů se blíží 0 %.
Předchozí grafy jsou trochu nepřehledné – je tam 22 dotazů a 5 datových řad, což je na jeden graf trochu moc. Zde je tedy graf ukazující dopad pouze pro všechny tři funkce (pti , pcid a retpoline ), pro obě velikosti datových sad.
Závěr
Stručně shrnuji výsledky:
retpolinemá velmi malý dopad na výkon- OLTP – regrese je zhruba 10–15 % bez
pcida asi 1–5 % spcid. - OLAP – regrese je až 20 % bez
pcida asi 1–5 % spcid. - U úloh vázaných na I/O (např. OLTP s největší datovou sadou) má Meltdown zanedbatelný dopad.
Zdá se, že dopad je mnohem nižší, než naznačovaly původní odhady (30 %), alespoň u testovaného pracovního zatížení. Mnoho systémů pracuje na 70-80 % CPU ve špičkách a těch 30 % by plně nasytilo kapacitu CPU. V praxi se však zdá, že dopad je nižší než 5 %, alespoň pokud je pcid je použita možnost.
Nechápejte mě špatně, 5% pokles je stále vážná regrese. Určitě je to něco, na čem bychom si dali záležet při vývoji PostgreSQL, např. při hodnocení dopadu navrhovaných záplat. Ale je to něco, co by stávající systémy měly zvládnout v pohodě – pokud 5% nárůst využití CPU dostane váš systém přes okraj, máte problémy i bez Meltdown/Spectre.
Je zřejmé, že toto není konec oprav Meltdown/Spectre. Vývojáři jádra stále pracují na vylepšení ochran a přidávání nových a Intel a další výrobci CPU pracují na aktualizacích mikrokódu. A není to tak, že bychom věděli o všech možných variantách zranitelnosti, protože výzkumníkům se podařilo najít nové varianty útoků.
Je toho tedy více a bude zajímavé sledovat, jaký to bude mít dopad na výkon.