Lassú ZFS

Fórumok

Sziasztok!

Freenas rendszerrel összeraktam egy storage szervert ami a a következőképpen néz ki:

HP DL380E G8
64GB DDR3 1333mhz memória
Xeon E5-2450L
LSI 9207-8i HBA
Qlogic QLE2562 FC

Merevlemezek:
3DB HGST 6TB 4Kn
2DB Seagate Enterprise capacity 6TB 512e
2DB Seagate EXOS 7E2 6TB 512e

A probléma a következő:

FC-n oda van adva egy ESxi host-nak egy zvol.

Ha szintetikus teszteket végzek rajta (RDM vagy VMFS-el) akkor teljesen rendben van a sebesség 820MB/s olvasás és írás (Q8 1MiB) Atto diskmark-al úgyszintén rendben vagyunk. [benchmarkok]

De ha elkezdek másolni rá fájlt egy ssd-ről akkor elindulunk szép nagy sebességgel majd lecsökkenünk folyamat 50-80MB/s közé de van, hogy ez alá is lemegy, szerintem többet kéne tudnia.

Nincsen SLOG/L2ARC beállítva most még csak szeretném ezek nélkül kipróbálni, hogy mit produkál.
Próbáltam már sync=disabled -el azzal nagyon halványan növekedett csak.

Valahogy ezt a sebességet kevésnek érzem ennyi merevlemeznél.

Köszönöm a segítséget

 

Hozzászólások

Az SSD fizikailag a gépben van amiről másolsz? A pool hogyan van szervezve amin a zvol van?

Próbáld ki a benchmark-ot nagyobb mérettel is, mondjuk 32GB-val, hogy akkor mit mond.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

BIOSban SATA mód legyen AHCI ha nem az és próbáld meg úgy is.

Én azt mondanám lehet már kéne neki az a read cache, l2arc buff hogy azt is hozza.Annak ha jól tudom az lenne a szerepe hogy a kilens általi limitációkon dobjon. Mondjuk zfs nagy fileokkal sokaknak van gondja Linuxon az is gond, ott nem teljesít alapból csücskösen sajnos.

Szerkesztve: 2021. 03. 08., h – 12:32

Próbáld meg kikapcsolni a primary cache-t, zfs set primarycache=none volname.

Ezek a tesztek semennyire sem relevánsak a rendszer teljesítményét tekintve. Mind 1 GB-os teszt-mérettel készült, ami úgy a host, mint a NAS oldalán bőven memóriából megy, így nem mutat kb. semmit. Azaz de, látod, hogy a 8Gb-es FC csatolód tudja amit ígért a két host között...

Olyan teszteket futtass, ahol a teszt-méret a két gép közül a több memóriával rendelkezőnek a memóriaméret kétszeresen-négyszerese. Tehát ha az ESXi 64GB, a NAS 32 GB, akkor a 64GBx2x/x4, 128GB vagy 256GB legyen a teszt éret. Az mutatja meg a diszk-alrendszer valódi teljesítményét. Ráadásul ebből a random IO lesz az érdekes, ha VM-eket akarsz futtatni, függetlenül a virtuális diszk méretétől.

Írd meg, milyen szervezésben van ez a 7 db 6 TB-os diszk. Tippre RaidZ2, ami IOPS-ben egyetlen HDD teljesítményét hozza (ami nem-SSD diszk esetén, random műveleteknél 100-200 IOPS), és igazából alkalmatlan VM diszkek tárolására, VM-ek futtatására, hiába kötötted be gyors FC-n a host-ot. Ezt mutatja a 0.44 MB/s Q1T1 mérés, ami reális érték.

Amennyiben RAID10 jellegű (2-way mirror VDEV-ek egy pool-ban) 6 diszkből, akkor már háromszoros lesz az IOPS, amivel kb. 3 db VM-et futtathatsz olyan minőségben, mintha local HDD-ről futnának.

Az L2ARC vagy az SLOG bevezetése ezeken a terheléseken mit sem segít, azok nem ilyen feladatok "gyorsítására" alkalmasak.

Én úgy variálnám át, hogy a 6TB-os HDD-kből lévő RaidZ2 pool legyen a VM-ek adat diszkjeinek fenntartva (ha nem DB vagy hasonló a terhelés, hanem mondjuk sima file share), és csinálnék egy RAID1 vagy RAID10 pool-t 2 vagy 4 db (vagy több) SSD-ből VM boot/rendszer diszkeknek.

Nemí derült ki pontosan a használat,  ezért irta  GGALLO a válaszát, kitűnően összefoglalva a lényeget, már már olyan jól mintha én írtam volna :-)

Én inkább fio-t használok (van windowsra is) , nálam is 100 iops a random, (400 kB/sec) egy HDD lemez ZFS alatt: 

#fio --name=teszt_1 --filename=./testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1  |grep WRITE

  WRITE: bw=432KiB/s (442kB/s), 432KiB/s-432KiB/s (442kB/s-442kB/s), io=100MiB (105MB), run=237268-237268msec

 

Nagy fájlok másolásakor ha elfogynak a pufferek, akkor kb. annyi a sebesség amit tapasztalsz.
 

Egy gyors mérés 6 db wd red , raidz2,  nincs ssd - freeNAS, 
 windows alól gigabites háló:

SAMBA share:

 

PS R:\>   fio --name=ssdtest  --size=10G --bs=256k --iodepth=16 --rw=read

fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning.
ssdtest: (g=0): rw=read, bs=(R) 256KiB-256KiB, (W) 256KiB-256KiB, (T) 256KiB-256KiB, ioengine=windowsaio, iodepth=16
fio-3.13
Starting 1 thread
ssdtest: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=0): [f(1)][100.0%][r=67.9MiB/s][r=271 IOPS][eta 00m:00s]
ssdtest: (groupid=0, jobs=1): err= 0: pid=9112: Tue Mar 9 11:29:30 2021
  read: IOPS=269, BW=67.5MiB/s (70.8MB/s)(10.0GiB/151742msec)
    slat (usec): min=15, max=34390, avg=39.68, stdev=229.86
    clat (msec): min=5, max=338, avg=59.22, stdev= 6.92
     lat (msec): min=5, max=338, avg=59.26, stdev= 6.93
    clat percentiles (msec):
     |  1.00th=[   57],  5.00th=[   58], 10.00th=[   58], 20.00th=[   58],
     | 30.00th=[   58], 40.00th=[   58], 50.00th=[   58], 60.00th=[   58],
     | 70.00th=[   59], 80.00th=[   60], 90.00th=[   63], 95.00th=[   67],
     | 99.00th=[   82], 99.50th=[   84], 99.90th=[   92], 99.95th=[  124],
     | 99.99th=[  334]
   bw (  KiB/s): min=  762, max=71394, per=79.71%, avg=55081.33, stdev=27987.55, samples=201
   iops        : min=    2, max=  278, avg=214.50, stdev=109.23, samples=201
  lat (msec)   : 10=0.01%, 20=0.01%, 50=0.09%, 100=99.81%, 250=0.05%
  lat (msec)   : 500=0.04%
  cpu          : usr=0.00%, sys=0.66%, ctx=0, majf=0, minf=0
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.1%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=40960,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=67.5MiB/s (70.8MB/s), 67.5MiB/s-67.5MiB/s (70.8MB/s-70.8MB/s), io=10.0GiB (10.7GB), run=151742-151742msec

Milyen adatok? Kis vagy nagy állományok, kevés vagy sok darab? Egy-egy állományt szekvenciálisan olvasol vagy állományon belül random műveletek vannak?

Milyen jellegű eléréssel? Egymás után az állományokatbatch feldolgozás jelleggel, vagy össze-vissza mint egy hálózati file share?

Mennyi VM-ről egyszerre? Egyetlen VM mögé van téve bulk tárolónak vagy a ZFS pool-on több dataset van, amin párhuzamosan dolgoznak VM-ek? Vagy valami cluster FS-en keresztül egyszerre haszhálja több VM?

Most újra elővettem a dolgot és nem tudom felfogni hogy miért lassú továbbra is az írás része, másolok rá fájlokat és így 10 MB/s és ott vége utána felmegy 60-70-re aztán megint leugrik, nem éppen reszponzív. Itt éppenségel egy smb megosztásról van szó.

A legérdekesebb, hogy csak akkor ilyen rossz az eredmény ha a VM-en keresztül másolok rá ha a truenas intézi az smb-t is akkor teljesen rendben van a sebesség.

Nagy fájlok (filmek,sorozatok,képek) ez lenne az egyik zvol feladata.

Egy db VM mögé menne ez az egy ZVOL ami csak ezt a részét tárolná, 1db esxi használja.

Természetesen lenne több zvol is más VM-nek, de először ezt kellene helyretenni.

Próbáld ki natív ZFS fájlként feltölteni a storage-ra, meg próbáld meg a zvol-ba is dd-vel beletolni (a storage-on is megpróbálhatod, meg az ESXi hoston is). Én azt várnám (az alapján, ami még úgy 2006 magasságából megmaradt a fejemben a ZFS-ről), hogy a ZFS fájlos verzió gyors lesz, az zvolos megoldás meg dd-vel sem lesz gyors. De persze lehet, hogy tényleg a VM miatt lassú csak.

Na de milyen eredmények születnek, ha fio-val vagy dd-vel írod a VM-ből ezt a NAS-on lévő zvol diszket? Ebből talán közelebb juthatnánk ahhoz, hogy a VM-ben futó Samba a gond, vagy a NAS-ról FC-n felcsatolt zvol diszk, vagy az ESXi-n keresztüli FC csatolt diszk elérés, vagy más.

Az a baj, hogy regeteg réteg kerül egymásra ebben a felállásban, mire az adat a kliensről a NAS-ra kerül. Nem olyan könnyű megmondani, melyik réteg lassítja így meg, és azt sem, hogy lehet-e azon segíteni, vagy együtt kell élni vele.

Valamerre el kell indulni, de ahhoz teszt eredmények kellenek.

Azon nem gondolkodtál esetleg, hogy a NAS-ról iSCSI-n a VM-be felcsatolsz egy diszket? Akkor kikerülnéd az ESXi virtuális diszk alrendszerét (igaz, az FC-t is). De egy tesztnek érdekes lehet, mit mutat. Vagy egy olyan teszt, hogy az FC vezélőt odaadod a VM-nek, hogy úgy mit változik a teljesítmény (csak egy próbára persze).

Esetleg az nem lehet, hogy az FC-vel van a baj ESXi vagy FreeNAS, vagy mindkét oldalon? Gondolom a NAS direkt SMB elérése sima Ethernet hálózaton történt (amikor is az elvárhatót hozta sebességben).

Kíváncsiságból beletettem egy SSD-t a szerverbe majd átadtam az esxinek ugyanúgy ahogy a merevlemezes pool-al tettem majd pedig a virtuális gépnek RDM diskként physical és virtual módba is.

Ez egy Intel 545s SSD ami 550/500MB/s-re képes. Ehhez képest nem annyira akarta hozni amit kellett volna és sokszor lement 0bájt/s-re is meg a sebességben nagyon ugrált 100-400MB/s között. KÉP

 

Érdekes.

A merevlemezes poolt még nem tudtam tesztelni majd azt is nemsokára le fogom tudni.

Tehát jól értem, hogy FC-n megkapja a NAS-ról az ESXi a diszket, és nem VMFS-t teszel rá, arra pedig VMDK-t a virtuális gépnek, hanem az ESXi-n RDM-mel átadod az FC-n kapott diszket a virtuális gépnek?

Ha jól értettem, akkor szerintem inkább próbáld úgy, hogy az FC-n, a NAS-ról kapott diszkre VMFS-t teszel, és azon hozol létre sima VMDK-t a virtuális gépnek. Az RDM-et sok mindenre lehet használni ugyan, de pont nem sima diszk elérésre van kitalálva, hanem speciális esetekre.

Szerintem ott veszik el az IOPS és az átviteli sebesség, hogy valamelyik réteg (vagy több is) szinkron műveleteket csinál, és azt a többeknek meg kell várniuk. Ha kiveszel ilyen rétegeket, akkor csökkented az egymásra épülő szinkron műleteket számít, és esetlen az ESXi-nek és/vagy a NAS-nak lesz esélye cache-t használni.

Tehát jól értem, hogy FC-n megkapja a NAS-ról az ESXi a diszket, és nem VMFS-t teszel rá, arra pedig VMDK-t a virtuális gépnek, hanem az ESXi-n RDM-mel átadod az FC-n kapott diszket a virtuális gépnek?

 Igen így néz ki a dolog.

Megcsináltam vmfs/vmdk-val most sokkal egyenletesebb de a sebesség 230-340 ig ment de itt is lement 0-ra, a zvol-on a sync disabled-re van állítva a fő dataseten meg standard. KÉP

Egyébként a speciális eset mit takarhat? :)

Az esetleg okozhat ilyet, hogy a memóriák csak 800mhz-n mennek? Én úgy tudom, hogy a zfs-nek inkább memóriamennyiség mint sem sebesség kell.

+1 kérdés, hogy miért mennek csak 800mhz-n? forceolni se tudom őket, hogy 1333mhz-n menjenek pedig próbáltam mindent high-ra tenni a szerver beállításaiban de 0 siker. DDR3L modulok.

A memória sebesség szerintem ezen tesztek közben nem játszik szerepet. Még 800 MHz-en is elvileg 6.4 GB/s az elméleti RAM csúcssebesség, az FC 8 Gb/s meg elméletileg tud 1 GB/s átvilelt. Szóval nem igazán látom, hogy a RAM lehetne szűk keresztmetszet ebben az esetben bárhogyan.

Biztos, hogy egyformák (sebességre) a memória modulok? Nem nagyon jut eszembe semmi más ok, hogy ne a max. frekvencián működjön a memória egyébként.

Az RDM akkor jön jól általában (ez a "speciális eset" az én olvasatomban, alapból a VMFS javasolt ugye), ha egy "fizikai" diszkhez (ami lehet persze DAS/SAN LUN is) valami okból tényleges, kvázi közvetlen hozzáférés szükséges (spéci SCSI parancsok kiadásához, fizikai gépről virtuálisba migráláskor HDD másolással, ilyesmik).

Elvileg az RDM-nek jobb teljesítményt kellene nyújtania egyébként. Az persze nehéz kérdés, hogy ebben a konkrét felállásban hol van a szűk keresztmetszet, ami miatt ez nem így van.

Az biztos, hogy az ESXi NFS-en mindig szinkron írást végez, függetlenül az NFS szerver oldal beállításától. Számomra nem elképzelhetetlen, hogy az FC-n felcsatolt LUN-okkal is így van. Mert egyébként Te hiába tiltod le a szinkron írást ZFS oldalon, az csak annyit csinál, hogy ha a kliens nem jelöli meg az írás módját, akkor nem sziknron lesz. De ha a kliens megjelöli, hogy neki szinkron művelet kell, akkor mindenképp az lesz, hiába van a dataset-en/zvol-on letiltva.

Mondjuk egy jó SLOG device lehet segítene ezen a fajta terhelésen, ha valóban a feltételezésem szerinti szinkron írásokkal működik a rendszer. De nem 100%, ki kellene próbálni. A 8 Gbit-es FC-t alapul véve elég nenne 5-10 GB-nyi SLOG. Viszont szerintem az említett Intel 545-ös desktop SSD erre nem jó. Az szinkron írásban, pláne kis blokkméret esetén nem remekelhet annyira (mondjuk tesztre... HDD-n lévő ZIL-nél tuti gyorsabb).

Azt, hogy async vagy sync lesz-e ZFS szinten az írás azt a zpool iostat -l 2 paranccsal teszt közben is lehet ellenőrizni.

Egyébként általános tippként én azt mondanám, hogy a disk-től indulva kellene mérni, később hogy egyre több réteget használva, hátha kibukik, hogy hol van a szűk keresztmetszet.

Én többet sajnos így nem mondanék, mert egy ilyen hiba kivizsgálása nagyon sok időt, és utánaolvasást igényel, amit én nem szeretnék a kérdező helyett elvégezni. :)

Szia!

CPU elég gyengének tűnik (E5-2450L: 8x 1.80 GHz), kellene bele legalább ami 3.0 Ghz megy alapból.

Ezt miért gondolod/mondod?

Nem írta, hogy lenne bármilyen komolyabb igényű (nem LZ4 és nem ZStd) titkosítás, vagy egyéb olyan funkció használatban, ami CPU intenzív. Nekem is pont ilyen energiatakarékos CPU van az itthoni szerverben, és az 1 GbE hálózatot mindenféle módon ki tudom terhelni vele (úgy, hogy a TrueNAS egy VM-ben fut Proxmox-on, HBA átadással, nem is natívan a hardveren) különösebb CPU terhelés nélkül.

De ha valamiért itt mégis CPU limites lenne, akkor is hihetetlen, hogy a proci miatt 10-60 MB/s a max. sebessége. Még CPU limit esetén is jóval magasabban lennének a vágások.