cim vic jader CPU, tim pomalejsi

[David Pasek]

Ahoj Mirku.

Toto jsi psal v puvodnim mailu

<snip>
Okrajove pouzivam headless VirtualBox, ktery bezi na FreeBSD 11.4 a v
nem mam nekolik FreeBSD a Linux guest VM. Vetsinou se jedna o male
jednoucelove VM s 1 - jadry procesoru a tam mi pripada, ze vsechno
funguje normalne. Pred casem jsem v tom VirtualBoxu zkusil udelat i
ponekud vetsi virtualni stroj s 6 jadry, bezi tam Apache + PHP + MySQL a
subjektivne je to velmi pomaly na to, ze to ma dve tretiny jader
(presneji vlaken) z CPU Intel Xeon E5649.

Zkusil jsem tomu VM pridat vice jader (fyzicky procesor ma 6 jader,
celkem 12 vlaken, ten VM mel 6 virtualnich jader a ja to zvednul na 10).
Prekvapenim pro me bylo, ze od toho okamziku se zacal chovat jeste
pomaleji, nez pred tim navysenim poctu jader. A to tak pomalu, ze pri
bootu trvalo nacteni pravidel PF firewallu (respektive tabulek s
nekolika tisici IP adres) nekolik minut. Vec, ktera za normalnich
okolnosti probehne asi za 5 - 10 sekund.
</snip>

Jestli to chapu dobre, tak mas system osazeny jednim CPU Intel Xeon E5649,
takze mas 6 CPU Cores a pri zapnutem hyper-threadingu mas k dispozici
12 CPU Threads.

Na takovemto systemu s 6-ti pCPU provozujes
VM Apache + PHP + MySQL - 10 vCPU
par (nevim kolik) VM s 1 vCPU, rekneme ze dohromady treba - 5 vCPU
a podkladovy OS, ktery si vezme rekneme 2 CPU Cores

Celkovy system ma 6 CPU Cores, od ktereho odecteme 2 CPU Cores na podkladovy OS.
Zbyvaji nam 4 CPU Cores, ktere jsou teoreticky schopny zvladnout v
kvalite (3 vCPU na 1 pCPU) nejakych 12 vCPU.
Jaka kvalita je ta pozadovana (3:1, 2:1, 1:1) pro tve aplikace, je
zavisle na tvych aplikacich.
No a ty tam provozujes treba 15 vCPU, coz je overbooking skoro 4:1.

Vypada to, ze proste ocekavas od Tveho systemu vice nez je ti ochoten dat.

On Tue, Mar 30, 2021 at 1:59 AM Miroslav Lachman <000.fbsd at quip.cz> wrote:
>
> Opravdu system vidi 10 jader
> FreeBSD/SMP: 1 package(s) x 10 core(s)
>
> Problem je, ze je s temi 10 jadry opravdu neuveritelne pomaly.

> Zkusil jsem to jeste s 8 jadry a to vypadalo skoro stejne spatne jako s
> 10, se 7 jadry uz to bylo o neco lepsi. Ted jsem to zkusil se 4 jadry a
> system je skutecne temer bez zateze

Myslim si, ze to co pozorujes je prave ten Virtualizacni PARADOX, o
kterem jsem psal v minule odpovedi.
To, ze uberes vCPU ve VM a mas lepsi vykon je tezke nekomu
vysvetlovat, ale ono to celkem dava smysl.

Je to o tom, ze v pripade vetsiho overbookingu vCPU na pCPU zacina v
ramci scheduleru probihat dost velky magic, ktery se mi nechce
vysvetlovat po mailu, ale vysledkem je vyssi CPU latence diky vetsimu
plneni fronty, kdy vCPUs cekaji na volne pCPU a navic se u virtualniho
pocitace s 10-ti vCPU provozuje virtualni SMP (vSMP), kde je CPU
scheduling velmi tricky, jelikoz ty vCPU v ramci jednoho VM se nesmeji
rozjet casove. Respektive se ukazuje, ze trosku se rozjet muzou, ale
ne moc. Prave v implementaci vSMP je mezi ruznymi hypervisory celkem
velky rozdil a roky ladeni a tuningu.

Mimochodem jsem jen tak zbezne zagoogloval a nasel stranku
https://www.virtualbox.org/manual/ch03.html

Doporucuju si precist sekci 3.5.2. Processor Tab ...

<snip from="https://www.virtualbox.org/manual/ch03.html">
Processor(s): Sets the number of virtual CPU cores the guest OSes can
see. Oracle VM VirtualBox supports symmetrical multiprocessing (SMP)
and can present up to 32 virtual CPU cores to each virtual machine.
You should not configure virtual machines to use more CPU cores than
are available physically. This includes real cores, with no
hyperthreads.
</snip>

Virtualbox nedoporucuje pouzivat vice vCPU nez je pCPU (fyzickych CPU
cores). Nikoliv hyperthreadu.
Takze ve tvem pripade bys mel mit pro vsechny virtualky na tom stroji
maximalne 6 vCPU, coz mi pripada, ze porusujes, takze mne
neprekvapuje, ze vidis vykonostni problemy a pozorujes Virtualizacni
PARADOX.

Jak jsem psal minule. Na VMware ESXi vetsina verejnych cloud provideru
poskytuje CPU overbooking (vCPU : pCPU) 3:1 a nekdy klidne i 5:1 a to
bez toho, ze by uzivatele hlasili vykonostni problemy, i kdyz kvalita
CPU vykonu je relativni a kazda aplikace je na kvalitu jinak
sensitivni. Casto se tu relativitu snazim vysvetlovat pomoci
prirovnani ke kvalite vykonu storage, ktera se definuje response
timem. Pro nekterou aplikaci je prumerna kvalita storage vykonu pod 15
ms dostatecna a jine aplikaci nevyhovuje ani prumerny response time
kolem 3 ms. Dnes jsou casto pozadovany AllFlash storage s response
time pod 1 ms, takze se tam bavime o mikrosekundovych latencich.

Jeste je potreba si uvedomit, ze to co pozorujes v TOPu jsou
zprumerovane hodnoty. Nezapomen, ze veci v procesorech se deji v
jinych radech nez jsou sekundy, ktere jako lidi umime celkem dobre
zaznamenat. Access time pameti je napriklad cca 80 nano sekund. Tvuj
konkretni CPU ma 2.53 GHz, takze kolik udela cyklu za sekundu? No a
ted si predstav kdyz to ovebookujes co se stane? vCPU zustavaji ve
frontach. V mem ESXi clusteru v labu ted bezim 25 vCPU na 24 pCPU a u
vybraneho VM-ka vidim, ze vCPU zustanou v prumeru v CPU fronte 25ms v
monitorovanem 20 sekundovem samplu. To kdyz prepocitas, tak ti vyjde,
ze vCPU zustanou ve fronte 0.125% casu z toho casu, kdy by to melo byt
naschedulovany na fyzickych procesorech (pCPU). Cim vetsi je takoveto
procento, tim vice jsou zvirtualizovane systemy tzv. gumove.

No nic. Chci tim jen rict, ze fyziku obelstime jen trosku a musime
vedet co delame, jinak budeme prekvapeni. No a kdyz se bavim o Corech,
tak je to vlastne fyzika jaderna, takze budme opatrni, aby to
nebouchlo ;-)
-- 
David Pasek