Fun with Spectre (s výsledkem)

18.6.2018 13:29 | Přečteno: 3701× | Linux | poslední úprava: 19.6.2018 11:35

Konečně jsem se dokopal k upgradu našeho databázového serveru (12.1 na OL7), kterým se mi do systému propašovaly opravy pro Meltdown a Spectre. Trošku se nám nezdál výkon, tak jsme vytáhnuli náhodný SELECT z produkce a změřili čas.

# cat /sys/kernel/debug/x86/ibrs_enabled 
1
$ sqlplus

SQL*Plus: Release 12.1.0.2.0 Production on Mon Jun 18 11:12:28 2018

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options

SQL> set timing on
SQL> @select.sql
...
13 rows selected

Elapsed: 00:00:XX.XX

SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options

# echo 0 > /sys/kernel/debug/x86/ibrs_enabled

$ sqlplus

SQL*Plus: Release 12.1.0.2.0 Production on Mon Jun 18 11:12:28 2018

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options

SQL> set timing on
SQL> @select.sql
...
13 rows selected

Elapsed: 00:00:09.39

-- vyjasnění --
Detaily se v textu drobet ztrácí. Po vypnutí IBRS doběhl SELECT pod 10 sekund.
Anketa je: jak dlouho běžel před vypnutím (v sekundách)?

-- UPDATE --
Pravdu mají ti, kteří hádali "> 22". V průměru jsme se dostali z 9,5s k naprosto nepochopitelným 23,5s.
Prý 5-10% dolů.
Jó Intelu nasrat a namazat, nezůstala nám ani polovina výkonu!

PS: nejde jen o jeden náhodný SELECT. Provedli jsme (a mockrát testovali) upgrade z 11.2 na 12.1 a s IBRS trval místo půl hodiny hodinu celou.        

Anketa

Komentáře

[snajpa]

Tipoval bych nekde okolo 10-15%. Nejhur jsou na tom ti, co si mysleli, ze “hardwarove virtualizuji”; ti to maji jeste o level vys na hypervisoru zpomalene o podobne cislo.

[snajpa]

Ups, myslel jsem, ze anketa je o procentech, toho XX ve snippetu jsem si nevsim, mam to otevreny na tabletu a vidim jenom “Oracle blabla”, tak jsem ani nepokracoval (protoze mi to nerekne vubec nic).

[pc2005]

[joke] Pokud je ten server na 486, tak změna nebude žádná ne? [/joke] [nonjoke] No ale chtělo by to opravdu napsat i procesor, novější intely maj tu lepší implementaci, některý nemaj update mikrokódu, AMDčka nemaj meltdown vůbec a některý už maj mikrokód pro opravu spectre [/nonjoke]

[Bubak]

Taky spusteni stejneho selectu dvakrat za sebou neni moc vypovidajici, chtelo by to spustit v obou nastavenich nekolikrat a pak mrknout na vysledky. Pokud to bylo spusteno opravdu jen takhle dvakrat za sebou, muzou se casy dost lisit i za normalnich okolnosti Ale autor nic blizsiho nepise, tak treba to je uz vyber

[alkoholik]

Sorry, ten SELECT jsme samozrejme pustili nekolikrat. Rozdily jednotlivych behu byly pod sekundu. Bez fixu pro Spectre bezel v prumeru kolem 9,5s.

[alkoholik]

CPU Intel E5-2637 v3 s microcode 0x3c z 2018-01-19.

[pc2005]

To je haswell, ten snad ještě v mikrokódu IBRS neumí/nemá ne? Rozhodně ne v mikrokódu z ledna.

[alkoholik]

Podle Intelu je to zatim posledni produkcni verze a podle M$ tahle verze uz fix pro Spectre V2 ma. Datum bude asi nejaky inteli interni build. Proste to meli ready uz v lednu.

[alkoholik]

A pochybuju, ze bys do ibrs_enabled dostal 1, kdyby to CPU neumel. Na starsich serverech mam po bootu 0.
V sysfs v CPU vulnerabilities psal mitigation i IBRS.

[pc2005]

Je možný že to změnili, já vycházel z tohodle:

For Intel processors prior to Skylake, Retpolines are used instead of the ibrs feature for mitigation against Spectre variant 2.

a:

pti=1 ibrs=0 retp=1 ibpb=1-> fix variant#1 #2 #3 for pre-Skylake cpus

pti=1 ibrs=1 retp=0 ibpb=1-> fix variant#1 #2 #3 for Skylake cpus

[pc2005]

Taky je možný, že xeonový haswelly to mají trošku jinak než desktopový. Máš nějaký spectre/meltdown orientovaný parametr pro kernel?

[alkoholik]

Ne.

[snajpa]

Retpolines maji mensi overhead, nez mitigation pomoci IBRS; duvod, proc nebyly pouzity rovnou a nekde se pouzilo IBRS bylo, ze se musela podpora retpolines backportovat do prehistorickych GCC a rekompilovat s tim cele distro. IBRS v mikrokodu pro Haswell+ bylo vcelku rychle, pro starsi procesory nekde vyslo rychleji aplikovat rovnou retpoline. Retpoline mitigace pokud vim nefunguje na Skylake a novejsich, tam je to IBRS only. AFAIK.

[pc2005]

Aha, dík za info.

[alkoholik]

Oracle Linux ma vlastni UEK4 kernel. Treba to maji jinak.

[Ovoce]

Haswell opravu má. Když aktualizuješ z OS, tak už jsou mikrokódy i pro Sandy bridge a některé Nehalemy.

[pc2005]

BTW v jednom patchi se zmiňuje i volba:

echo 2 > /sys/kernel/debug/ibrs_enabled will turn on IBRS in both userspace and kernel

Teď nemůžu najít zda se do kernelu dostala (a nonvanilla distribuce to můžou mít jiné). Ale pokud by to tak platilo, tak nastavení pouze na 1 nebude mít na databázi tak velký vliv, jako by mělo i nastavení na userspace.

[pc2005]

ad update: To ale znamená že s hodnotou 2 to ale bude ještě pomalejší ne? o_O

[Max]

Smutný. Na druhou stranu, pokud jde čistě o backend, tak sice by nebylo pěkné ho nechávat děravý, ale zase by to nemělo ničemu vadit.
Zdar Max

[alkoholik]

Nas se bohuzel tyka PCI-DSS audit. Zkusime to okecat na retpoline nebo performance issues.

[snajpa]

Zalezi na architekture, pokud je tam jedna databaze a na tech procesorech nebeha nic jinyho, tak je skoda si vsema temahle mitigacema ukrajovat vykon. A i kdyz je ta databaze pustena jednou, ale ma v sobe vic databazi pouzite z vicero hostu, je pak stejne problem Oraclu, aby jejich kod byl imunni vuci temhle spekulativnim casovacim utokum. Na OS levelu je to potreba resit, pokud na tech procesorech bezi neco, co s tema databazema nema nic spolecnyho a nema to videt na jejich data, obzvlast, kdyz takova vec ma I/O mimo ten stroj.