Výkon iSCSI přes ethernet, optimalizace

[Fox!MURDER]

Aha, dobrý tip, tak na tom Atom není taky tak zle.

[    2.832149] raid6: int64x1    323 MB/s[    2.900076] raid6: int64x2    507 MB/s
[    2.968034] raid6: int64x4    595 MB/s
[    3.036042] raid6: int64x8    713 MB/s
[    3.104057] raid6: sse2x1     619 MB/s
[    3.172041] raid6: sse2x2    1128 MB/s
[    3.240027] raid6: sse2x4    1981 MB/s
[    3.240032] raid6: using algorithm sse2x4 (1981 MB/s)

Jinak včera jsem si s tím hrál už na gigabitu (přes FTP, SMB i iSCSI) a mám tam nějakej větší problém, asi špatnej kabel či co, každopádně si to dělalo úplně co chce... občas kolísalo kolem 10MB/s a pak nějak padlo na rychlosti kolem 4MB/s... laboroval jsem ale i s MTU, takže bůh ví, co jsem domrvil

Takže další krok bude pořízení slušné kabeláže. Zajímavé ale bylo, že switche nehlásí žádné errory na linku a spojí se na 1000/FDX.

OS taky nehlasi zadne errory na te lince?

Jinak zlate pravidlo MTU je, ze musi byt uplne stejne na vsech strojich v segmentu.

[frelichl]

Nemuzu rict, ze bych tomu zrovna rozumnel, ale vsechna mereni vykonu XORu (pro RAID) anebo rychlosti sifrovacich algoritmu (pro TrueCrypt etc.) mi pripadaji velmi malo vypovidajici. Zasadni rozdil je imho v tom, ze neni prakticky mozne pouzit DMA. V normalim modu mate nejaky blok pameti, ktery potrebujete dostat na disk, procesor zinicializuje prenos a zbytek se dodela sam, neni nutne protocit vsechna data pres procesor.

V momente, kdy nad temi daty potrebujete spocitat XOR nebo v horsim pripade je zasifrovat nutne musite vsechno pres procesor propasirovat a rozhodne to nemuze fungovat tak, ze CPU spocita XOR pro vsechna data najednou tou rychlosti, kterou si muzete zmerit, pak je hotovo a jede se jako normalne. IO operace jsou vyrazne pomalejsi, bude tam hodne, hodne context-switchu a ve vysledku bude procesor castecne zaneprazdneny danou IO operaci po celou jeji dobu. Vyvedte me nekdo prosim z omylu, ale presne takhle si ja vysvetluju, ze laptop se sifrovanym diskem je citelne pomalejsi nez ten s nesifrovanym diskem, at jsou testy vykonu ohromujici jak chteji.

Mluvim samozrejme softraidu a softsifrovani...

[Fox!MURDER]

...

takhle by to bylo, pokud by nad tim nikdo vubec nepremejslel a udelal to nejjednodussim zpusobem ...

jinak ale staci obetovat trochu pameti na buffery a neni problem ...

viz. zapis na

Cipher name:    aes
Cipher mode:    xts-essiv:sha256
Hash spec:      sha512

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00    0.00  475.00     0.00   211.21   910.64     0.26    0.55    0.00    0.55   0.47  22.50
dm-0              0.00     0.00    0.00  475.00     0.00   211.21   910.64     0.22    0.46    0.00    0.46   0.39  18.70
sdc               0.00     0.00    0.00  557.00     0.00   247.74   910.91     0.30    0.54    0.00    0.54   0.45  25.10
dm-0              0.00     0.00    0.00  557.00     0.00   247.74   910.91     0.26    0.46    0.00    0.46   0.39  21.60
sdc               0.00     0.00    0.00  495.00     0.00   220.21   911.11     0.28    0.56    0.00    0.56   0.47  23.30
dm-0              0.00     0.00    0.00  495.00     0.00   220.21   911.11     0.23    0.47    0.00    0.47   0.40  19.80

----total-cpu-usage---- ---system-- ---io/sdc-----io/dm-0-- --dsk/sdc-----dsk/dm-0-
usr sys idl wai hiq siq| int   csw | read  writ: read  writ| read  writ: read  writ
  0  83   0  15   0   3|4592  3045 |   0   507 :   0   507 |   0   225M:   0   225M
  0  96   0   2   0   2|4728  1249 |   0   619 :   0   620 |   0   275M:   0   275M
  0  78   0  21   0   1|5363   881 |   0   486 :   0   488 |   0   217M:   0   217M
  0  78   0  21   0   1|5379  1033 |   0   479 :   0   477 |   0   212M:   0   213M

context switchu tam moc neni a preruseni taky ne (vzhledem k tomu, ze 4000 je klidovej stav pri 4 CPU a HZ=1000 kernelu)
HW: 1x Xeon E5504, Areca 1680, 5x2TB WD2002FYPS RAID6, 6GB RAM

(samozrejme se jedna o velmi jednoduchej test-case - sekvencni zapis na fs)
(ty vypisy jsou chycene v rozdilnych casech - jsou spis informativni, nez aby mely velkou vypovidaci hodnotu)
(zkusim jeste najit nezatizenej sw raid5/6 ...)

A nemuzu ted narychlo najit benchmark kernelove implementace AES256-XTS, ale pro obrazek rychlost OpenSSL implementace AES-256-CBC pri vyuziti vsech 4 jader (kernel ma AES implementovany v assembleru a tim padem o neco rychlejsi).

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc     171594.18k   179896.87k   182058.07k   182586.71k   182591.49k

btw. marty - nahod komplet konfigurak ietd ...

[frelichl]

Fox: jasne, nerikam, ze je to udelane tak hloupe, ale princip je jasnej: vsechno musi projet pres registry procesoru, ze to jde udelat blokove je samozrejme podstatna optimalizace, ale jde to vzdycky delat po rozumnych blocich?

HollyG: nerikam, ze je to v prumernem pripade extra pomalejsi, ale jsou situace, kdy notebook se sifrovanym diskem bezpecne poznam. Ale taky samozrejme zalezi na konkretni implementaci, specialne ta, co mam na pracovnim notebooku mi pekne pije krev.

[Fox!MURDER]

Fox: jasne, nerikam, ze je to udelane tak hloupe, ale princip je jasnej: vsechno musi projet pres registry procesoru, ze to jde udelat blokove je samozrejme podstatna optimalizace, ale jde to vzdycky delat po rozumnych blocich?

HollyG: nerikam, ze je to v prumernem pripade extra pomalejsi, ale jsou situace, kdy notebook se sifrovanym diskem bezpecne poznam. Ale taky samozrejme zalezi na konkretni implementaci, specialne ta, co mam na pracovnim notebooku mi pekne pije krev.

ono ani tak neni problem v rozdeleni do bloku ... koneckoncu to v blocich musi byt vzdy.
problem je v tom, ze kdyz to nemas v blocich, musis precist co uz na disku je, zmenit to, co zmenit chces a zase to zapsat (a to plati jak pro raid - problem pri velkem stripe, tak pro sifrovani - tam bloky nastesti nejsou tak velke)
a nakonec, marty ma problem i se ctenim a to v raid5 skrz cpu projit nemusi ...

[HollyG]

Ja tedy notebook s sifrovanym diskem pouzivam a ze by byl nejak extra pomalejsi to mi neprijde

[Marty]

OS taky nehlasi zadne errory na te lince?

Ověřím.

Jinak zlate pravidlo MTU je, ze musi byt uplne stejne na vsech strojich v segmentu.

Co na to switche? Když nastavím nějakou velkou velikost, a switch to nebude umět, co se stane?
Hledal jsem hledal a můj hlavní switch (v routeru Edimax BR6574n) to snad i umět má (ač jsem tu kdysi tvrdil něco jiného).
Trochu mi v tomto tématu chybí teoretický základ, takže budu muset trochu nastudovat, vo co jde.
(jak je to s hlavičkou, kolik má bajtů? 14 nebo kolik?)

btw. marty - nahod komplet konfigurak ietd ...

marty@tix:~$ sudo cat /etc/iet/ietd.conf | grep -v \#

Target iqn.2003-08.net.myslenka.grisu:vFile1
        Lun 0 Path=/mnt/data/volumes/iscsi_hdd_01.img.backup,Type=fileio,IOMode=ro

Target iqn.2003-08.net.myslenka.grisu:CDs
        Lun 0 Path=/mnt/data/volumes/ubuntu-11.04-desktop-amd64.iso,Type=fileio,IOMode=ro
        Lun 1 Path=/mnt/data/volumes/win7x64.iso,Type=fileio,IOMode=ro

Target iqn.2003-08.net.myslenka.grisu:InstXP
        Lun 0 Path=/mnt/data/volumes/iscsi_hdd_02.img,Type=fileio,IOMode=wt

Target iqn.2003-08.net.myslenka.grisu:vFile3
        Lun 0 Path=/mnt/data/volumes/iscsi_hdd_03.img,Type=fileio,IOMode=wt

[Fox!MURDER]

Jen tak bych zkusil u nejakyho targetu nastavit

InitialR2T no
ImmediateData yes
MaxRecvDataSegmentLength 262144
MaxXmitDataSegmentLength 262144

popripade

IOMode=wb

pokud budes resit zapis ...

co se MTU tyce, tak to je dylka segmentu, takze hlavicky neres (pokud nepouzivas VLANy) ...
pokud mas na strojich vetsi mtu, nez umi switch, tak nejspis proste neprojdou, resp. dojdou poskozeny. (tipuju, hadam zavisi kus od kusu)
pokud mas na ruznych strojich ruzne mtu v jednom segmentu site, tak je dost mozne, ze ti napr. filetransfery budou fungovat jen jednosmerne, pricemz ping se bude zdat ok.
btw. jsi si jisty, ze to ten edimax umi? ted jsem narychlo nenasel nic, co by tomu nasvedcovalo, resp. urcite ne s orig firmware ... nejspis i proto, ze vetsinou se wifi k ethernetu bridguje a to by s velkym mtu asi fungovalo spatne ...

[Marty]

Dík moc.
S tím nastavením MTU mě mátlo, že ve Win ovladači Atherosí síťovky v desktopu byl defaultní údaj 1486, zatímco na NASu v linuxu to je 1500 (tj. odhaduji, že na Win to ovladač bere bez hlavičky).

V současné době mám v segmentu víc zařízení - bude problém, když budu testovat různá nastavení (MTU) jen na dvou z nich? Z toho, co jsi psal, mi přijde, že to musí být nastaveno i na ostatních zařízeních, i když s nimi nekomunikuji...

Jinak asi to udělám tak, že NAS na čas vezmu a přemístím ho desktopu, abych eliminoval i problém délky a/nebo kvality kabelu...

S tím edimaxem si jistý vůbec nejsem, a jak jsem zmínil, jsem nakloněn výměně... jen vybrat něco vhodného, viz jiná diskuze Zatím jsem se k tomu neodhodlal/nedokopal. (čím dál víc mě tam visí myšlenka pouze drátového routeru a malého samostatného APčka.

[Fox!MURDER]

Dík moc.
S tím nastavením MTU mě mátlo, že ve Win ovladači Atherosí síťovky v desktopu byl defaultní údaj 1486, zatímco na NASu v linuxu to je 1500 (tj. odhaduji, že na Win to ovladač bere bez hlavičky).

V současné době mám v segmentu víc zařízení - bude problém, když budu testovat různá nastavení (MTU) jen na dvou z nich? Z toho, co jsi psal, mi přijde, že to musí být nastaveno i na ostatních zařízeních, i když s nimi nekomunikuji...

Jinak asi to udělám tak, že NAS na čas vezmu a přemístím ho desktopu, abych eliminoval i problém délky a/nebo kvality kabelu...

S tím edimaxem si jistý vůbec nejsem, a jak jsem zmínil, jsem nakloněn výměně... jen vybrat něco vhodného, viz jiná diskuze Zatím jsem se k tomu neodhodlal/nedokopal. (čím dál víc mě tam visí myšlenka pouze drátového routeru a malého samostatného APčka.

Pokud si to spravne pamatuju, tak je IP hlavicka 16B ... a ethernetovej frame pobere tech 1500B ... takze nevim, co je 1486 ...

Mno, jinak receno, kazde dve zarizeni, ktere spolu maji komunikovat musi mit stejne MTU. Tj. pokud ti ty dve zarizeni komunikuji jen mezi sebou a s nicim jinym, tak to vadit nebude. (pokud mas NAS a Desktop 9000, server 15000 a router 1500, tak spolu budou bezproblemove komunikovat jen NAS a Desktop)

[Marty]

Jasan, to jsem si myslel.
Jinak hlavička má od 20 do 24 bytů... chjo

[Marty]

Takže aktuální stav k ladění... přesunul jsem všechen HW na jeden switch a hraju si s tím, nicméně ani přes NFS/FTP/SMB se nedostanu přes nějakých 35-40 MB/s. Na discích v NASu je přitom slyšet, že hrábnou jednou za 5 vteřin, ne-li méně často.

Takže budu se teď chvíli zabývat identifikací úzkého hrdla a pak se vrátím k iSCSI...