To alvorlige sikkerhedssårbarheder (kodenavnet Meltdown og Spectre) blev afsløret for et par uger siden. Indledende tests tydede på, at ydeevnepåvirkningen af begrænsninger (tilføjet i kernen) kan være op til ~30 % for nogle arbejdsbelastninger, afhængigt af syscall-hastigheden.
Disse tidlige estimater skulle foretages hurtigt, og de var derfor baseret på begrænsede mængder af test. Ydermere udviklede og forbedrede rettelserne i kernen sig over tid, og vi fik nu også retpoline som skal adressere Spectre v2. Dette indlæg præsenterer data fra mere grundige tests, der forhåbentlig giver mere pålidelige estimater for typiske PostgreSQL-arbejdsbelastninger.
Sammenlignet med den tidlige vurdering af Meltdown-rettelser, som Simon postede tilbage den 10. januar, er data præsenteret i dette indlæg mere detaljerede, men generelt matcher resultaterne præsenteret i det indlæg.
Dette indlæg er fokuseret på PostgreSQL-arbejdsbelastninger, og selvom det kan være nyttigt for andre systemer med høje syscall-/kontekstskifthastigheder, er det bestemt ikke på en eller anden måde universelt anvendeligt. Hvis du er interesseret i en mere generel forklaring af sårbarhederne og konsekvensanalysen, udgav Brendan Gregg en fremragende artikel om KPTI/KAISER Meltdown Initial Performance Regressions for et par dage siden. Faktisk kan det være nyttigt at læse det først og derefter fortsætte med dette indlæg.
Bemærk: Dette indlæg er ikke beregnet til at afskrække dig fra at installere rettelserne, men for at give dig en ide om, hvad effektpåvirkningen kan være. Du bør installere alle rettelserne, så dit miljø er sikkert, og bruge dette indlæg til at beslutte, om du muligvis skal opgradere hardware osv.
Hvilke test skal vi lave?
Vi vil se på to sædvanlige grundlæggende arbejdsbelastningstyper - OLTP (små simple transaktioner) og OLAP (komplekse forespørgsler, der behandler store mængder data). De fleste PostgreSQL-systemer kan modelleres som en blanding af disse to typer arbejdsbelastning.
Til OLTP brugte vi pgbench, et velkendt benchmarkingværktøj leveret med PostgreSQL. Vi testede begge i skrivebeskyttet (-S ) og læs-skriv (-N ) tilstande med tre forskellige skalaer – passer ind i shared_buffers, i RAM og større end RAM.
Til OLAP-sagen brugte vi dbt-3 benchmark, som er ret tæt på TPC-H, med to forskellige datastørrelser – 10 GB, der passer ind i RAM, og 50 GB, som er større end RAM (i betragtning af indekser osv.).
Alle de præsenterede tal kommer fra en server med 2x Xeon E5-2620v4, 64 GB RAM og Intel SSD 750 (400 GB). Systemet kørte Gentoo med kerne 4.15.3, kompileret med GCC 7.3 (nødvendigt for at aktivere den fulde retpoline rette op). De samme tests blev også udført på et ældre/mindre system med i5-2500k CPU, 8 GB RAM og 6x Intel S3700 SSD (i RAID-0). Men adfærden og konklusionerne er stort set de samme, så vi vil ikke præsentere dataene her.
Som sædvanlig er komplette scripts/resultater for begge systemer tilgængelige på github.
Dette indlæg handler om præstationspåvirkningen af reduktionen, så lad os ikke fokusere på absolutte tal og i stedet se på ydeevnen i forhold til upatchet system (uden kernebegrænsningerne). Alle diagrammer i OLTP-sektionen viser
(throughput with patches) / (throughput without patches)
Vi forventer tal mellem 0 % og 100 %, hvor højere værdier er bedre (mindre effekt af afbødninger), 100 % betyder "ingen indvirkning."
Bemærk: Y-aksen starter ved 75 %, for at gøre forskellene mere synlige.
OLTP / skrivebeskyttet
Lad os først se resultater for skrivebeskyttet pgbench, udført af denne kommando
pgbench -n -c 16 -j 16 -S -T 1800 test
og illustreret af følgende diagram:
Som du kan se, påvirker pti ydeevnen for skalaer, der passer ind i hukommelsen, er omkring 10-12% og næsten ikke-målbare, når arbejdsbyrden bliver I/O-bundet. Desuden reduceres regression markant (eller forsvinder helt), når pcid er aktiveret. Dette er i overensstemmelse med påstanden om, at PCID nu er en kritisk ydeevne/sikkerhedsfunktion på x86. Virkningen af retpoline er meget mindre – under 4 % i værste fald, hvilket let kan skyldes støj.
OLTP / læs-skriv
Læse-skrivetestene blev udført af en pgbench kommando svarende til denne:
pgbench -n -c 16 -j 16 -N -T 3600 test
Varigheden var lang nok til at dække flere kontrolpunkter og -N blev brugt til at eliminere låsestrid på rækker i den (lille) grentabel. Den relative ydeevne er illustreret af dette diagram:
Regressionerne er en smule mindre end i det skrivebeskyttede tilfælde – mindre end 8 % uden pcid og mindre end 3 % med pcid aktiveret. Dette er en naturlig konsekvens af at bruge mere tid på at udføre I/O, mens der skrives data til WAL, tømme modificerede buffere under checkpoint osv.
Der er dog to mærkelige ting. For det første virkningen af retpoline er uventet stor (tæt på 20%) for skala 100, og det samme skete for retpoline+pti på skala 1000. Årsagerne er ikke helt klare og vil kræve yderligere undersøgelse.
OLAP
Analysearbejdsbyrden blev modelleret af dbt-3 benchmark. Lad os først se på skala 10 GB resultater, som passer helt ind i RAM (inklusive alle indekser osv.). På samme måde som OLTP er vi ikke rigtig interesserede i absolutte tal, hvilket i dette tilfælde ville være varigheden af individuelle forespørgsler. I stedet vil vi se på afmatning sammenlignet med nopti/noretpoline , det vil sige:
(duration without patches) / (duration with patches)
Hvis vi antager, at begrænsningerne resulterer i afmatning, får vi værdier mellem 0 % og 100 %, hvor 100 % betyder "ingen indvirkning". Resultaterne ser således ud:
Det vil sige uden pcid regression er generelt i intervallet 10-20 %, afhængigt af forespørgslen. Og med pcid regressionen falder til mindre end 5 % (og generelt tæt på 0 %). Endnu en gang bekræfter dette vigtigheden af pcid funktion.
For datasættet på 50 GB (som er omkring 120 GB med alle indekser osv.) ser virkningen sådan ud:
Så ligesom i tilfældet med 10 GB er regressionerne under 20 % og pcid reducerer dem markant – tæt på 0 % i de fleste tilfælde.
De tidligere diagrammer er lidt rodede – der er 22 forespørgsler og 5 dataserier, hvilket er lidt for meget for et enkelt diagram. Så her er et diagram, der kun viser virkningen for alle tre funktioner (pti , pcid og retpoline ), for begge datasætstørrelser.
Konklusion
For kort at opsummere resultaterne:
retpolinehar meget lille effekt på ydeevnen- OLTP – regressionen er omkring 10-15 % uden
pcid, og omkring 1-5 % medpcid. - OLAP – regressionen er op til 20 % uden
pcid, og omkring 1-5 % medpcid. - For I/O-bundne arbejdsbelastninger (f.eks. OLTP med det største datasæt), har Meltdown ubetydelig indvirkning.
Virkningen ser ud til at være meget lavere end de oprindelige estimater antyder (30 %), i det mindste for de testede arbejdsbelastninger. Mange systemer kører med 70-80 % CPU i spidsbelastningsperioder, og de 30 % ville mætte CPU-kapaciteten fuldt ud. Men i praksis ser virkningen ud til at være under 5 %, i det mindste når pcid mulighed bruges.
Misforstå mig ikke, et fald på 5 % er stadig en alvorlig regression. Det er bestemt noget, vi ville bekymre os om under PostgreSQL-udvikling, f.eks. ved evaluering af virkningen af foreslåede patches. Men det er noget, eksisterende systemer burde klare fint – hvis 5 % stigning i CPU-udnyttelse får dit system over grænsen, har du problemer selv uden Meltdown/Spectre.
Det er klart, at dette ikke er slutningen på Meltdown/Spectre-fixes. Kerneludviklere arbejder stadig på at forbedre beskyttelsen og tilføje nye, og Intel og andre CPU-producenter arbejder på mikrokodeopdateringer. Og det er ikke sådan, at vi kender til alle mulige varianter af sårbarhederne, da det lykkedes forskerne at finde nye varianter af angrebene.
Så der er mere på vej, og det bliver interessant at se, hvad indvirkningen på ydeevnen vil være.