cim vic jader CPU, tim pomalejsi
Miroslav Lachman
000.fbsd at quip.cz
Thu Apr 1 17:06:57 CEST 2021
On 01/04/2021 07:42, David Pasek wrote:
> 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.
Ano, to souhlasi
> 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
Celkem tam jsou 4 VM:
Linux s dockerem, 1 vCPU + 768MB RAM
Linux s dockerem, 1 vCPU + 1024MB RAM
FreeBSD 11.4 IPSec GW, 1 vCPU + 1024MB RAM
FreeBSD 11.4 "webhosting" 5 - 10 vCPU + 16GB RAM
> 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.
V tom nejextremnejsim testovanem pripade jsem mel 13 vCPU, ale velmi
spatne se to chova i kdyz tomu "webhsotingu" dam 8 vCPU, takze celkem to
bylo 11 vCPU.
Rad bych taky upozornil na to, ze ty vedlejsi VM v podstate nic
nedelaji. Jsou v tom nejake oneshot aplikace, co se spusti tak jednou za
hodinu, odeslou data skrz tu IPSec GW a pak zase nic nedelaji.
(predavaji se skrz to nejake pozadavky do vzdalene message queue)
> Vypada to, ze proste ocekavas od Tveho systemu vice nez je ti ochoten dat.
Ja bych tomu vsemu i docela rozumnel, kdybych videl, ze je ten procesor
na hostiteli (hypervizoru) zatizeny, ale ono se to porad flaka a v
okamziku, kdy VM s treba 6, nebo jeste hur s 8 vCPU klekne na kolena a
stane se nepouzitelny, tak si na tom hostiteli muzu delat cokoliv,
klidne bych tam mohl pustit nejakou kompilaci a vykonu by to melo porad
dostatek. Predstavoval jsem si to tak, ze kdyz mam overbooking vCPU vuci
HW CPU, tak bych mel videt vytizeny HW CPU a ne ze se HW CPU na
hypervisoru flaka a VM je nepouzitelne pomaly.
Navic je nepouzitelne pomaly i pro jednovlaknove aplikace.
Ten virtualizacni paradox bych porad chapal, kdybych od toho VM
pozadoval s pridavanim vCPU i vetsi vykon, ale to se nedeje, jenom tim,
ze nastavim vic vCPU a zatez vseho okolo je porad stejna, spadne vykon
toho VM o desitky procent dolu.
Dale jsi v tom textu psal o "ve fronte 0.125% casu", to bych taky
chapal, ze se budou ztracet treba i jednotky procent, coz ale neodpovida
tomu, co ja na tom pozoruju. Ja zvednu pocet vCPU z 6 na 8 a boot
(nacteni pravidel PF) se prodlouzi treba 20x oproti stavu pred navysenim
poctu vCPU. Pritom ta fyzicka jadra jsou na hypervizoru porad k
dispozici, nevytezujou je ty ostatni VM.
Mozna ten tvuj predchozi text spatne chapu, tak se teda zeptam
polopaticky: Je normalni, ze na nevytizenem stroji zvednutim poctu vCPU
z 6 na 8 klesne vykon o desitky procent? Tedy ze uloha, ktera pred tim
trvala do 10 sekund ted trva v radech minut?
A jeste vysvetleni k tomu, proc nastavuji "tak velky overbooking" -
nedokazu zadnym zpusobem vytizit CPU na hypervisoru. Ten procesor ani v
tom nejhorsim scenari nepracuje na vic, nez 50% (spis se to pohybuje
mezi 15% - 30%), takze jsem si rikal, ze kdyz tomu VM pridam vic vCPU,
tak to bude schopne vyuzit vic z potencialu HW CPU. Ale opak je pravdou.
Takze tu ted zkratka mam stroj s vykonem 6x 2.53 GHz (kdyz nepocitam HT
vlakna), ale nedokazu ten vykon vyuzit na vic, nez polovinu.
Rozhodne ne tim zpusobem, ze bych mel jeden velky VM. Mozna, ze kdybych
mel 6 malych s 2 vCPU, tak by to dokazalo vyuzit lip, nez 1 VM s 8 vCPU.
Mirek
More information about the Users-l
mailing list