zfs compression ennyire lassú?

Fórumok

Sziasztok!

Van valakinek elképzelése, hogy a zfs compression miért ilyen lassú?

root@freenas:~ # zfs create mirr1/teszt1
root@freenas:~ # zfs create mirr1/teszt2
root@freenas:~ # zfs set compression=off mirr1/teszt1
root@freenas:~ # zfs set compression=lz4 mirr1/teszt2
root@freenas:~ # dd if=/dev/zero of=/mnt/mirr1/teszt1/zero bs=1024 count=1024000
1024000+0 records in
1024000+0 records out
1048576000 bytes transferred in 8.646973 secs (121265097 bytes/sec)
root@freenas:~ # dd if=/dev/zero of=/mnt/mirr1/teszt2/zero bs=1024 count=1024000
1024000+0 records in
1024000+0 records out
1048576000 bytes transferred in 9.237847 secs (113508695 bytes/sec)
root@freenas:~ # dd if=/mnt/mirr1/teszt1/zero bs=1024 of=/dev/null
1024000+0 records in
1024000+0 records out
1048576000 bytes transferred in 3.183545 secs (329373714 bytes/sec)
root@freenas:~ # dd if=/mnt/mirr1/teszt2/zero bs=1024 of=/dev/null
1024000+0 records in
1024000+0 records out
1048576000 bytes transferred in 32.015340 secs (32752299 bytes/sec)
root@freenas:~ # dd if=/mnt/mirr1/teszt2/zero bs=2048 of=/dev/null
512000+0 records in
512000+0 records out
1048576000 bytes transferred in 16.104390 secs (65111192 bytes/sec)

Valamint az is meglepő számomra, hogy az utolsó dd-nél a bs duplájára állításánál dupla lett a sebesség is...

Valaki tudja a magyarázatot?

csucsu

Hozzászólások

Elképzelésünk van, de mivel semmit nem árultál el a vasról, ezért egyelőre megtartjuk magunknak ;)
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

HP Proliant P4300

FreeBSD 11.0-STABLE #0 r313908+f4b711d1be8(freenas/11.0-stable): Tue Jun 13 19:17:29 UTC 2017
root@gauntlet:/freenas-11-releng/freenas/_BE/objs/freenas-11-releng/freenas/_BE/os/sys/FreeNAS.amd64 amd64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2266.80-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x106a5 Family=0x6 Model=0x1a Stepping=5
Features=0xbfebfbff
Features2=0x9ce3bd
AMD Features=0x28100800
AMD Features2=0x1
VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID
TSC: P-state invariant, performance statistics
real memory = 32614903808 (31103 MB)
avail memory = 31216017408 (29769 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads

Tovabbmentél bs=4k-ra? Hányszor futtatták a teszteket? sync volt? Memorianal nagyobb fajllal mi a helyzet? Mennyi az sda natív r/w sebessége?

zfs get compression mirr1/teszt2
du -hs /mnt/mirr1/teszt?/zero

root@freenas:/mnt/mirr1/teszt1 # zfs get compression mirr1/teszt2
NAME PROPERTY VALUE SOURCE
mirr1/teszt2 compression lz4 local

root@freenas:/mnt/mirr1/teszt1 # du -hs /mnt/mirr1/teszt?/zero
1.0G /mnt/mirr1/teszt1/zero
512B /mnt/mirr1/teszt2/zero
root@freenas:/mnt/mirr1/teszt1 # ls -l /mnt/mirr1/teszt?/zero
-rw-r--r-- 1 root wheel 1048576000 Jun 28 20:55 /mnt/mirr1/teszt1/zero
-rw-r--r-- 1 root wheel 1048576000 Jun 28 20:55 /mnt/mirr1/teszt2/zero

A bs növelésével egyértelműen nő a sebesség...

Valós adatokkal kéne tesztelni, nem szintetikus benchmarkkal.

Az ökölszabály az (legalábbis Solarisnál), hogy lehetőleg mindenhol kapcsold be. Még a leggyorsabb I/O alrendszer is általában nagyságrendekkel lassabb, mint a CPU és a memória, a tömörítés pedig azt jelenti, hogy a lassú komponensen kell átmozgatni kevesebb adatot.

Bizonyára van olyan workload, ahol nem előnyös, de pont a minap futottam ebbe bele, még Postgres alá is javasolt:

https://people.freebsd.org/~seanc/postgresql/scale15x-2017-postgresql_z…

Az lz4-ről amúgy olvastam, hogy nem csak ki-betömöríteni tud igen gyorsan, hanem nagyon hamar fel is ismeri, ha a kiírandó adat nem tömöríthető. Ilyenkor "föladja" és tömörítés nélkül tárolja, tehát írásnál csak egy minimális késleltetést jelent az, hogy próbálkozik.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”