Permalänk
Medlem

ZFS fragmentering(?)

Jag har en NAS, som består av en i7 860 (4C/8T), 16GB ram och 8st 2TB Samsung EG diskar, 7200rpm.
Systemet kör 9.1-RELEASE-p11, och ZFS 5/28. Diskarna är GELI-krypterade, med ZFS ovanpå. Poolen är ca 55% full.

# zpool status pool: tank state: ONLINE scan: scrub repaired 0 in 13h44m with 0 errors on Mon May 19 00:32:54 2014 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 label/ss-disk1.eli ONLINE 0 0 0 label/ss-disk2.eli ONLINE 0 0 0 label/ss-disk3.eli ONLINE 0 0 0 label/ss-disk4.eli ONLINE 0 0 0 label/ss-disk5.eli ONLINE 0 0 0 label/ss-disk6.eli ONLINE 0 0 0 label/ss-disk7.eli ONLINE 0 0 0 label/ss-disk8.eli ONLINE 0 0 0 errors: No known data errors

Det underliga som jag märkt det senaste halvåret(?) är att prestandan blivit ganska usel, eller rättare sagt urusel. Vid läsning.

# dd if=/dev/zero of=/tank/testfile.zero bs=1M count=10000 10000+0 records in 10000+0 records out 10485760000 bytes transferred in 51.176170 secs (204895364 bytes/sec) # dd if=/dev/urandom of=/tank/testfile.zero bs=1M count=10000 10000+0 records in 10000+0 records out 10485760000 bytes transferred in 147.880727 secs (70906873 bytes/sec) # dd if=/tank/testfile.zero of=/dev/null 20480000+0 records in 20480000+0 records out 10485760000 bytes transferred in 192.019463 secs (54607798 bytes/sec)

Den mittersta kan jag förstå, det är urandom som drar ner prestandan. Men vid kopiering till null så ligger jag på ca 50MB/s. Och skulle jag kopiera över nätverket så ligger jag på än mindre, med CPU på 96-98% idle ... Protokoll, sFTP eller SMB spelar ingen roll, kanske aningen fortare med sFTP.

# dd if=testfile.zero of=/dev/null 20480000+0 records in 20480000+0 records out 10485760000 bytes (10 GB) copied, 279,989 s, 37,5 MB/s

Är det bara att gilla läget tills jag skaffar fler diskar och kan kopiera över till en ny pool (och tillbaka)? För det luktar fragmentering, som jag förstår inte går att avhjälpa på annat sätt..?

Permalänk
Medlem

Du har inte funderat på att gå över till 9.2?

Jag hade urusel läs och skrivhastighet i 9.1 med mina raidz1 pooler på 4 diskar vardera, problemet är att rekommenderade diskar i pooler inte stämmer överens med antal diskar jag har och då blev prestandan urusel.
9.2 åtgärdade problemet för mig iallaf.

Permalänk
Medlem

defragmentering genom att flytta allt till ny pool är en beprövad lösning.

Permalänk
Medlem
Skrivet av xp1ratex:

Du har inte funderat på att gå över till 9.2?

Jag hade urusel läs och skrivhastighet i 9.1 med mina raidz1 pooler på 4 diskar vardera, problemet är att rekommenderade diskar i pooler inte stämmer överens med antal diskar jag har och då blev prestandan urusel.
9.2 åtgärdade problemet för mig iallaf.

9.2 är absolut ett alternativ.

Jag har också ett "dåligt" antal diskar.. 7st eller 9st verkar vara ett bättre val. Men nu sitter jag i den sitsen jag gör, och får leva med det tills jag får skaffat mitt 24 tray rack..

Jag ska klura lite på en uppgradering..

Permalänk
Medlem

ZFS är ju riktigt långsamt alltid, men ett problem kan ju vara att diskarna har använts väldigt mycket.

Hur mycket I/O tror du de varit med om?

Permalänk
Medlem

Tråkigt att Schrimp har problem, jag menar inte att på något sätt vrida om kniven så att säga men det är en intressant tråd med tanke på att i andra delar av forumet hyllas ju ZFS utan förbehåll som lösningen på alla världens problem (typ).

Permalänk
Medlem

Prova med att samtidigt köra "gstat" och se om kanske en av diskarna sticker ut bland dem andra (t.ex. latencymässigt). Jag har själv stött på situationer där en enskild dålig disk drar ner prestandan för hela poolen.

Permalänk
Medlem

Tror inte heller att det är fragmentering som är problemet. Men en raidzX är mycket känslig för variation i hastighet och latens på medlemsdiskarna. Har du kollat på SMART data från de? Är det någon disk som sticker ut? Testa även gstat som weeblie föreslår.

Permalänk
Medlem

Du kör för stor pool helt enkelt. För att kunna köra fler än 6 diskar bör du dela dessa i max 6 st i varje grupp. 24 st bör alltså vara 6×4st eller 4×6st. Då kan du köra ext4fs eller ResierFS utan problem. Skapa därför först små RAID-block av 4-6 diskar sedan gör du ett nytt överlagrat block av blocken du skapar.

Försök att få värden där under och övervärdet ligger nära varandra både i storlek för gruppen och totalt antal diskar, dvs 6×4, 6×6, 7×7 etc.

Permalänk
Medlem

Det är inga problem att köra 8 diskar i raid2z. Han säger att han planerar ett bygge med 24 diskar. Det skulle jag kört som 3x6 raidz2 om alt nödvändigtvis skulle vara en pool.

Permalänk
Medlem

Ja, det stämmer att jag någon gång framöver ska bygga ut min pool. Jag ska då ha 3x7 alt 4x6 i raidz2.

gstat vet jag inte riktigt hur jag ska tolka, men en läsning verkar inte dra mer än ca 50% av diskarna. Medans skrivningen, som går fort, ligger på allt från 75% upp till 125%. Alla värden är jämna och fina sinsemellan.
CPUn ligger på ca 20-40% load vid läsningen. Vid skrivning är det 100% load.

Jag hyllar fortfarande ZFS, då jag gillar dess features oerhört mycket, men det är trist att detta hänt. Diskarna har inte så värst mycket "ren" throughput över tid, utan det är mest småfiler som skrivs (kör en handfull rsync script som skriver in en del filer på allt från 2KB till 20MB. 4000-5000 per natt. Utöver det så tas det ett tiotal snapshots på dessa volymerna.

Jag har länkat den i en annan tråd, men jag postar den här också, mycket intressant ZFS-läsning: https://calomel.org/zfs_raid_speed_capacity.html
Och enligt den kan det vara problem med att jag valt just 8st diskar och inte 7 eller 9(?).

Dessa två bilder är några sekunder ifrån varandra, under läsning.

Permalänk
Medlem
Skrivet av Schrimp:

Ja, det stämmer att jag någon gång framöver ska bygga ut min pool. Jag ska då ha 3x7 alt 4x6 i raidz2.

gstat vet jag inte riktigt hur jag ska tolka, men en läsning verkar inte dra mer än ca 50% av diskarna. Medans skrivningen, som går fort, ligger på allt från 75% upp till 125%. Alla värden är jämna och fina sinsemellan.
CPUn ligger på ca 20-40% load vid läsningen. Vid skrivning är det 100% load.

Jag hyllar fortfarande ZFS, då jag gillar dess features oerhört mycket, men det är trist att detta hänt. Diskarna har inte så värst mycket "ren" throughput över tid, utan det är mest småfiler som skrivs (kör en handfull rsync script som skriver in en del filer på allt från 2KB till 20MB. 4000-5000 per natt. Utöver det så tas det ett tiotal snapshots på dessa volymerna.

Jag har länkat den i en annan tråd, men jag postar den här också, mycket intressant ZFS-läsning: https://calomel.org/zfs_raid_speed_capacity.html
Och enligt den kan det vara problem med att jag valt just 8st diskar och inte 7 eller 9(?).

Dessa två bilder är några sekunder ifrån varandra, under läsning.

http://puppe.se/zfs/Screenshot%20from%202014-05-29%2016:58:45...

http://puppe.se/zfs/Screenshot%20from%202014-05-29%2016:59:33...

När jag läste på om ZFS så har jag för mig att det här med jämnt antal diskar endast påverkar skrivning, inte läsning.

Sök på saker Sub_Mesa skrivit om ämnet är ett hett tips.

Permalänk
Medlem
Skrivet av Phiphler:

ZFS är ju riktigt långsamt alltid, men ett problem kan ju vara att diskarna har använts väldigt mycket.

Hur mycket I/O tror du de varit med om?

Beror helt på konfiguration (som allt annat), har du någon källa på att moderna diskar blir "trötta" av användning?

Permalänk
Medlem

Jag har lite smått fullöst mitt prestandaproblem, genom att kringgå NCQ:

# sysctl vfs.zfs.vdev.min_pending=1 # sysctl vfs.zfs.vdev.max_pending=1

Detta ger mig iaf 30MB/s igen. Relativt nöjd, men jag fortsätter mitt sökande.. (Jag var så lågt som 11MB/s när det var riktigt illa..)

Permalänk
Medlem

nu vet jag inte om du har raid kort eller om det gör skillnad, men jag måste öka på min "read ahead" i linux kerneln för att få ut full fart.
har ett perc5 kort till mina diskar

skadar inte testa, i många fall räcker det att öka från 256 till 8192, jag får dock bäst prestanda med 16384
och det blir sjukligt stor skillnad, att lista mp3 mappen tog flera sek upp mot 20sec, nu ca 1-2sec
ändra sdb till vad dina diskar heter.
sudo /sbin/blockdev --setra 8192 /dev/sdb
sudo /sbin/blockdev --setra 16384 /dev/sda