FreeNAS - lose performanse

[alfaunits]

On je for the classes, not for the masses Ako hoces for the masses, onda Apple Time Machine, i ne moras da ukljucujes ni 0.02%% mozga

 

[zeleni_zub]

Napisao sam već u tvom drugom tredu gde najčešće dolazi do problema sa performansama na ZFS-u. Još jedna stvar može da bude problem - ARC se povećava sve dok ima slobodne memorije i možda FreeBSD ima problem sa tim. Ograniči ZFS ARC (zfs_arc_max) na recimo 2GB za početak.

Inače ARC je samo read cache, ZFS ne kešira upise, sve ide direktno na diskove.


Jel možeš da uradiš (iz shell-a):

1. zpool list
2. zfs list
3. zfs get all <fs gde su ti podaci>
4. Sačekaš da se pojave problemi sa performansama i uradiš "vmstat 5 10" i "iostat -x 5 10"
5. Ako imaš sysutils/zfs-stats instaliran uradi i zfs-stats -a

Takođe proveri da li se problem javlja i kada direktno upisuješ na diskove iz FreeBSD-a:

dd if=/dev/null of=testFile.dat bs=131072 count=32768 (4GB u blokovima od po 128k - trebalo bi da bude isto kao ZFS blok size, dobro pazi šta ti je output file, pošto ako staviš of=/ ode ceo file sistem).



I sve naravno okačiš ovde.

 

[kovacm]

^
hocu predvece...

 

[alfaunits]

Napisao sam već u tvom drugom tredu gde najčešće dolazi do problema sa performansama na ZFS-u. Još jedna stvar može da bude problem - ARC se povećava sve dok ima slobodne memorije i možda FreeBSD ima problem sa tim. Ograniči ZFS ARC (zfs_arc_max) na recimo 2GB za početak.

Po graficima mu je cache usage uvek manji od 2GB, wired memory se puno koristi (5-6GB, a ne znam sta bi to konkretno bilo, tj. sta u kernelu i za sta koristi)

Inače ARC je samo read cache, ZFS ne kešira upise, sve ide direktno na diskove.

Mislis da sam ARC cache je samo read cache, ili da sav cache je samo read?
Skoro sam siguran da si nesto lose razumeo, ako je ovo drugo. Da nema uopste write cache-a, performanse bi bile uvek lose. Postoji write SSD cache kao opcija, ako nista drugo.

Ako je upis sector-aligned, onda vec ima smisla da uvek bude full commit.

Write caching ne mora da znaci da se stvari cuvaju u memoriji, i da nije garantovan upis - dovoljno je da se tokom checksumiranja asinhronog upisa radi processing u memoriji, RAID5 parity calculation i slicno, i to je vid write cache-a (u stvari najbitniji!).

 

[joximus]

kovacm probaj kopiranje preko ftp-a i proveri kojom brzinom ide. Ja nekad preko sambe imam slabu brzinu transfera ali ftp mi uvek ide punom brzinom.

 

[zeleni_zub]

Po graficima mu je cache usage uvek manji od 2GB, wired memory se puno koristi (5-6GB, a ne znam sta bi to konkretno bilo, tj. sta u kernelu i za sta koristi)

Većina wired memorije bi trebala da bude ARC. Taj cache usage je kernel cache koji se ne koristiti za ZFS.

Mislis da sam ARC cache je samo read cache, ili da sav cache je samo read?
Skoro sam siguran da si nesto lose razumeo, ako je ovo drugo. Da nema uopste write cache-a, performanse bi bile uvek lose. Postoji write SSD cache kao opcija, ako nista drugo.

Mislio sam na ARC - on je samo read cache, ali je on jedina vrsta keširanja podataka na ZFSu (ne računam L2ARC). Ne postoji neki write cache koji bi držao podatke dok ih diskovi ne upišu. SSDove možeš staviti kao L2ARC (level 2 arc - isto samo read cache) ili log vdev-ove (ZIL onda stoji na njima).

Upis bi morao biti sector aligned - to sam mu već napisao - da proveri ashift da li je dobro podešen. U principu da nema dobar aligment problem sa performansama bi imao od početka, a ne samo kada nestane memorije.

 

[alfaunits]

Upis bi morao biti sector aligned - to sam mu već napisao - da proveri ashift da li je dobro podešen. U principu da nema dobar aligment problem sa performansama bi imao od početka, a ne samo kada nestane memorije.

Kada je upis sector aligned, onda ima smisla da se odmah radi upis - sve ostalo bi moralo ici kroz cache, a ako SAMBA/NFS upisi, koji cesto nisu uopste aligned, moraju da budu odmah upisivani, to je glupost onda.

Mogu da shvatim da ne postoji neki veliki cache, tipa ni 64MB, ali da sve odmah ide write, takav file system nije ni cudo da se ne koristi svugde onda.

 

[zeleni_zub]

Sinhrono upisivanje može da se isključi (sync property, ne znam da li je isto na OpenZFSu), ali naravno nije preporučeno za file sisteme gde ne smeš da izgubiš poslednjih 5 sekundi upisa.

Inače kod sinhronih upisa postoje dva scenarija. Prvi je da ZIL upiše parcijalni ZFS record i pointer na lokaciju u pool-u (i to se upisuje direktno na disk), a posle se na kraju transakcije modifikovan full ZFC record upiše na samom pool-u (asinhrono). Drugi je da se direktno na samom pool-u upisuju modifikovani full ZFS record-i (za neke velike operacije upisa recimo), a u ZIL se upisuju samo pointeri.

U svakom slučaju ako je sinhroni upis uključen (sync=always, ili je fajl otvoren sa O_SYNC flagom) ZFS record mora biti upisan na disk sinhrono (ili full record u pool ili partial u ZIL).

Ako je sync isključen, podaci o transakciji stoje u memoriji do txg commit-a - koji se u ovoj verziji ZFS radi na 5 sekundi. Tako da se može reći da su transakcije keširane u memoriji (ako nije sync), ali ne i ZFS record-i.

 

[ness1602]

Zato se i koristi recimo SSD za ZIL(odnosno dodatni). Ako ti prsne memorija, ostaje ti na ZIL disku upis.

 

[alfaunits]

Ako je sync isključen, podaci o transakciji stoje u memoriji do txg commit-a - koji se u ovoj verziji ZFS radi na 5 sekundi. Tako da se može reći da su transakcije keširane u memoriji (ako nije sync), ali ne i ZFS record-i.

Nisam ni mislio na metadata, iskljucivo na podatke. Imao sam iskustvo ne nekim extremnim "safety" kontrolerima (koje ja zovem *****ni - mislim da vecina LSI spada u tu grupu!), gde svi upisi, kada je write-through idu instant commit... sto znaci da i sekvencijalni upis od 1MB ide svaki disk zasebno! I to je performanse sekvencijalnog upisa cak svelo na mnogo sporije od jednog diska cak (dok sekvencijalni na RAID5 ide brze nego na RAID1, skoro brzinom RAID0 sa jednim diskom manje).
To je jedina stvarna varijanta da se radi bez cache-a za RAID5. Sve ostalo moze da se nazove kvazi-cache ili minimal caching, 0second lazy-write-commit, ali u svim slucajevima postoji neki write cache.

5 sekudni je sasvim dovoljan time, moze i 1-2 sekunde da bude lazy-write timing za podatke i performanse ce biti mnogo bolje.

 

[zeleni_zub]

OK, mislim da se ja nisam dobro izrazio. Ne postoji write cache u smislu nekog write back cache-a koji bi čuvao record-e i upisivao ih na diskove u pozadini (kao što radi cache na storage sistemima), gde bi u se u slučaju restarta pojavila nekonzistentnost u upisanim podacima.

1. Ako je uključen sync sve transakcije se odmah sinhrono upisuju u ZIL (koji je na diskovima ili na SSDu ako je eksplicitno definisan log vdev) i to u praksi znači:
- ako je IO dosta manji od record size-a, podaci i pointer se upišu u ZIL (sinhrono), pa se naknadno formiranju full record-i i upisuju na pool prilikom commit-a.
- ako je IO veći, u ZIL se upisuje pointer (sinhrono), a full record direktno na pool (isto sinhrono).

U slučaju restarta sve transakcije koje su u ZIL-u će biti primenjene na pool-u i nema gubitka podataka.

2. Ako nije uključen sync, podaci o transakciji (pointer, i full/partial record) stoje u memoriji i pri txg commit-u se formiraju full record-i i upisuju u pool. U slučaju restarta - izgubićeš sve podatke koji nisu commit-ovani, ali će ti ZFS uvek biti konzistentan.


Inače neko bi mogao celu ovu opštu ZFS diskusiju iz dva treda da spoji u jedan.

 

[alfaunits]

OK, mislim da se ja nisam dobro izrazio. Ne postoji write cache u smislu nekog write back cache-a koji bi čuvao record-e i upisivao ih na diskove u pozadini (kao što radi cache na storage sistemima), gde bi u se u slučaju restarta pojavila nekonzistentnost u upisanim podacima.

Hmmm, pa zato sluzi battery backup... taj cache ce moci da se upise posle restarta.
Ako mislis da ce metadata biti neupisani, to ce biti jedino ako je greska kontrolera da ne postuje FLUSH komandu.

Inace je mit da se to desava zbog write-back cachea. (ja licno uvek gasim WB cache jer zelim konzistentne performanse, a ne neki skok/pad, i najgori je onaj trenutak kad se napuni cache i odjednom mora da se uradi flush da bi moglo da se nastavi - taj zastoj nervira uzasno kada je workstation u pitanju )

Inače neko bi mogao celu ovu opštu ZFS diskusiju iz dva treda da spoji u jedan.

Da, malo je glupo sto je i u onoj drugoj temi bilo diskusije o performansama

P.S. Jel' ti i daljes imas onaj Areca 1220 ili nesto slicno? Mozes na njemu probati da iskljucis write-back cache (tj. prebacis na write-through) i uporedis sa nekim LSI kontrolerom koji nema bateriju ili nema cache uopste

 

[zeleni_zub]

Mislio sam na restart samog kontrolera iz bilo kog razloga i gubitak podataka iz keša (ne radi baterija, neispravna memorija, itd...).

Uf, taj server je odavno otišao u zasluženu penziju, a i ja nisam više u toj firmi.

 

[alfaunits]

Restart kontrolera (ili bilo koji drugi bug kontrolera) su vec ozbiljna pitanja, koja se mnogo cesce desavaju nego problemi sa CPUom ili ECC memorijom.
Slazem se, sa te strane server ne treba da rizikuje, ali se tu vodi samo ona osnovna ideja: "RAID is not a backup"

 

[kovacm]

Napisao sam već u tvom drugom tredu gde najčešće dolazi do problema sa performansama na ZFS-u. Još jedna stvar može da bude problem - ARC se povećava sve dok ima slobodne memorije i možda FreeBSD ima problem sa tim. Ograniči ZFS ARC (zfs_arc_max) na recimo 2GB za početak.

Inače ARC je samo read cache, ZFS ne kešira upise, sve ide direktno na diskove.


Jel možeš da uradiš (iz shell-a):

1. zpool list
2. zfs list
3. zfs get all <fs gde su ti podaci>
4. Sačekaš da se pojave problemi sa performansama i uradiš "vmstat 5 10" i "iostat -x 5 10"
5. Ako imaš sysutils/zfs-stats instaliran uradi i zfs-stats -a

Takođe proveri da li se problem javlja i kada direktno upisuješ na diskove iz FreeBSD-a:

dd if=/dev/null of=testFile.dat bs=131072 count=32768 (4GB u blokovima od po 128k - trebalo bi da bude isto kao ZFS blok size, dobro pazi šta ti je output file, pošto ako staviš of=/ ode ceo file sistem).


I sve naravno okačiš ovde.

u attachu je fajl 1.txt sa:

1. zpool list
2. zfs list
3. zfs get all <fs gde su ti podaci> (nisam stavljao nijedan spec. path)

novi problem je sto posle cackanja i iskljucivanja parametara u tunables sad non stop imam oko 10MB/s ...
vise od toga ne mogu da dobijem cak ni kad poiskljucujem sve tunables.

---
dd iz nekog razloga ne radi:

[root@FreeNAS /mnt/WD20EARX_trailer]# dd if=/dev/null of=testfile.dat bs=131072 
count=32768                                                                     
0+0 records in                                                                  
0+0 records out                                                                 
0 bytes transferred in 0.000040 secs (0 bytes/sec)

---
a FTP: ako su manji fajlovi imam 50-100MB/s...

probao sam jedan veliki fajl od par GB - zakucala se LAN kartica na NASu!!!!
ispisuje "re0: watchdog timeout"
i "ntpd[2041]: sentto(xxx.xxx.xxx.xxx) (fd=22): no route to host"

izgleda da moj hardware ima problem :/

 

[zeleni_zub]

Ne radi pošto nema šta da pročita iz /dev/null (prsti brži od pameti). Treba /dev/zero. Jel ovo vmstat urađen u periodu kada imaš problem sa performansama?

 

[kovacm]

Ne radi pošto nema šta da pročita iz /dev/null (prsti brži od pameti). Treba /dev/zero. Jel ovo vmstat urađen u periodu kada imaš problem sa performansama?

to je vmstat odradjen dok imam 10MB/s (za vreme kopiranja na NAS) ali kazem, sad imam konstantno 10MB/s (otprilike) od kad sam cackao tunables. sad vise nikada ne dobijam 60-80MB/s!

 

[zeleni_zub]

OK, Znači sada imaš neki drugi problem. Šta si tačno "čačkao"? Jesi menjao recordsize, kernel parametre? Ako promeniš record size, uključiš kompresiju, itd. ta podešavanja se odnose samo na podatke koje upisuješ od tada. Znači recimo, promeniš recordsize na 8k, kreiraš neki fajl (on će imati recordsize 8k), vratiš recordsize na 128k, taj fajl koji si napravio je i dalje u blokovima od 8k (i imaš strašno loše performanse kada ga sekvencijalno čitaš). Ako si nešto tako uradio, moraš da prebaciš podatke negde, središ podešavanja pool-a (ili mnogo jednostavnije da ga rekreiraš) i onda vratiš podatke.

Koliko vidim iz podešavanja, sve ti je OK, osim što bi logbias mogao da staviš na throughput. Jel možeš da okačiš i /boot/loader.conf i zfs-stats ako imaš?

 

[kovacm]

kernel parametre jesam. menjao sam sledece:

kern.ipc.maxsockbuf
net.inet.tcp.recvbuf_max
net.inet.tcp.sendbuf_max
vfs.zfs.arc_max
vm.kmem_size
vm.kmem_size_max

ali sve te parametre ISKLJUCIO! pretpostavljam da su sada defaultni za FreeNAS.

zfs-stats nemam.

u prilogu je /boot/loader.conf

a rezultati DDa su:

4294967296 bytes transferred in 62.959518 secs (68217919 bytes/sec)

 

[alfaunits]

Znači recimo, promeniš recordsize na 8k, kreiraš neki fajl (on će imati recordsize 8k), vratiš recordsize na 128k, taj fajl koji si napravio je i dalje u blokovima od 8k (i imaš strašno loše performanse kada ga sekvencijalno čitaš).

WTF?? Kakav je ovo FS

 

[zeleni_zub]

sad imam konstantno 10MB/s (otprilike)

Proveri da nemaš neki mrežni adapter koji radi na 100Mbit-a.