ZFS - rettenetesen lassu

Naplózó filerendszerek (journaling)

Immaron majdnem egy hete hasznalok a Fedora Linux 17-et futtato laptopom kozos tarhelyen ZFS-t. Mukodik is, teljesen jol, minden faja, egy gondom van: borzalmasan lassu az olvasas rajta. Mintha nem lenne mogotte meg disk cache sem.

Jelenleg egy 2.10GHz -re hitelesitett i3-mal es 4G RAM-mal ellatott Lenovo G570-en fut egy Samsung winyon a cucc, es erzesre ket-haromszor lassabb olvasasom van rajta, akkor is, ha olyan fajlokat olvasok fel, amiket mar egyszer felolvastam. Konkretan: most par napig egy darab Rails projekten dolgoztam, relative keves fajlt modositva (a betoltott fajlok szamahoz kepest keveset), es a konzol meg ket egymas utani inditasnal is bunlassu volt, pedig tapasztalatbol tudom, hogy altalaban a masodik inditasra mar nem kell szinte egyaltalan varni ra.

Igazabol nem tudom, mit merjek, hogy teszteljem a dolgot. Azt tudom, hogy a disk, ami benne van, nem egy gyors darab - de hat elvben errol szolna a disk cache, hogy ezt megoldja, nem?

Mas: van olyan verzio a ZFS-bol ami tamogatja az inotify-t? Egy kazal minden epitene erre a kernelszolgaltatasra, de minden csak nyivakol, hogy ezt a fajlrendszert o nem ismeri, es nem is tudja rajta elerni az inotify szolgaltatast.

  • 8548 megtekintés

( deje | 2013. 03. 19., k – 11:49 )

Mit jelent az, hogy "közös tárhelyen"? Hálózat, vagy multiboot esetén a közös partíció, vagy mi?

Legjobb tudomásom szerint a linuxos ZFS driver még messze nincs kész, az eredeti ZFS kódot megnyitotta a Sun/Oracle, de BSD licensz alatt, az meg nem jó a linuxnak - újra kell írni.

Konklúzió: Linuxon NE használj ZFS-t. Amúgy sem laptopra való, hanem szerverbe, a RAM igénye is jelentős. Ha hálózati ZFS cucc van, akkor meg NFS-en vagy Samba-n keresztül érd el.

Multiboot, OS X + Linux kozos particio, de eddig csak Linux mountolta.

Mar egyszer volt rola szo, halozatos megosztas nem megoldas, mert folyamatosan kell (akkor is, ha nem otthon vagyok), Ext driver csak nyugosen mountolhato irhatora OS X alatt (nem automata), a HFS meg Linux alatt instabil, mint allat. Egy sleepet nem bir ki tisztessegesen, regebben egyszeruen csak elcrashelt a gep a sleepbol feljovetel utani 2-5 oraban, mostanaban mar csak fsckzni kell idonkent, neha 1-2 logfajl eltunik, semmi komoly. Ironikus felmosoly.

Az NTFS-sel meg az a nyugom, hogy VirtualBox is futna ezekrol a particiokrol, es tapasztalatom szerint azt a linuxos NTFS-3G nem igazan birja, illetve birja, csak epp a gep a rajzolt lajhar sebessegere gyorsul fel, illetve le.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( kisg v | 2013. 03. 19., k – 12:14 )

A teljesítménygondhoz nem tudok hozzászólni, inotifyt megnéztem:

Ubuntu 12.04, zfs verzió: 0.6.0.71-0ubuntu1~precise1


$ touch xxx
$ inotifywait -m xxx &
$ touch xxx
xxx OPEN
xxx ATTRIB
xxx CLOSE_WRITE,CLOSE
$

( tompos v | 2013. 03. 19., k – 13:56 )

En javasoltam neked a zfs-t, de sajnos ilyen formaban nem tudok neked segiteni, mivel ilyen desktop kornyezetben sosem hasznaltam.

Mindenesetre pl. az atime-ot kapcsold ki, bar bizatosan nem ez a gondod.

Azt javaslom, hogy irja a zfs-discuss@zfsonlinux.org levlistara es ott segiteni fogjnak neked (tenyleg segitokeszek).

udv,
tamas

( W3ber | 2013. 03. 19., k – 22:52 )

Leírhatnád mit mérsz raw disk sebességre,és mit mérsz ha ugyanezt zfsen ajánlod ki.
Io-performance
Milyen Os-en méred?:)(Zfsonlinux?)
zpool iostat 10 ?top?

RAW disket nem tudok merni - ertelemszeruen, mert nincs szabad particiom. Az jo, ha ext3-on merek?

Szerk: ok, olvastam a megszerkesztett postot is. Fedora 17, ZFS on Linux.

Szerk 2: ide folyamatosan fogom feltolteni az infokat.

zfs iostat (a 10 ?top? parametereket nem tudta ertelmezni): 


               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
stuffz      14,9G  78,1G      0      1  16,3K  63,3K

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

#top (összevetve io művelettel.)
#zpool iostat -v 10 (10 masodpercenkent vesz mintat)
Megnézem neked virtuális gépen mit mérek.
Update1:Freebsdn mérve. 


root@server:/dataset # /usr/bin/time -h dd if=/dev/zero of=sometestfile bs=1024 count=10
10+0 records in
10+0 records out
10240 bytes transferred in 0.000680 secs (15059493 bytes/sec)
        0.00s real              0.00s user              0.00s sys
root@server:/dataset # /usr/bin/time -h dd if=sometestfile of=/dev/null bs=1024 count=10
10+0 records in
10+0 records out
10240 bytes transferred in 0.000303 secs (33792032 bytes/sec)
        0.00s real              0.00s user              0.00s sys
root@server:/dataset #

Update2:Fedore 17 telepítés alatt.

Nekem az altalad adott adat tul gyorsan lefutott, igy kicsit nagyobb fajllal tesztelek... 


$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   7526 MB in  2.00 seconds = 3765.91 MB/sec
 Timing buffered disk reads: 322 MB in  3.00 seconds = 107.18 MB/sec

$ echo WRITE TEST; time dd if=/dev/zero of=sometestfile bs=1M count=100 oflag=sync ; echo READ TEST; time dd if=sometestfile of=/dev/null bs=1M count=100 oflag=sync
WRITE TEST
100+0 beolvasott rekord
100+0 kiírt rekord
104857600 bájt (105 MB) másolva, 5,37096 mp, 19,5 MB/s

real	0m5.375s
user	0m0.002s
sys	0m0.089s
READ TEST
100+0 beolvasott rekord
100+0 kiírt rekord
104857600 bájt (105 MB) másolva, 0,0218035 mp, 4,8 GB/s

real	0m0.025s
user	0m0.000s
sys	0m0.024s

Ezek kurva jo adatoknak tunnek, de nem tudom, hogy a zfs nem erzekeli-e a /dev/zero -val valo tesztet. A valodi sebesseg ennel sokkal kevesebbnek erzodik

Csak egy momentum: az elobb epp egy Ubuntu Precise virtualis gepet probaltam uptodate allapotra hozni, es az updatek kb. egy ora alatt akartak lejonni egy alapvetoen 50MBites kapcsolaton, parszaz meganyi update. Irrealis.

A bonnie++ telepites alatt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem tudom rendesen stracelni, mert kismillio fajlt olvas fel, a felet nem is errol a partiorol.

Opciokkal? Oszinten szolva nem hasznaltam semmi extrat. zpool create stuffz, zfs create stuffz/projects talan. Talan megadtam a mount pointot is, de ennyi, nem is tudom, hogy a zfs-nek egyaltalan milyen opciokat lehet atadni.

A HDD particionalasa ugy nez ki, hogy ez a particio egy logikai cucc, sda8 vagy sda9 most fejbol meg nem mondom neked. Semmi extrat nem vittem bele.

Itt egy bonnie kimenet a ZFS-rol, bar nem birtam kivarni, es az ext3 cuccrol elinditottam egy filmet. Ha kell, ejjel meg merek egyet film nelkul. 


Version  1.96       ------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
darkstar.hron.me 8G    84  84 49435  13 20859   8   242  98 56329   7  66.1   2
Latency             94300us    7193ms    7761ms     110ms    4763ms   16267ms
Version  1.96       ------Sequential Create------ --------Random Create--------
darkstar.hron.me    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  9594  59 +++++ +++ 15271  82 14851  88 +++++ +++ 12684  62
Latency             41056us    1116us    1209us   55352us     118us     193us

A listaban talaltam egy txg_sync -es szalat, de nalam az a processz meg sem jelenik.

Furcsa amugy. Most ugyanaz az Ubuntu Precise upgrade nagysagrendekkel gyorsabbna lefut. Mintha valamitol fuggne, hogy lassu, de igazabol semmi nem fut a hatterben, ami a zfs-t bokdosne, vagy akar a disket.

Nem tudom, mi lehet a nyug, sajnos en ehhez a reszehez mar hulye vagyok. Ezert is kertem segitseget.

Szerk mittudomenmennyi: csinaltam zpool iostat merest az ubuntu upgrade kozben, gondolom, az eleg eroteljes. 


pool                                              alloc   free   read  write   read  write
------------------------------------------------  -----  -----  -----  -----  -----  -----
stuffz                                            15,2G  77,8G     32     52  4,07M  5,27M
  ata-ST500LM012_HN-M500MBB_S2U3J9AC706093-part8  15,2G  77,8G     32     52  4,07M  5,27M
------------------------------------------------  -----  -----  -----  -----  -----  -----

                                                     capacity     operations    bandwidth
pool                                              alloc   free   read  write   read  write
------------------------------------------------  -----  -----  -----  -----  -----  -----
stuffz                                            15,3G  77,7G     43     73  5,39M  7,10M
  ata-ST500LM012_HN-M500MBB_S2U3J9AC706093-part8  15,3G  77,7G     43     73  5,39M  7,10M
------------------------------------------------  -----  -----  -----  -----  -----  -----

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Tehat a /etc/modprobe.d ala kell ezeket beirni?

Illetve melyiket ajanlod? Tenyleg hulye vagyok ezekhez...

Valamint: meg lehet nezni, hogy most mennyi? A /sys/ alatt tobb valtozo is elerheto, ami FreeBSD-n is, igy ha azt mondod, lehet, hogy eleg nekem.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem, ezt a zpool létrehozásakor adhatod (?*) csak meg; utóbb nem változtatható meg. Ellenőrizni a jelenlegit a 'zdb' kimenetéből tudod.

*Solarison nem támogatott, de van hozzá olyan bináris (zpool), amit jótét lelkek megpatkoltak és az hardcoded ashift=12-t tartalmaz. A derivatívok némelyike állítólag már tud ilyet paraméterként.

/etc/lib/lu/plugins/lupi_bebasic

Nem ZFS-nél ugyan, de tudtommal nem okoz gondot, ha egy 512byte-os szektorral rendelkező lemezt 4k aligmenttel partícionálunk, ugyan olyan, mintha 512byte-ra lenne igazítva. Gondolom itt is meg lehet csinálni, hogy mindig fixen ashift=12 van. Főleg ha néhány rendszeren fixen 12 az értéke.

Tekintve, hogy a Windows keptelen a ZFS kezelesere, ez viccesen nezne ki, ezen felul az OS X sem kepes gyokerrendszerkent elkezelni a ZFS-t.

A szektormeretre: az fdisk 512 / 4096 logical / physical aranyt ir ki, nem tudom, ebben mennyire lehet megbizni?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

100-116 IOPS nagyon sok egy diszknél.
Ez kb. ennyit tud.

Annyit még megemlítenék, hogy a zfs alapból 128k blokkmérettel dolgozik (legalábbis Solaris-on, de valószínűleg linuxon is ez a default), ami nagy mennyiségű adat, kicsi fájlok és random io esetén jelentősen rontja az olvasási teljesítményt.
Érdemes megmérni valamivel az átlagos IO méretet, és ahoz igazítani a ZFS blokkméretét.

Még valami: dd-vel teljesen felesleges bármit mérni, hacsak nem kimondottan nagy IO méretű szekvenciális IO teljesítményére vagyunk kiváncsiak. Irodai file szerver, desktop, adatbázis szerver esetén tipikusan kis blokkméret random IO-ja van.

dd: Tudom, csak megis valami szamot ad

Igen, ez igy soknak tunik, es exten is valami hasonlot mertem. De nem is a mert ertekekkel van a baj, hanem azzal, hogy mintha nem letezne a disk cache vagy a fajlrendszer cache fogalma. Nem tudom elhinni, hogy egy ./script/console ket _egymasutani_ meghivasa pontosan ugyanolyan bunlassu legyen, es legalabb ketszer, de inkabb haromszor lassabb mint a szar, ganyolt, reverse-engineered HFS-en. Ezt nem tudom elfogadni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal