SW RAID CPU felhasználás mérése

Linux-kezdő

Sziasztok,

A kérdés adott. Mivel nem vagyok annyira otthon ezekben a dolgokban, viszont felmerült ez a kérdés, érdekelne, hogyan mérnétek meg egy SW RAID CPU overheadjét.

Kezdeti, igen gyatra mérések (dd /dev/zero-ból felmountolt ext4 filerendszerre) azt mutatták, hogy RAID nélkül 4% volt a max CPU használata a dd-nek, RAID-del 12%. Viszont ez szerintem - megérzésre - nem túl jó/pontos mérés.

( zeller | 2016. 05. 12., cs – 13:58 )

Jó kérdés, hogy milyen RAID? Nagyon nem mindegy, hogy 0, 1, 5, 6...

csak azért, mert raid0 esetén csak egy lemezre történik írás, mirror esetén már annyira, ahány winyót a tömbbe tettél - és akkor még jönnek az olyan apró úri huncutságok, mint raid5, raid6, ahol neki kell állni chekcsumokat is számolgatni. Ez utóbbi azért pöttyet jobban izzasztja a procit, mint amikor az adattal nem kell babrálni.
ráadásul ha már tesztelsz, akkor azt is érdemes átgondolni, hogy mit akarsz tesztelni? egy raid5 esetén ha olvasod az adatokat, akkor bármely adatblokk megvan valamely winyón, tehát minimális számítás után megvan az a winyó, ahonnan a blokkot beolvasva megvan a kért adat. na most tegyük fel, hogy egy winyó megdöglend - ekkor a redundancia ugrik, de adatvesztés nincs. viszont ekkor ha az adatot pont arról a winyóról kell bekapni, ami kiesett, akkor az macera, mert akkor be kell olvasni az összes winyó adatát, majd a cheksum és a többi adat alapján újra kell számolni, hogy mi volt az adat a kiesett winyón. megoldható, működik is - picit nagyobb az erőforrás igénye, mint amikor csak simán előveszem az adatot. csakhogy ezen a ponton tejesen más az erőforrás igénye egy jól működő raid5 tömb olvasásának és egy degradedben lévő raid5 tömb olvasásának.

De azt vágod, hogy ettől még a mérés elve nem kéne, hogy más legyen, csak az eredmény. Tudom, hogy mit csinálnak a különböző RAID szintek. Engem csak az érdekel, hogy ki szeretném mérni, hogy adott rendszeren, adott RAID típusnál mennyire CPU igényes a dolog. Durván fogalmazva: egy számra van szükségem, mint eredmény.

Akkor mégegyszer... Összefűzött diszkek, stripe-olt diszkek, illetve tükrözött diszkek esetén gyakorlatban nincs mit mérni CPU-ban (I/O, illetve DMA téren viszont igen), mert csak és kizárólag a metaadatokat kell feldolgozni írás/olvasás esetén egyaránt.
Ahol relevánsan fogyaszt CPU-t a raid, az a RAID5, illetve RAID6 írásnál, illetve sérült állapotban. Ezt tudod mérni a RAID-et kezelő folyamat által fogyasztott CPU-idő figyelésével.

Akkor viszont mi adhatja a különbséget a dd-futtatásánál RAID0-val és nélkül? _Elvben_ nincs mit mérni CPU-ban, de pont ezt szeretném igazolni. Hogy _gyakorlatban_ sincs. Úgyhogy a kérdés továbbra is fennáll.

Ugyanis ez az egész RAID0-történet egy elég gyenge CPU-erőforrású eszközre menne rá.

( szilas | 2016. 05. 12., cs – 14:20 )

Htop, iotop esetleg iostat. Ezekkel nagyjából kitalálható. Nem lesz egy egyenletes adatod, mert pl raid 5-ön az adat fajtája befolyásolja a számítási szükségletet (elvileg). Illetve illik ránézni a /proc-ban a korlátokra is.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Igen. Felfogtam. Htop pl azt (is) méri. És az átvitt adat menyisége/cpu foglalás értékét ezekkel ki tudnád következtetni. Mérni pontosan nem. Ahogy a kollegák írták, ez nagyon sok mindenen múlik, akár pillanaton belül is. De kezdem azt sejteni, hogy te csak egy konkrét parancssort vársz. Szerintem ilyet senki se fog mondani.

Egyébként gyenge gépre a raid 0/1 nem lehet gond. A raid 5/6-ot meg ha visszafogod /proc-ban, akkor rá lehet kényszeríteni kevesebb cpu időre. Csak a re-szinkron lesz fosatós ilyenkor. Sőt ezt vissza is szívom. Adatvesztés lehet belőle. (tehát szigorúan elméleti lehetőség)

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

( epab | 2016. 05. 12., cs – 15:16 )

Az [mdX_raidN] nevu processzek cpu hasznalatat /proc alol kiolvasni, ezt az adott tombre kiirt/rola beolvasott adattal osztani?

( fathom | 2016. 05. 12., cs – 16:05 )

Őszintén még RAID mérésre nem használtam, de amúgy bonnie++ képes kimutatni a felhasznált CPU időt fájlírás/olvasás esetén és elég sokféle teszt benne is van.

FathoM

Emlékeim szerint linux már 15 éve is tudott softraid-et az akkori gépeken, relatíve jó sebességgel. Ezek után a mai modern CPU-k azt a sebességet röhögve kellene h. bírják, főleg mivel h. a CPU-k teljesítménye nagyságrendileg kb. a 10-20x-ra nőtt (quad core, nagyobb FSB stb.), a mai diszkek meg jó ha 4-5x lettek gyorsabbak.
--
WP8.x kritika: http://goo.gl/udShvC

> Emlékeim szerint linux már 15 éve is tudott softraid-et az akkori gépeken, relatíve jó sebességgel. Ezek után a mai modern CPU-k azt a sebességet röhögve kellene h. bírják, főleg mivel h. a CPU-k teljesítménye nagyságrendileg kb. a 10-20x-ra nőtt (quad core, nagyobb FSB stb.), a mai diszkek meg jó ha 4-5x lettek gyorsabbak.

Mint n+2-szer írtam, ezt szeretnénk számokban is látni. Egy pillanatra, vagy legalább ebben a topicban felejtsd el a "vas mindenre elég" szemléletet.

nekem az a tapasztalatom (RAID-1 esetén), hogy a raid vezérlő mindkét lemezről olvas párhuzamosan, teljes sebességgel - uez mdraid-re nem igaz.
md esetén az olvasás picivel több, mint egy vinyó sebessége, hwraid esetén pedig nagyjából az összes vinyó sebessége összeadva. (nyilván azonos raid volume-on belül)

És már akkor is körberöhögték a normális hardveres raid-kontrollerek OS-oldali terhelés tekintetében :-P El kell/lehet dönteni, hogy cpu/memória/iops feláldozása árán akarsz-e spórolni egy raid-kártyányi pénzt, vagy sem, illetve hogy mindez majd üzemeltetési költségben hogyan fog jelentkezni (egy döglött diszk cseréje hw-raid esetében, hot-swap keretnél egy idomított csimpánzzal elvégeztethető, sw-es raid esetén azért ez nem ennyire triviális...)

ájjj beszép! :) Én a takarítónőt szoktam felhozni példaként: - "Margétnéne, a világító lámpa fölött tessék megnyomni a bordó színű gombot, a kiugró karral óvatosan húzza ki a páncélkazettát, majd a polcon lévő ugyanolyan kazettát, ugyanúgy élére állítva dugja bé' a likba, és lassan nyomja be kattanásig a kart a helyire" - kb. ennyi kommunikációval megoldható a hardveres része :)

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( wachag | 2016. 05. 12., cs – 18:01 )

Átfogalmazom, mert nem a kérdésre kapom a választ.
Van két disk. Írok rájuk, olvasok róluk. Külön. Hogyan tudom megmérni, hogy egységnyi adat átjuttatása mennyi CPU-t igényel? Akármilyen kicsi is.

Aztán ugyanezt a két disket RAID-be kötöm. Azoknak, akik ezen fennakadnak, legyen RAID5, a kedvenc paramétereikkel. Ugyanezt megmérem.

A cél: ennek a kettőnek az arányát megmondani. Lényeg: egy gyenge vason SW RAID (előző bekezdés) bekapcsolása fogja-e számottevően terhelni a processzort. Nem "szerintem nem", meg "nem kéne", hanem számot szeretnék mondani. Egy mérési elv, egy benchmark program neve érdekel. Ennyi.

Ennel azert letezik kulturaltabb modszer is... ;-) 

# dd if=/dev/zero of=disk0.img bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.000847337 s, 1.2 GB/s

# dd if=/dev/zero of=disk1.img bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.000813721 s, 1.3 GB/s

# losetup /dev/loop0 disk0.img

# losetup /dev/loop1 disk1.img

# mdadm -C /dev/md0 -n 2 -l raid1 /dev/loop[01]
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [raid1]
md0 : active raid1 loop1[1] loop0[0]
      960 blocks super 1.2 [2/2] [UU]

unused devices: <none>

# mdadm -G /dev/md0 -n 3 -l raid5 -f --backup-file=.backup
mdadm: level of /dev/md0 changed to raid5
mdadm: Need to backup 128K of critical section..

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [raid1]
md0 : active raid5 loop1[1] loop0[0]
      1920 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/2] [UU_]

unused devices: <none>

Lényeg: egy gyenge vason SW RAID (előző bekezdés) bekapcsolása fogja-e számottevően terhelni a processzort. Nem "szerintem nem", meg "nem kéne", hanem számot szeretnék mondani. Egy mérési elv, egy benchmark program neve érdekel. Ennyi.

Ez nem triviális, nagyon nem. Ugyanis nincs olyan mérési lehetőség a kernelben, hogy X művelethez mennyi cpu terhelés tartozik (és akkor az izgalmasabb részekkel nem is foglalkoztunk, mint pl. cache miss meg hasonlók következményei). Tehát igazából csak az egész gép teljes terhelését tudod nézni szumma.

Amit tehetsz:
- szigorúan üres gépet állítasz elő, amin semmi más nem fut (nincs X, nincsenek random daemonok, stb)
- lefuttatod a tesztet raid nélkül, aztán raiddel, aztán raid nélül, aztán raiddel, és így tovább, addig, amíg az egymást követő azonos setupok kellően közeli eredményt nem adnak (azaz be nem áll valami stacioner állapot), és akkor megnézed a különbséget a két utolsó mérés között.

Egyébként személy szerint teljesen feleslegesnek gondolom a méricsgélést: lassú gépen nem csinálunk RAID5/6-ot SW-ből (igazából gyors gépen sem csinálunk, mert egy kalap kaki), a RAID0/1 overheadjét meg simán el lehet hanyagolni.

Nyaljon sót - kap n darab diszket, és köze nincs hozzá, hogy azok fizikailag hogyan állnak össze. Ha van egy izmos storage, amiből fc-n osztod a tárterületet, akkor mit csinálsz?
A zfs alá nem tehetsz sw-raid-et, maradjunk annyiban, de a hw-es rétegben megvalósított redundanciához semmi köze nincs, és nem is lehet.

Tudom, viszont egy jól kialakított raid-kártya os-től, lvm-től, fs-től függetlenül elintézi neked a dolgot - ráadásul úgy, hogy nem vesz el sem i/o-ban, sem cpu-ban erőforrást az os-től. (nem mindegy, hogy egy blokk kiírása egy darab "ezt írd ki" művelet, és a read, read, xor, write műveletsort jelenti az os számára...)
A sw raid, az lvm-es tükrözés meg a zfs ezen tudása ugyanannak a feladatnak (redundancia növelése, elérhető diszkterület egyben láttatása, elérés gyorsítása a megbízhatóságban tett jelentős engedmény árán, stb) más-más megoldásai.

Zfs féle snapshotot mással nem tudsz csinálni. Nálunk ez volt a legfontosabb, a különféle cryptlocker nyalánkságok miatt. Az online tömörítés, quotázás már csak nyalánkság a torta tetején.
És ma már olyan procik vannak, h a hw raid kártya előnye ilyen szempontból _szerintem_ már csekély/nincs.

Nem csak a cpu-ban spórol a hardveres raid; nem mindegy, hogy egy blokk kiírása az i/o-t illetve a dma-t hányszoros adatmozgatással terheli (raid5 esetén kiírás során egy blokk helyett legalább három mozog, raid6 esetén meg minimum négy.). A snapshot, tömörített fs, illetve a deduplikáció olyan dolgok, amik alatt egyrész mindegy, hogy milyen storage van (mindegyiken tudják tenni a dolgukat), másrészt viszont nem mindegy, hogy a storage milyen iops-ot, mekkora rendszerszintű terhelés (i/o, dma, cpu) árán tud biztosítani.

Egy bazi nagy baja van nekije: rettentő nehéz redundánssá tenni. Mondhatni úgy is, hogy ehhez ki kell venni a gépből, át kell gyúrni egy dobozzá, amiben egy redundáns számítógéppár csinálja szoftverből a dobozba rakott diszkekkel azt, amit a "hardveres raid" csinált a PC-ben egy kártyán. Aka redundáns, intellligens külső tárolóeszköz.

amik alatt egyrész mindegy, hogy milyen storage van

Nem, amikor azt valakinek ki is kell fizetnie, akkor már hirtelen nem mindegy. Ha beraksz fölöslegesen egy snapshot alá egy tükrözött diszket, miközben ott arra nincs szükség (mert bármikor elő lehet állítani az adatot újból), akkor a kapacitás felét kidobtad, és ez ritkán szokott ingyen lenni. Az a "hardveres raid kártya" pedig elég ritka, ami egy diszkpár egyik felén tud csinálni RAID1-et, míg ugyanannak a diszknek a másik felét tükrözés nélkül is fel tudja használni.

> a RAID0/1 overheadjét meg simán el lehet hanyagolni

Ezt szeretném alátámasztani méréssel. Van/lehet az a hw környezet (pl. egy régebbi ARM), ahol ez már nem triviális. Eszköz hiányában szeretnénk megmondani, hogy egyáltalán van-e esély arra, hogy elbírja. Úgy néz ki, IO-ban jók leszünk, a CPU tűnik szűk keresztmetszetnek. (Amúgy az ügyben átjátszóállomás vagyok, kolléga kérdéseit továbbítom).

Nyilván lehet tesztelni - bár ebben esetben nyilván a célhardveren kell majd tesztelni (egy mai modern PC-n max. SSD-vel tudsz akkora I/O-t generálni, hogy az számottevő CPU-loadot generáljon az I/O oldalán).

Viszont továbbra is érdekesnek tartom, hogy egy gyenge gépen hogyan állítasz elő/dolgozol fel annyi adatot, aminek a ki-belapátolása egy rendes DMA-s csatornán sok energiát köthetne le.

> Nem érzel némi ellentmondást?

Pl. megvalósíthatósági tanulmány? Vagy te hogyan csinálnád?

> RAID1-nek nincs számítási igénye, mitől lenne a CPU szűk keresztmetszet?

Mint n+1-szer írtam, ezt szeretnénk számokban is látni. Egy pillanatra, vagy legalább ebben a topicban felejtsd el a "vas mindenre elég" szemléletet.

> RAID0-t meg minek használnál?

Pl. mert azt kérik, vagy azért mert négy (vagy n, tök mindegy) disket szeretnének egyben látni, redundancia meg nem igény. Teljesen irreleváns. Csak.

Függ az architektúrától (dma megvalósítása), hogy mérhető-e a terhelés. A raid0 esetében meg kérdés, hogy stripe vagy szimpla összefűzés lesz a tömb alatt? (Utóbbira példa Linuxban egy lv bővítése újabb pv-vel). És nem, nem mindegy, hogy hány diszk, pláne akkor nem, ha a dma illetve a diszkvezérlő "szuboptimálisan" lett megvalósítva.

A mérettől független biztosan nem fogsz ilyet kapni. Sőt a méret csökkenésével csak az segít, ha mondjuk 1000ből átlagolsz, aztán egy idő után már az se.

Mégegyszer. Kipróbáltam itthon a kiszerveren (RAID5) és bonnie++ megmutatja neked. Sőt extra, hogy nem nyers sebességeket mutat, hanem azt, hogy mennyi CPU-t vitt el, mire a fálj tényleg oda is lett írva...

FathoM

Ui.: Itt az output a laptopomről (ez mondjuk nem RAID):
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
northernligh 15432M 655 99 391146 30 161229 13 3588 99 349146 12 5606 77
Latency 17791us 739ms 490ms 5913us 30418us 4687us

De szerintem pont azt csinálja, amit akarsz. Megnézed külön és egyben. Profit.

( foci v | 2016. 05. 12., cs – 19:17 )

Fontos lenne:
Mivel hoztad létre a raidet?
Milyen raid mdam, lvm....?
Gabi

( LMoon | 2016. 05. 12., cs – 20:51 )

Virtualizáció alá 3 GHz körüli magoknál, AMD-n 4 magvas gépen egy maggal, intel esetén egy fizikai maggal szoktam számolni.
Így elég nagy a ráhagyás, de tuti elég.

( uid_6201 v | 2016. 05. 13., p – 00:24 )

Vajon mennyire szükségszerű, hogy terhelje a CPU-t és mennyire tudja a kernel a DMA kontrollerre tolni a feladat oroszlánrészét RAID0 és RAID1 esetén?

RAID5 már izgalmasabb kérdés, ott kell XOR-olni a memóriában a diszkekre DMA-zás előtt, de

[ 22.913899] xor: automatically using best checksumming function:
[ 22.952778] avx : 18958.000 MB/sec

Ez a XOR számítás vajon mennyire terheli 500 MB/mp írása esetén a CPU-t?

Egeszen hihetetlen ez a topic.

- Sziasztok! Sose adtam meg fel csomagot, de valszeg mostantol fogok. Van arra valami modszer, hogy megtudjam egy csomag A-bol B-be szallitasanak hozzavetoleges koltseget? Mittomen, vannak futarszolgalatok online arkalkulatorral? Vagy telefonalgatni kell? Otlet?

- Jo de honnan hova!?
- Meg nem tudom, csak ugy altalaban.
- Igen, de ha nagy a csomag...
- Miert, ha nagy akkor hogy csinalnad? Es ha kicsi?
- Ha nagy akkor sokba fog kerulni!
- Jo de hogy lehet megtudni, hogy adott esetben mennyi?
- Mondom draga!
- Vidd el kocsival!
- A posta ugyis ellopja!
- Manapsag mar senki nem ad itthon fel, mindent kinabol szallitanak!
- De ha hosszukas a csomag...
- Mondd meg a konkret allomasokat es csomagmeretet, mondok erzesre valamit. +- ket nagysagrend...
- Dehat mit erdekel, hogy mibe kerul!? Ha ertekes a cucc nem szamit a koltseg, ha nem ertekes ne is szallittatsd!
- A DHL-nek jobb kamionjai vannak, mint a bela'92 bt.-nek!
- A kerteszkedest javasolnam!
- Talan ez a logisztikai-arajanlatok.com oldal kozelebb visz. Nem tudom mennyire pontos es hogy mukodik-e kulfoldi csomagokra is. [a kb. 3 relevans valasz]
- De a posta mar szaz eve is szallitott csomagot!
- Az biztos, hogy sok lesz a vam es az afa!
- Azt nem tudom, de bringas futarral lassu lesz Miskolcra!
- A horgaszatot javasolnam!

------------------
Hogy erdemben is hozzaszoljak (szinten csak otleteles szintjen):

En fathom bonnie-s otletet es hg2ecz hozzaszolasat (http://hup.hu/node/147414#comment-1987574) egeszitenem ki:

Minimalis prioritassal futtatnek egy uniformizalt, szamitasigenyes feladatot, ami nem nyul a diszkhez (memoriaban levo/bekesselt 40 megas random file tomoritese pipeban 20-szor egymas utan?), annyi peldanyban parhuzamositva, hogy kitoltse az osszes cput/magot.

Ennek lefutasi idejet mernem, mikozben

A) a bonnie a softraid nelkul irna a cel blockdev-re

B) a bonnie ugyanerre a blockdevre a valasztott raid-en keresztul ir.

A bonnie-t magas cpu es io prioritassal futtatnam, hogy a IO cpu/mem/dma koltsege teljes mertekben megjelenjen, tulajdonkeppen a ket esetben a maradek cpu teljesitmenyt mered.

A maradek cpu teljesitmenyek aranya adja, hogy az adott platformon, adott raid tipusnal, adott blockdeven, adott csillagallasnal mekkora a raid tobblet koltsege.

Pl. raid nelkul 9 perc, raiddel 10 perc: 9/10=90%, tehat 10% a raid koltsege.

Termeszetesen ugy ertettem, hogy a bonnie-k is parhuzamosan futnak ugyanazokon a blockdev-eken, amikbol elotte/utana a raidet csinalja. Ha epp azt akarja tesztelni, hogy mibe kerul egy raid5 egy SSH tunellezett nbd-n, plusz egy LUKS titkositott iscsi lun-on plusz egy SATA-USB-LVM lancolaton, akkor azokon.

Bar igazad van, utana ennyi darab bonnie-t kell parhuzamosan futtatni a raiden is.

Ezzel viszont beleméri az mdraid IO overhead-et is, miközben csak a CPU overhead érdekli - amint a raid valódi raid-ként működik és nem 1 diszkkel, onnan már (workload függő) IO overheadje van.

A legegyszerűbb példa erre, hogy a raid5 random írás kb 20%-a lesz a független diszkek párhuzamos teljesítményének, aminek semmi köze a CPU overhead-hez.

"IO cpu/mem/dma koltsege teljes mertekben megjelenjen"
Nade ha jól értem pont ezt nem akarja. Vagy elvesztettem a fonalat. Ez alapján legalábbis azt sejtem, hogy neki a különféle raid szintek által okozott plusz cpu cycle kell, a többi sallang nélkül. Ami ugye ott bukik hogy egy disk vs. több disk, illetve más az írás-olvasás karakterisztikája a más-más raid szinteknek (hány disket kell olvasnia ha egy blokkot részben felül kell írni), ami a konkrét xor mellett bőven bekavarhat(*). Már ha jól értem az egészet.

*) Különösen ha pl. USB-s diskek vannak, bár ezt csak úgy vakon bedobtam, nem tudom hogy milyen hw-ra kell, de pl. egy PÍ biztos sokat törpölne csak az öt disk nézegetésével.

De ennek semmi értelme. Ha pl. van 3 lemezem stripe-olva, akkor (nagyon primitíven) x86-on két parancs (SHR, DIV), hogy megkapjam egy logikai blokk fizikai címét (eszköz EDX-ben, blokkszám EAX-ben), viszont egy régi ARM-on lehet, hogy egyáltalán nincs DIV, nemhogy modulus, és akkor jön a ciklikus kivonás és hasonló szépségek. A pipeline-ok számáról és a cache-ről még szó sem esett.
Innentől tök mindegy, hogy mi mit tesztelünk, ha egy általa is ismeretlen hardverre szeretné vonatkoztatni.

Ugy gondoltam, hogy mivel a linuxban nincs DTrace szeru instrumentalhatosag, ezert attetelesen kell kimerni a raid koltseget.

teljes szamitasi kapacitas = hatter folyamatok + x peldany bonnie futtatasa + raid kezeles + cpu/mem hasznalat kitolto folyamat

Mivel az egyenletben raid-del es raid nelkul is allando minden, kiveve az utolso kettot, ezert az utolso valtozasa egy-az egyben adja az utolso elottiet, a keresett erteket.

Vagy nem. En is csak otletelek, meg nem mertem ilyesmit.

Nincs..?

De hiába van ez is meg a perf, nem tudja mérni a teljes, valódi overhead-et, mert az a kernel több részén is jelentkezik, nem csak az mdraid driverben.

Legegyszerűbb példa, hogy pl a raid1 2 diszket dolgoztat, ami az IO pathot is kétszeresen dolgoztatja, ezzel máris olyan helyen okozva CPU overhead-et a szóló diszkes setuphoz képest, ami nem látszik ha csak az mdraid driverben töltött időt veszi górcső alá..

Azt tudtam, hogy valami van, de legutolso infoim szerint a solaris+dtrace-hez kepest meg nagyon kezdetleges. Mivel ez evekkel ezelotti info, akar elavult is lehet.

Es igen, ugyanaz a baj vele, mint a [md0_raid1] es tarsai process meresevel, necces osszecsipegetni a sok merendo dolgot.

Persze az is lehet, hogy meg lehet csinalni. Nem vagyok kernel guru, viszont egy dummy "hasznos folyamat" lefutasanak idejet meg tudom merni.

En ugy ertelmeztem a "mennyi CPU teljesitmenybe kerul" kerdest, hogy mennyi rendszerteljesitmenyt von el mas, "hasznos" folyamatok elol. Marpedig a "hasznos" dolgok szinte kivetel nelkul memoriat is hasznalnak, L2, L3 cache-ben tudnak maradni, ha mas ki nem szoritja oket, stb.

Egyebkent pedig nincs otletem, hogy hogyan mernem az uresjarat idejet, hogyan vennem szamitasba az esetleges valtozo cpu frekvenciat.

[ 22.913899] xor: automatically using best checksumming function:
[ 22.952778] avx : 18958.000 MB/sec

Ez a XOR számítás vajon mennyire terheli 500 MB/mp írása esetén a CPU-t?

A fenti példádra javaslom figyelmedbe az osztás műveletet: 500 MB/sec / 18958 MB/sec ~= 2.6 %. :)

:) köszi.

Bár a szintetikus teszt és a valós alkalmazás között mindig célszerű ráhagyni. Csak egy szempont: más xor-t számolni például

2 diszk --> +1 paritás
3 diszk --> +1 paritás

esetben. Utóbbiról belátható, hogy több xor lépést igényel azonos adatmennyiség diszkre írásánál.

Kimérés terén én azon gondolkozom, hogy számolnék valamit erőteljesen az összes magon és megmérném, hogyan alakul a kiszámítás ideje (elapsed time) diszkírási melléktevékenység nélkül és intenzív diszkírás esetén.
Ennek ideje jól adja, mennyit rabolt el a diszk alrendszer a számoló algoritmus elől és nem függök attól, hogy a top esetén mit számolt bele a kernel és mit nem számolt.