Výkon iSCSI přes ethernet, optimalizace

[Gargamel]

Neco mi rika, ze SW RAID5 nebude levna zalezitost co do vyuziti CPU...

[Marty]

Neco mi rika, ze SW RAID5 nebude levna zalezitost co do vyuziti CPU...

I při čtení? Při zápisu souhlas...

[monsoon]

Zase tak hrozné to není, při startu se testují různé algoritmy a do 8GB/s mám ještě pěknou rezervu.

[    1.208020] raid6: sse2x4    6435 MB/s
[    1.208027] raid6: using algorithm sse2x4 (6435 MB/s)
[    1.208662] xor: automatically using best checksumming function: generic_sse
[    1.228014]    generic_sse:  8053.000 MB/sec
[    1.228020] xor: using function: generic_sse (8053.000 MB/sec)

hw viz podpis: Intel(R) Pentium(R) Dual CPU E2200 @ 2.20GHz

[Marty]

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.

[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 ...

[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 ...