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.)

  • 2276 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.

( debtamas88 | 2019. 08. 08., cs – 12:55 )

Szia!

Megnéztem E5-2667 V2 rendszeren
> sysbench 0.4.12
> Linux proxmox2 4.15.18-14-pve #1 SMP PVE 4.15.18-39 (Wed, 15 May 2019 06:56:23 +0200) x86_64 GNU/Linux

$> sysbench --test=cpu run
Test execution summary:
total time: 8.6735s
total number of events: 10000
total time taken by event execution: 8.6728

$> sysbench --test=cpu --num-threads=2 run
Test execution summary:
total time: 4.2351s
total number of events: 10000
total time taken by event execution: 8.4674

$> cat /proc/cpuninfo
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2667 v2 @ 3.30GHz
stepping : 4
microcode : 0x42d
cpu MHz : 3026.664
cache size : 25600 KB
physical id : 1
siblings : 8
core id : 11
cpu cores : 8
apicid : 54
initial apicid : 54
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti intel_ppin ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
bogomips : 6585.62
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

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.

Hardware:
HP ML350p Gen8
2018.05.21(A)(6 Jul 2018)

Sysbench
Host-on futattam, de megnéztem VM-ben 1vcpu-val:

$> sysbench --test=cpu run
Test execution summary:
total time: 8.4044s
total number of events: 10000
total time taken by event execution: 8.4037

$> sysbench --test=cpu --num-threads=2 run
Test execution summary:
total time: 8.3003s
total number of events: 10000
total time taken by event execution: 16.5966

Viszont megnéztem, most adtak ki valami új BIOS-t ehhez is :D

Version:2019.05.24 (28 Jun 2019)
This revision of the System ROM includes the latest revision of the Intel microcode which, in combination with operating system and/or hypervisor updates, provides mitigation for a new group of side channel vulnerabilities known as Microarchitectural Data Sampling (MDS). This includes support for mitigating the following vulnerabilities: CVE-2018-12126 - Microarchitectural Store Buffer Data Sampling, CVE-2018-12130 - Microarchitectural Fill Buffer Data Sampling, CVE-2018-12127 - Microarchitectural Load Port Data Sampling, and CVE-2019-11091 - Microarchitectural Data Sampling Uncacheable Memory. These issues are not unique to HPE servers.

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

( azbest | 2019. 08. 08., cs – 22:57 )

" 1 szálon 10.000 request esetén. Gondolom minél kisebb a szám, annál jobb."

Nem lehet, hogy a régi szerveren régi sysbench van és máshogy mér alapértelmezetten?

Nálam mindig 10 sec az idő és threadek számától függően (1-2-4) 11278 - 22936 - 42409 a number of events.

Ez egy sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3), ubuntu 18.04.3 lts a laptopomon. Itt is látszik, hogy így működik:
https://blog.pythian.com/sysbench-1-0-was-released/

A régi 0.4 körüli sysbench meg 10000 eventig megy alapból (vagy amit megadsz) és annak az idejét írja.

Add meg hogy --events=10000, ha azt akarod, hogy úgy mérjen mint a régi.

Pl, nekem az i7-3720qm

sysbench --test=cpu --events=10000 --num-threads=1 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
...
CPU speed:
events per second: 1118.07

General statistics:
total time: 8.9398s
total number of events: 10000

sysbench --test=cpu --events=10000 --num-threads=8 run
Running the test with following options:
Number of threads: 8
...
CPU speed:
events per second: 6146.38

General statistics:
total time: 1.6255s
total number of events: 10000

Pont most találtam én is egy linket, ahol fix 10s a time.
Nekem még 0.4.12 van, itt nincs evens kapcsoló, hanem max-request, de ha nem adom meg, default 10.000. Ugyanazt a VM-et vándoroltattam a host gépeken, csak a host változott alatta és jöttek ki ezek az értékek.

Ilyen egy teljes kimenet. A többin is, csak a time változik, amit fentebb megosztottam. 

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          9.8203s
    total number of events:              10000
    total time taken by event execution: 9.7944
    per-request statistics:
         min:                                  0.97ms
         avg:                                  0.98ms
         max:                                  1.67ms
         approx.  95 percentile:               0.98ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   9.7944/0.00

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.

Érdemes tisztában lenni azzal, mit tesztel pontosan az adott szoftver. Tartok attól, hogy nem azt, amit szeretnénk kimutatni.
A forráskódját tanulmányozva (src/tests/cpu/sb_cpu.c) esetünkben simán prímjelölt moduló (2..sqrt(prímjelölt)) között az integeres hardverosztót nyúzza.
Az ARM-ok integerben igen jók, a hardverosztója sem rosszabb az x86-nál. Nézzünk egy ARM Cortex A53 architektúrát: 

odroid-c2:~$ sysbench --test=cpu --num-threads=1 run

Test execution summary:
    total time:                          9.7273s
    total number of events:              10000
    total time taken by event execution: 9.7245
    per-request statistics:
         min:                                  0.97ms
         avg:                                  0.97ms
         max:                                  1.54ms
         approx.  95 percentile:               0.98ms


odroid-c2:~$ sysbench --test=cpu --num-threads=4 run

Test execution summary:
    total time:                          2.3937s
    total number of events:              10000
    total time taken by event execution: 9.5696
    per-request statistics:
         min:                                  0.95ms
         avg:                                  0.96ms
         max:                                  1.88ms
         approx.  95 percentile:               0.97ms

Ezzel összevetve nem tűnik gyorsnak az Intel szerverproci, holott egyéb dolgokat figyelembevéve valójában sokkal nagyobb kiszolgálási teljesítményt ad a néhány wattos ARM Cortex A53-hoz képest.
Célszerű nem csak integeres hardver osztásra kihegyezni a tesztet (ahol a hardverosztó eleve igen nagy késleltetésű hardverművelet). Inkább olyan jellegű szintetikus teszttel célszerű próbálkozni, amely jobban közelít a rendszer valódi felhasználásához. Például ha webkiszolgáló, akkor teszt weboldalakat párhuzamos ab-vel terheljünk meg. Ha pedig jelfeldolgozás lesz a célja, akkor a leendő alkalmazástól függően f32 vagy f64 regiszterekkel FIR teszt, FFT teszt és hasonlókkal. Ilyen módon tesztelve már sokkal jelentősebb tempókülönbségek jönnek ki és a valós alkalmazással összhangban vannak a teszteredmények.