root@st01:~/iotest/cpu00_raid10# cat /proc/mdstat
Personalities : [raid10]
md127 : active raid10 sdak[35] sdai[34] sdaj[33] sdah[32] sdae[31] sdaf[30] sdag[29] sdac[28] sdad[27] sdaa[26]
sdab[25] sdz[24] sdw[23] sdy[22] sdx[21] sdu[20] sdt[19] sdv[18] sdr[17] sdq[16] sds[15] sdm[14] sdp[13] sdo[12]
sdk[11] sdn[10] sdl[9] sdj[8] sdg[7] sdi[6] sdh[5] sde[4] sdf[3] sdc[2]
sdd[1] sdb[0]
35163259776 blocks super 1.0 64K chunks 2 near-copies [36/36] [UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU]
unused devices: <none>
aztán, hogy mit is lehet olvasni erről.
root@st01:~/iotest/cpu00_raid10# dd if=/dev/md/md0 of=/dev/null bs=4M count=262144
262144+0 records in
262144+0 records out
1099511627776 bytes (1.1 TB) copied, 1174.93 s, 936 MB/s
hát ez alata maradt a kívánt 1GB/sec -nek, valamit tuningolni kell.
- egeresz blogja
- A hozzászóláshoz be kell jelentkezni
- 1063 megtekintés
Hozzászólások
a saját, erre az egy célra írt roppantul feltúrbózott aio() alapú multithread olvasási-teszterem 2600 mbyte/sec -cel olvas. Valahol a linux kernel rejtelmeiben kellene tunningolni, hogy egy szokásos 'while( fread() ) utility is hozza a formáját.
- A hozzászóláshoz be kell jelentkezni
man readahead esetleg? (Szabványabbul posix_fadvise(), POSIX_FADV_SEQUENTIAL ésvagy POSIX_FADV_WILLNEED hinttel.)
A Linux mdraid 10-nek nekifutottam itt, de ez most estére túl nagy erőfeszítést igényelne. Mindenesetre 64K-s chunk-mérettel és 36 diszkkel a 4 MB elég sovány dd blokkméretnek tűnik.
... Az mdadm manual-ja szerint a RAID10 default layout-ja "n2". Hm, a "man 4 md" szintén leírja, mi is az a RAID10. Ha jól látom, a "near" replikák a lehető leglassabbak szekvenciális olvasásnál.
- A hozzászóláshoz be kell jelentkezni
olyan kedves vagy. tenyleg.
most raid50 -nel tartok, a raid10 elsodleges celja az mdraid cpu terhelesenek megfigyelese volt egy egyszeru esetben.
es ugye kiesett, hogy hiaba a rengeteg diszk, olyan esznelkul hasznalva annak nem lesz nagy teljesitmenye.
- A hozzászóláshoz be kell jelentkezni
itt a raid10-ben hogy vannak a diskek? 6x6? 9x4? 18x2 :) ?
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
linux raid10 implementáció, ami single layer, nem pedig raid1+raid0.
mdadm --create md0 --chunk=64 --metadata=1.0 --level=raid10 -n 36 `awk '/1953514584/{print "/dev/" $4}' /proc/partitions `
- A hozzászóláshoz be kell jelentkezni
nem olyan egyszerű ez a raid50.
Hogyisvanez.
5 diszkes raid5; blocksize=64k, 4 adatblock utan jon egy parityblock.
Akkor egy teljes stripe=4block=256k
Ha ilyeneket ezt fuzok raid0 -ba, akkor a raid0 blockmerete ertelmesen 256k tobbszorose, most 512k.
tehat iraskor ket teljes raid5 stripe kerul ki egy raid5 -be, es csak utana lep a kovetkezo raid5-be.
7 ilyen raid5 van, tehat a raid0 teljes stripe=7block=3584k
Namarmost, ah bufferelve 4k -val irok ki, akkor is olvas a raid5 dizkekrol, megpedig (elvileg) csak akkor olvas, ha nincs eleg adat kiirni az egesz raid5 stripe -t (256k) marpedig elegnek kell lennie, hiszen a raid0 blockmerete ennek tobbszorose
hm, hm
- A hozzászóláshoz be kell jelentkezni
1.0 raid superblock a default 1.2 helyett?
mdadm --create /dev/md50 --level=0 -n 7 --metadata=1.0 /dev/md{121,122,123,124,125,126,127}
ugyanaz a jelenseg, hm, hm,
- A hozzászóláshoz be kell jelentkezni
nem nyert
- A hozzászóláshoz be kell jelentkezni
Lacosnak ajanlva :-)
van egy sima, 5 diszkes raid5 device. A szekvencialis irasi teljesitmenyevel van problemam.
Itt egy jellemzo 'sar -d -p 3' kimenet-reszlet:
09:57:01 AM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
09:55:10 AM sdb 141.67 74.67 90322.67 638.10 3.09 21.80 6.15 87.07
09:55:10 AM sdd 146.00 90.67 90488.00 620.40 2.54 17.38 5.89 86.00
09:55:10 AM sdc 139.00 146.67 89325.33 643.68 3.05 21.48 6.74 93.73
09:55:10 AM sde 140.00 104.00 90794.67 649.28 2.88 21.07 6.14 86.00
09:55:10 AM sdf 132.33 101.33 90112.00 681.71 3.17 23.94 7.08 93.73
jol latszik, hogy az iras mellett folyamatos olvasas is van. A raid5 iraskor akkor olvas, ha nem egy egesz stripe kerul ki a diszkre. Nehany blockot ki kell olvasni, hogy megallapithato legyen az uj parity block.
(ha teljes stripe kerul kiirasra, akkor a parity block is teljes felulirasra kerul, nem kell beolvasni semmit). Ilyet produkal minden bufferelt iras, a dd is, es a sajat teszteloprogramom is, minden.
Itt pedig egy "jo" 'sar -d -p 3' kimenet-reszlet:
09:57:01 AM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
10:00:34 AM sdb 1282.33 0.00 228992.00 178.57 7.49 5.85 0.76 96.93
10:00:34 AM sdd 1286.00 0.00 228293.33 177.52 6.72 5.22 0.75 96.67
10:00:34 AM sdc 1280.33 0.00 228138.67 178.19 6.52 5.08 0.75 96.13
10:00:34 AM sde 1296.67 0.00 228565.33 176.27 6.76 5.21 0.73 95.07
10:00:34 AM sdf 1295.00 0.00 228053.33 176.10 7.71 5.94 0.76 98.13
lenyegesen nagyobb irasi teljesitmeny lathato ugyanarra a raid5 tombre.
Ez a "jo" helyzet akkor all fenn, ha az alabbiak egyuttesen:
1) okos irassal kikapcsolom a bufferelest (O_DIRECT)
2) pontosan stripe-size (4*64k=256k) blockokat irok ki
3) az egyszerre kikuldott anyagmenyiseg (outstanding writes; "irasi szalak") akkora, nem haladja meg a /sys/block/md0/md/stripe_cache_size erteket. Ami 16KiB mertekegysegben van (tapasztalat)
Ha meghaladja (vagyis, ha nem fer bele) akkor a teljesitmeny elromlik.
Maramost bufferelt (normal) IO eseten az irando anyag szinte minden merteket meghalad, es nem varhato el minden programtol, hogy okosan ir.
- A hozzászóláshoz be kell jelentkezni
A
stripe_cache_size-ra nyomtam egy duckduckgo-t; valamelyik első találat: https://inkhornnet.wordpress.com/2010/06/06/io-performance-and-stripe_c…
Eszerint a
stripe_cache_sizekézzel állítható, másrészt (ld. a blogposzt alatti kommentben) a növelésével az egyik csóka megötszörözte az írási teljesítményt.
(Persze lehet, hogy pont arra utaltál, hogy általános esetben még ez sem elég.)
Valamint az mke2fs-nek megnézted az
-E strideés az
-E stripe-widthkapcsolóját? Az utóbbi doksija például ezt mondja:
This allows the block allocator to prevent read-modify-write of the parity in a RAID stripe if possible when the data is written
Ebből valami olyat sejtek, hogy a megfelelő blokkolást az alkalmazás ráhagyhatja az ext[234] driver-re. A konkrét értékeket tekintve, legalábbis ha jól értem a leírást: 64 KB-os chunk size-od van, ami 4 KB-os fs blokkban kifejezve
-E stride=16, ill. 4 adatdiszk,
-E stripe-width=64.
Esetleg XFS... :)
Szerk.: itt is van valami; ez legalább eszembe juttatta a
blockdev --setraparancsot.
- A hozzászóláshoz be kell jelentkezni
az a baj, hogy hét ilyen raid5 kapna a feje fölé egy raid0 -át.
Talán ez se baj, de szertném érteni, mi hol, miért romlik el.
Ez valami agyatlan hülyeség, hogyha az md helyesen kiszámítja az optimal_io_size értéket, akkor a queueing rendszer miért nem úgy eteti.
Jövőhéten foly.köv vadiúj kernellel, és a lustre patchek boncolgatásával.
Köszönöm a látogatásod :-)
- A hozzászóláshoz be kell jelentkezni
... nézd meg a blktrace csomagot. Nekem nem segített (valami másban), de hátha neked fog :)
- A hozzászóláshoz be kell jelentkezni