Spectre i Meltdown - wpływ na rynek hostingowy

[nnd.newbie]

Mamy tu wiele osób z firm hostingowych, więc może zaczęlibyśmy taką dyskusję: jak sądzicie jaki wpływ na rynek hostingowy będą mieć odkrycie luk Spectre i Meltdown i ich poprawek obniżających wydajność. W szczególności skutki dla klienta końcowego: obniżenie wydajności,  przycięcie parametrów, podwyżki cen, żadne? Najchętniej poznałbym opinie konkretnych osób jak będzie to wyglądało w ich firmach. 

[milosz]

Google twierdzi, że nie widzą różnicy

https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

[Suspect]

Po przeczytaniu niebezpiecznika bardzo zacząłem się obawiać o wydajność jednak okazuje się, że tytuł artykułu to typowy clickbait. Sądziłem, że skoro niebezpiecznik pisze o spadku wydajności nawet o 63% to pewnie w moim przypadku będzie to jakieś 20% (zgadując). Moje obawy były na szczęście mocno przesadzone.

 

Dziś postanowiłem zaaplikować wszystkie dostępne patche w tym nowy kernel. Postanowiłem przy tym zrobić benchmark który jak wiadomo nie odda w 100% dokładnych różnic w wydajności jednak pozwoli przybliżyć ile taka różnica wynosi.

 

Kernel 3.10.0-514.16.1.vz7.30.10 #1 SMP Sat Apr 29 20:28:55 MSK 2017 x86_64

 

Test 8 wątkowy

CPU speed:
    events per second:  9129.34

Test 1 wątkowy

CPU speed:
    events per second:  1423.28

 

Kernel 3.10.0-693.11.6.vz7.40.4 #1 SMP Fri Jan 5 21:20:16 MSK 2018 x86_64 + wszystkie dostępne w repozytorium poprawki

 

Test 8 wątkowy

CPU speed:
    events per second:  9260.09

 

Test 1 wątkowy

CPU speed:
    events per second:  1416.83

 

Testy przeprowadzone na 8 wątkowym procesorze Intel i7-6700K z użyciem sysbench.

Wniosek: nie ma widocznego spadku wydajności procesora

[milosz]

Obstawiam, że spadek wydajności jest przy jakichś określonych operacjach, o których nigdzie nie przeczytałem

Edytowane 12 Stycznia 2018 przez milosz

[webh]

Na naszych serwerach również nie widać różnicy w wydajności.

Edytowane 12 Stycznia 2018 przez webh

[Archi]

Nie wiem czy wszyscy zgodnie testujecie nie to co trzeba, czy nie rozumiecie na czym polega łatka.

 

Spadek wydajności, a raczej dodatkowy overhead aniżeli jakieś rzeczywiste spowolnienie dotyczy wyłącznie wykonywanych syscalli na poziomie OSu, a nie czystego benchmarka. Program wykonujący nawet bardzo zaawansowane obliczenia zajmujący 100% procesora nie odczuje w żadnym stopniu łatki, natomiast taki który dokonuje pierdyliard operacji na plikach, pomimo niewielkiego obciążenia CPU już tak.

 

Jak chcecie dobry benchmark to polecam testować INSERTy do MySQLa. Alternatywą będzie cat w pętli lub inne akcje znacząco ukazujące spowolnienie tam, gdzie rzeczywiście się ono znajduje. Nie, nie jest to jakaś ogromna liczba, którą widać na pierwszy rzut oka, ale w zależności od dokonywanego testu do 20% udało mi się zaobserwować, w szczególności na bazach danych. Będzie to bardziej odczuwalne na słabszych maszynach, bo koszt syscalla jako takiego jest minimalny i nawet z łatką bardzo trudny do zauważenia/zbenchmarkowania, ale jest i można w łatwy sposób go sprawdzić.

 

I nie, nie są to liczby, które kogokolwiek musiałyby zmusić do zainwestowania w lepszą infrastrukturę czy podwyżkę cen. Nawet w przypadkach serwerów stricte bazodanowych, dodatkowy overhead jest minimalny, bo operacje zapisu (czyli de facto operacje zapisu plików) są w ogromnej mniejszości w porównaniu do selectów, które na ogół ciągną się z cache'a. Z drugiej strony twierdzenie, że nic się nie zmieniło i spadek wydajności jest bujdą też jest głupotą - overhead jest, ale w przypadku rzeczywistego praktycznego użycia danego serwera, a nie umyślnym robieniu konkretnych benchmarków, jest on po prostu marginalny.

[servizza]

Realny spadek wydajności w środowisku hostingowym w tzw. "życiu realnym", według większych graczy wynosi od 5 do 24% (AWS/Azure), przynajmniej na tą chwilę. Spadek wydajności będzie zależny od jak słusznie zauważył archi ilości systemowych wywołań jak i obsługi pamięci contexu (oraz modelu posiadanego procesora). Poprzednicy chyba nie zadali sobie trudu przeczytania pełnej specyfikacji meltdown i spectre i wykonania odpowiednich testów,  a później będzie zdziwienie (no chyba że wszyscy się mylą, łącznie z gigantami jak rackspace czy nasa telemetry)

Niestety aplikując patcha trzeba mieć na uwadze:

https://www.computerworld.com/article/3247788/computer-hardware/intel-says-new-firmware-patches-trigger-reboots-in-haswell-and-broadwell-systems.html

 

 

Zastanawiam się jeszcze czy Panowie oprócz patchy wgrali też nowy firmware ? 

Edytowane 13 Stycznia 2018 przez servizza
model cpu

[oui]

Update #22 https://blog.online.net/2018/01/03/important-note-about-the-security-flaw-impacting-arm-intel-hardware/

[gb1]

W dużej części zależy od procesora wykorzystywanego oraz obciążenia. Jednak według mnie w przypadku webhsotingu nie będzie to miało większego znaczenia dla użytkownika końcowego. Pamiętajmy także że mamy trzy główne podatności, z czego jedna może być rozwiązana programowo, jednak wymaga microcodu i patchy, a nad kolejną się nadal zastanawiają jak rozwiązać. Na pewno w następnych miesiącach będą coraz lepsze i bardziej wydajne rozwiązania.

 

Znaczna większość webhostingu stoi na Linuxie zatem polecam śledzenie listy mailingowej developerów kernela, ciekawe dyskusje :-)

 

Jak wygląda według Was obecna sytuacja dostawców webhostingu w zakresie aktualizacji ? Śledzę kilku ciekawszych dostawców i widzę że poza nielicznymi dotychczas nie patchowali (przynajmniej tych serwerów które obserwuję).

[Espen]

A jak te bugi w procesorach mają się do działania zwykłego PC opartego na procku zakupionym w roku 2012? Ile lat wstecz procesory mają ten problem? I jak to się ma do kupowania nowych procesorów?

[gb1]

@Pawel_15 obecnie wygląda że podatne jest większość procesorów od 1995 roku. Natomiast co do kupowania nowych to jakie masz alternatywy ? Intel podobno od czerwca zeszłego roku wie o podatności i poza sprzedażą akcji przez prezesa to prace trwają jednak według mnie nie oczekuj nowych procesorów lub zmian w krótkim czasie. Intel znając dokładnie podatności wprowadził na rynek procesory Coffee Lake.

[Espen]

Czyli mam rozumieć że procesory z rodziny Coffee Lake są w jakimś stopniu odporne na te lukę?

Sama luka mnie tak mocno nie przeraża, miały ją trzy kompy i świat się z tego powodu nie zawalił.

Niepokoi mnie tylko nieco ryzyko sytuacji gdzie zaimplementują jakieś rozwiązania które spowolnią/zmniejszą wydajność obecnego już wiekowego procka i tego który kupię za kilka lat.

[gb1]

4 minuty temu, Pawel_15 napisał:

Czyli mam rozumieć że procesory z rodziny Coffee Lake są w jakimś stopniu odporne na te lukę?

 

Wręcz przeciwnie

 

4 minuty temu, Pawel_15 napisał:

... za kilka lat.

 

Poczekaj, obserwuj, kilka lat to długi okres czasu.

[Przemek Jagielski]

W dniu 13.01.2018 o 04:22, Archi napisał:

Nie wiem czy wszyscy zgodnie testujecie nie to co trzeba, czy nie rozumiecie na czym polega łatka.

 

Spadek wydajności, a raczej dodatkowy overhead aniżeli jakieś rzeczywiste spowolnienie dotyczy wyłącznie wykonywanych syscalli na poziomie OSu, a nie czystego benchmarka. Program wykonujący nawet bardzo zaawansowane obliczenia zajmujący 100% procesora nie odczuje w żadnym stopniu łatki, natomiast taki który dokonuje pierdyliard operacji na plikach, pomimo niewielkiego obciążenia CPU już tak.

 

Jak chcecie dobry benchmark to polecam testować INSERTy do MySQLa. Alternatywą będzie cat w pętli lub inne akcje znacząco ukazujące spowolnienie tam, gdzie rzeczywiście się ono znajduje. Nie, nie jest to jakaś ogromna liczba, którą widać na pierwszy rzut oka, ale w zależności od dokonywanego testu do 20% udało mi się zaobserwować, w szczególności na bazach danych. Będzie to bardziej odczuwalne na słabszych maszynach, bo koszt syscalla jako takiego jest minimalny i nawet z łatką bardzo trudny do zauważenia/zbenchmarkowania, ale jest i można w łatwy sposób go sprawdzić.

 

I nie, nie są to liczby, które kogokolwiek musiałyby zmusić do zainwestowania w lepszą infrastrukturę czy podwyżkę cen. Nawet w przypadkach serwerów stricte bazodanowych, dodatkowy overhead jest minimalny, bo operacje zapisu (czyli de facto operacje zapisu plików) są w ogromnej mniejszości w porównaniu do selectów, które na ogół ciągną się z cache'a. Z drugiej strony twierdzenie, że nic się nie zmieniło i spadek wydajności jest bujdą też jest głupotą - overhead jest, ale w przypadku rzeczywistego praktycznego użycia danego serwera, a nie umyślnym robieniu konkretnych benchmarków, jest on po prostu marginalny.

 

Na WHT [R.I.P] podawałeś łatkę na jajko, która kompiluje jajko bardziej pod kątem procka na którym jest stawiane jajo. Jak w tym przypadku będzie się sprawować procek? Podniesie się jakkolwiek jego działanie czy dalej Intel zrobił maniane? 

[gb1]

Kilka słów na ten temat napisał Linus wczoraj, można się z tym zapoznać tutaj:

https://lkml.org/lkml/2018/1/21/192

 

Warto przeczytać całość do końca :-)

[theqkash]

1 godzinę temu, gb1 napisał:

https://lkml.org/lkml/2018/1/21/192

 

Warto przeczytać całość do końca :-)

Bardzo mi się podoba tam słowo "garbage".

[Spoofy]

Chyba jedyne rozsądne słowa Linusa -ever