sysbench: újabb processzor gyengébben teljesít?

CPU-k, Cooler-ek

Sziasztok

Van pár újabb szerver, erős CPU-val és érezheőtően lassabbak benne a VM-ek.
A sysbench 50%-os romlást mutat a korábbiakhoz képest.

A táblázat sorrendje:
CPU: cpubenchmark.net értékelés 1 magra / összes magra | sysbench total time 1 szálon 10.000 request esetén. Gondolom minél kisebb a szám, annál jobb.

Xeon X3460 @ 2.80GHz # 4 core + HT: 1270 / 5143 | 9.8203s
Xeon E5645 @ 2.40GHz # 6 core + HT: 1077 / 6487 | 12.7453s
Xeon X5650 @ 2.66GHz # 6 core + HT: 1234 / 7526 | 13.1373s
Xeon E5-2690v3 @ 2.60GHz # 12 core + HT: 1976 / 19214 | 22.7053s <<< ez a bajom

A teszt így történt: sysbench --test=cpu run. A top szerint ez 1 magot dolgoztatott meg.
Ha 2 thread-et futtattam az újabb szerveren, akkor kaptam 9-10s értéket sysbench --test=cpu --num-threads=2 run

A gyakorlatban ez azt jelenti, hogy ha ugyanazt a teljesítményt akarom biztosítani egy virtuális gépnek, akkor az újabb szerveren 2x annyi CPU-t kell hozzárendelnem.
Miért van ez így?

(A teszt ugyanabban a frissen telepített virtuális gépben készült, amit vándoroltattam az egyes szerverek között.)

  • 2288 megtekintés

( debtamas88 | 2019. 08. 08., cs – 00:44 )

Szia!

E5 v3/v4 procikat jobban érinti a lassulás (spectre, meg a többiek) - szoftveresen lett/lesz javítva,
ellenben E5 v1/v2 procikat kevésbé érinti.

Tuning BIOS:
-HyperThreading: Disable
-ACPI C1/C2/C3.. State: Disable
-CPU core: performance mode

Tuning OS (linux kvm?):
-cpufreqd csomag governor: performance
-irqbalance csomag

( AiRLAC v | 2019. 08. 08., cs – 09:39 )

Spectre/Meltdown/stb fixek gondolom.

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Én is erre gondoltam, de a közel 50% nagyon sok.

Teszteltem a https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/mast… scripttel.
Mindegyik host gépen, a régi és új CPU-val szerelt szerveren is, XCP-ng 8.0.1 (XenServer fork):
> SUMMARY:
CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK
CVE-2018-12126:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO

A teszt virtuális gépen (debian 9.9):
> SUMMARY:
CVE-2017-5753:?? [/]CVE-2017-5715:KO CVE-2017-5754:KO[/b] CVE-2018-3640:OK CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:KO CVE-2018-3646:OK CVE-2018-12126:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO

Próbáltam virtuális gépen az itt közölt kernel paramétereket: https://hup.hu/node/157278 , de nem változott a sysbench érték, sem a check script kimenete.

Xeon X3460 @ 2.80GHz # 4 core + HT: 1270 / 5143 | 9.8203s
Ezt a szervert most le tudtam állítani, hogy BIOS-ba lépjek és kikapcsoljam a HT-t. Így már csak 4 magot látok, ebből kap továbbra is 1-et a teszt VM.
A sysbench értéke 9.7
Nem kellett volna felére esnie az értéknek, hiszen 1 mag 2 HT-t tartalmaz, amiből eddig egyet adtam. Most meg 1 rendes magot. Vagy valamit félreértek?

De miért esett volna a felére? A HT az virtuális két mag, de valójában csak egy magod van.

Ha semmi más nem fut, és adsz egy magot egy virtuális gépnek, amit az 100%-ban kihasznál, akkor teljesen mindegy, hogy van-e mellette még egy virtuális mag, amit nem használ éppen semmi.

( wpeople v | 2019. 08. 08., cs – 12:01 )

csak 1 tipp: próbáltad, hogy pin-eled a VM-hez a CPU-t (vagy fordítva :-)
a lényeg, hogy a VM mindíg adott CPU-t használjon és csakis azt. Elvileg le van írva, valahol egy táblázatban ,hogy melyik fizikai magnak melyik a HT "párja" esetleg érdemes lehet őket így együtt bind-elni.

Hatalmas ötlet, köszönöm!
xe vm-param-set uuid=XXXX VCPUs-params:mask=0
vagy futásidőben: xl vcpu-pin VMnév all 0

total time: 11.1026s
Mi a magyarázat? Nem dolgozik a content switching?

Annyi érdekesség van, hogy ha futásidőben adom ki, 10.9, ha fixre állítom a xe paranccsal és újraindíítom, akkor 11.1 és bármennyiszer próbálom le oda-vissza :)
Na de azért mindjárt más.

Meglett a cpu táblázat is: xenpm get-cpu-topology 

 CPU	core	socket	node
CPU0	 0	 0	 0
CPU1	 0	 0	 0
CPU2	 1	 0	 0
CPU3	 1	 0	 0
CPU19	 11	 0	 0
CPU20	 12	 0	 0
[...]
CPU22	 13	 0	 0
CPU23	 13	 0	 0
CPU24	 0	 1	 1
CPU25	 0	 1	 1
CPU26	 1	 1	 1
CPU27	 1	 1	 1
[...]
CPU44	 12	 1	 1
CPU45	 12	 1	 1
CPU46	 13	 1	 1
CPU47	 13	 1	 1

mi a magyarázat? az, hogy a kérdéses információk adott CPU belső cache-ében vannak. Ha a guest másik CPU-t kap éppen, akkor a abban a CPU cache-ben nincsenek benne az adatok, nem működik (kellően) az utasítás előrejelzés sem.

Nem vagyok egy CPU guru, de - ha jól tudom - akkor a hyperthread (HT) akkor számítandó (majdnem) második CPU-nak ha megfelelően tudja használni az adott maghoz tartozó cache-t és utasítást előrejelző algoritmust.

cpubenchmark szerint
Single Thread Rating: 2011
Összesen: 16158

Az értékek 1 szálon reálisak. Gondolom a VM-nek alapból 1 vCPU-ja volt. Milyen rendszeren? BIOS-t mikor frissítettél utoljára?
Felmerült, hogy lehet, hogy az új BIOS hozott valamit (2019. tavasz)
Ez egy DELL R730xd.

Szerintem ezek folyamatosan tesztelt megoldások. Ahol van pénz, ott nem kérdés, hogy folyamatosan vizsgálják az ARM vagy POWER9 alapú technológiákat is, hogy mit lehet kihozni belőlük... mondjuk én ilyen híreket akkor is szivárogtatnék a Google helyében, ha csak olcsóbban szeretném venni a procikat ;)

Felesleges, már így is 75%-al olcsóbb.

Mindezek tetejébe a processzorok árazása kifejezetten baráti (a Xeonokhoz viszonyítva), a csúcsmodell közel féláron kínál több mint kétszer több processzormagot az Intelhez mérten. A processzorok versenyképességét bizonyítja, hogy az ismert szervergyártók (élükön a HPE-vel és a Lenovóval) már javában készülnek az új Epyc-re alapozó rendszerekkel, A nagy felhőszolgáltatók sem hagyják ki a lehetőséget, a Microsoft Azure és a Google Cloud egyaránt kínál majd Epyc "Rome" instance-eket, a Google pedig még belső infrastruktúrájában is beveti az AMD újdonságait.

https://www.hwsw.hu/hirek/60672/amd-epyc-2-generacio-rome-processzor-sz…

*******
Ij

https://imgur.com/a/Ux6dDJS

Ezen én is gondolkoztam, ez is benne lehet.
Hiszen minél nagyobb a magszám, annál rosszabb a sysbench érték:
Xeon X3460 @ 2.80GHz # 4 core + HT: 1270 / 5143 | 9.8203s
Xeon E5645 @ 2.40GHz # 6 core + HT: 1077 / 6487 | 12.7453s
Xeon X5650 @ 2.66GHz # 6 core + HT: 1234 / 7526 | 13.1373s
Xeon E5-2690v3 @ 2.60GHz # 12 core + HT: 1976 / 19214 | 22.7053s

Lehet, hogy a sysbench nem a legjobb eszköz erre, de saját és több user visszajelzése alapján lassabbak az új szerveren lévő VM-ek. Ezért próbáltam keresni egy egzakt mérési módszert. Nézek egy ab tesztet is, ahogy lentebb javasolták.

nem a magszám miatt gondoltam, hanem a vm-eknek kiosztott core-ok valójában "fél" ht procimagok. Ha valamiért más vm kapja meg egyik felét, mint a másikat, akkor lehet a másik vm dolgoztatja a magot és ezért látszi úgy, hogy amikor mindkét vm dolgoztatja a magot, akkor fele a teljesítmény mint kéne.

Esetleg, ha az új szerverben nincs kihasználva a több memória csatorna, akkor terhelés alatt lassabb memóriakezelés lehet. Esetleg nincs a proci utasításkészlete átengedve teljesen (proxmox alatt by default kellett ezt állítani pl).

Eszembe jutott itt is kallódik pár vas:
10000 events, 10k prime, vm-en belül, minden ram csatorna használva a dual socketes supermicrokban. A vm egy socketről kapja az összes vCore-t.

0.4.12-es E5-2650 0 @ 2.00GHz
1 szál: 13.4666s, 10 szál: 1.3923s

0.4.12-es E5-2630 0 @ 2.30GHz
1 szál: 12.0948s, 10 szál: 1.3200s

egyébként itt is van pár eredmény
https://www.tomshardware.com/reviews/intel-xeon-e5-2600-v3-haswell-ep,3…
valsz így futtatták a 0.4.x-es verzióval
sysbench --test=cpu --cpu-max-prime=30000 run
azon az oldalon 2690v3 így 1 szálon: 35.7905s

nálam
E5-2630 1 szál: 54.6279s
E5-2650 1 szál: 58.4251s

az 1.0 sysbench estén
sysbench --max-requests=10000 cpu --cpu-max-prime=30000 --time=0 run
i7-3720qm 1 szál: 41.1950s

Javult, de azért érezhetően lassabb a VM tempója a 48 magos XCP-ng alatt, mint a 24 magos XenServer 6.5 alatt.
Összeraktam egy teszt VM-et, ráraktam a weboldalamat, apache mod-php, mysql és ab -vel nézem: 1, 2, 4 mag és 10..100..500 szálon.
Aztán most ugyanez, de 8VM-en párhuzamosan. Mindez XenServer 6.5 alatt. Aztán jön XCP-ng, majd KVM alatt.
Majd ugyanezt elvégzem a másik szerveren is előről az egészet.
Remélhetőleg egy szép látványos benchmark grafikonom lesz, amiből valamit majd megállapítok :)

24 magos: 2x Xeon X5650 @ 2.66GHz
48 magos: 2x Xeon E5-2690v3 @ 2.60GHz

Igen, bindelve is végzek tesztet. A cpubench úgy már hozza ugyanazt az értéket az új cpu-n, mint a régin, de ugye ez csak egy szintetikus teszt.
Gyarkolatban lassabb a 2690v3 egy sima apt-get upgrade folyamán is.