Dotaz: Vplýva CPU load na ping?

[rastos]

Dostal som otázku, na ktorú sám neviem dobre odpovedať, tak sa chcem opýtať tu:

Predstavte si, že máte 8 jadrový Linuxový stroj, na ktorom beží 8x Windows XP virtualizovaný pomocou VirtualBox-u. Každý VM má priradené jedno fyzické jadro. Každý ten VM robí komplikovaný výpočet náročný predovšetkým na CPU, a nenáročný na disk, pamäť, či sieť.

Otázka: Môže vysoká záťaž CPU spôsobiť dlhú dobu odozvy (viac ako 10s v tej istej LAN) na ping?

Odpovědi

[Trubicoid2]

Asi může, i když 10s je hodně, to se tam ani nikdo nepřihlásí Co takhle jedno jádro osvobodit a nechat linuxu?

A 8 je včetně HT? To je pak mazec, obzvlášť jestli ta zátěž je FP

[rastos]

Co takhle jedno jádro osvobodit a nechat linuxu?

To môžem skúsiť.

A 8 je včetně HT?

Mno. Tam mi nie je celkom jasno, ale je to asi Dell PowerEdge 1950 a

grep CPU /proc/cpuinfo

povie 8x

model name: Intel(R) Xeon(R) CPU E5420  @ 2.50GHz

Čo sa týka hyper-threading-u:

grep -w ht /proc/cpuinfo

vypíše

flags ... ht ...

Čo je "FP"?

[cronin]

E5420 je štvorjadrový CPU bez HT; pravdepodobne pôjde o dvojprocesorový stroj.

"FP" je Floating Point, výpočty s pohyblivou rádovou čiarkou. Ak sa skutočne jedá o taký výpočet, tak je to fakt priekak, lebo ten procesor má pravdepodobne jedinú FPU. Čo za sakramenský výpočet to je, že pre každú bežiacu inštanciu je potrebná samostatná inštancia operačného systému, navyše takého čudného? Skúšali ste vôbec postupný spúšťaním 1, 2, 4 a 8 inštancií, že výpočet skutočne škáluje?

[Trubicoid2]

Jestli to je E5420, tak je to Core2Duo architektura, tak by měl mít 4 FPU a nemít HT

Já mám dvojitý E5472 a tam to kupodivu 8 procesů trvá 75% času 4 procesů. Spíš by to mělo být 50%, nevím čím to je. Když se vezme 8 jader z různých uzlů tak vyjde 50%. Ten procesor je záhadnej.

[rastos]

lebo ten procesor má pravdepodobne jedinú FPU.

To budem musieť zistiť. Dík za tip.

Teraz som si všimol, že /proc/cpuinfo tiež hovorí:

cpu cores       : 4
...
fpu             : yes

Čo za sakramenský výpočet to je,

Z matematického/algoritmického hľadiska sa to nazýva "packing problem" a áno, pracuje so floating point dátami.

že pre každú bežiacu inštanciu je potrebná samostatná inštancia operačného systému

Ako to už býva, historicky existuje nejaká implementácia a je do toho zamontovaných mnoho komponentov a nie všetky je možné preportovať na iný OS.

, navyše takého čudného?

Sčasti historické dôvody. Sčasti preto, že taký OS je jednoduchý. Na každej ďalšej verzii Windowsov ten OS robí hromadu vecí, ktoré netreba. Keď sa pozriem na zoznam procesov na XP, tak tam nájdem ~10 položiek. Keď sa pozriem na W10, tak ich je tam aj 50 a kvantum úloh, ktoré sa spúšťajú pri nejakej udalosti ...

Skúšali ste vôbec postupný spúšťaním 1, 2, 4 a 8 inštancií, že výpočet skutočne škáluje?

To v tomto momente neviem povedať, ale určite sa tým budeme musieť zaoberať.

[pc2005]

Vysoká zátěž má určitě vliv na to jak moc často se userspace program (ping) dostane k CPU. Při normální zátěži by to ale těch 10s nemělo udělat nikdy. I kdyby to mělo latence jednosekundové tak bych hledal chybu.

[rastos]

Vysoká zátěž má určitě vliv na to jak moc často se userspace program (ping) dostane k CPU.

To sme sa nerozumeli. Ten ping púšťam na inom stroji než je ten vyťažený neborák. Takže proces ping-u sa k slovu dostane. Ide o to, či ten, kto ten ping paket dostane, odpovie naň ešte v rámci jadra. Reps. ak pingujem ten VM, tak či sa musí dostať k slovu ten VM.

[Michal Kubeček]

Reps. ak pingujem ten VM, tak či sa musí dostať k slovu ten VM.

Tak moment… celou dobu to vypadalo, že mluvíte o odezvách toho hosta. Tam by to bylo opravdu hodně divné, protože odpověď aby něco takhle zadusilo odpovědi na ICMP echo, muselo by to mít přinejmenším realtime prioritu (a bylo by s podivem, že by vám nezačal nadávat soft lockup detector nebo RCU stall detector.

Jestli se ale bavíme o odezvách těch guestů, tak tam kromě (dvakrát) síťového stacku hosta (Linuxu) hraje roli ještě zpracování ICMP echo guestem, což jsou Windows, takže k tomu nic říct nemůžu.

[rastos]

Reps. ak pingujem ten VM, tak či sa musí dostať k slovu ten VM.

Tak moment… celou dobu to vypadalo, že mluvíte o odezvách toho hosta.

Ja som to na začiatku nejako explicitne nepovedal. A ani mi to samému nie je 100% jasn0. Len som posunul tak ako som otázku dostal. Skúsim dozistiť podrobnosti, ale nateraz si myslím, že ide o odozvu guest-a.

Na druhej strane, nedivil by som sa keby obsluha ping-u bola urobená ak súčasť modulu, ktorý VirtualBox potrebuje v jadre hosta. ... Chcem povedať: neviem ako to presne je vnútri urobené, ale nečudoval by som sa, keby si VirtualBox urobil v host-ovi niečo ako virtuálny adaptér pre každého pusteného guest-a a obsluha pingu by sa mohla odohrať už tam.

[Michal Kubeček]

Tak to já bych se něčemu takovému nejen divil, ale považoval bych to za velmi nekorektní chování. Uvědomte si, že takhle by ten host za guesta odpovídal i v případě, že by guest tu svou virtuální síťovou kartu vůbec neměl nakonfigurovanou (a i kdyby měl, jak by host věděl, na které adresy má odpovídat?) nebo by guest dokonce úplně zatuhnul. Nemluvě o tom, že si na guestovi můžu spustit opatchované jádro, které bude pro testovací účely na ICMP echo odpovídat trochu odlišným způsobem.

[pc2005]

Zkus všechny pingací variace.

host - host (localhost)
host - virtuál
virtuál - host
virtuál - jinej virtuál
virtuál - ten samej virtuál (localhost)
externí - virtuál
externí - host
virtuál - externí
virtuál - host

Pak ještě můžeš zkusit ping flood a skenovat jednotlivé testy nějakým snifferem (například wireshark).

[Ivan]

V tom pripade je to hodne divny. Odpoved na ping obsluhuje kernel a ten ma max. prioritu. Uz se mi nekolikrat stalo, ze se serveru dostaly do nekonecne smycky procesy s realtime prioritou (Oracle rac lmd procesy) a pak se neslo prihasit, neslo s tim serverem delat nic jineho nez to otocit. Jedine na co ten server reagoval byl sysrq.

Na ping ale ten server odpovidal uplne v pohode. Dokonce pri navazani TCP spojeni odpovedel na SYN.

[Michal Kubeček]

Uz se mi nekolikrat stalo, ze se serveru dostaly do nekonecne smycky procesy s realtime prioritou (Oracle rac lmd procesy) a pak se neslo prihasit, neslo s tim serverem delat nic jineho nez to otocit. Jedine na co ten server reagoval byl sysrq.

To je známý problém, včetně toho, že pachatelem je nejčastěji Oracle. Ten realtime proces sice udusí "jen" jeden procesor, ale čas od času je potřeba provést něco na všech procesorech (např. rcu_sync()) a taková věc pak čeká, až se příslušný procesor uvolní, čímž blokuje další. Když se to nechá dost dlouho, visí nakonec všechny, pokud ten systém dřív neodstřelí soft lockup detector nebo RCU stall detector.

Na ping ale ten server odpovidal uplne v pohode. Dokonce pri navazani TCP spojeni odpovedel na SYN.

Tohle je trochu složitější. Nemáte-li tam moc velkou zátěž (ve smyslu počtu příchozích paketů), stihne se oboje vyřídit ještě v rámci softirq vyvolaného na konci obsluhy hardwarového přerušení, čemuž nedokáže zabránit ani ten realtime proces okupující daný procesor. Pokud té práce ale bude moc, nechá se to na ksoftirqd a pak máte problém. (Kromě toho ale ten příchozí paket nemusí vůbec připadnout na blokovaný procesor.)

[dan]

ja mavam bezne problem dlhej odozvy pingov v solarisoch ked cielova ip adresa nema reverzny zaznam, staci dat pingu parameter aby neresolvoval. Skust ci to nieje tiez problem s DNS.

[dan]

teda ja mam tu prvu odozvu po 10s ale pingy su v poriadku tak to asi nebude tvoj problem