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