Hozzáteszem eddig néhány 10 kilós dokumentumoknál nem nagyon tartottak nagyobb fájlokat a szerveren. Most hogy valakinek az jutott eszébe, hogy a pendrive-ját ideiglenesen átmásolja a szerverre, azonnal előkerült ez a probléma.
Ezzel a 'pontos' hibaleírással kerestek meg.
Konfig
Ennek okán a szerver beállításait átmásoltam a teszt szerveremre. és kezdődhetett a vadászat.
Alapesetben így néz ki a - mint a címből látható - zfs fájlrendszer
root@ubuntu:~# zpool status -v
pool: data
state: ONLINE
scan: scrub repaired 0 in 4h52m with 0 errors on Fri Nov 11 01:19:20 2016
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
sdb ONLINE 0 0 0
logs
ubuntu--vg-zlog ONLINE 0 0 0
cache
ubuntu--vg-zcache ONLINE 0 0 0
errors: No known data errors
Ahol az ubuntu-vg egy 128-as ssd-n van:
root@ubuntu:~# vgdisplay
--- Volume group ---
VG Name ubuntu-vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 4
Max PV 0
Cur PV 1
Act PV 1
VG Size 111,55 GiB
PE Size 4,00 MiB
Total PE 28556
Alloc PE / Size 28556 / 111,55 GiB
Free PE / Size 0 / 0
VG UUID rJmNgZ-sjOT-eRf0-mAhl-LxLa-YyfR-yHG3fC
root@ubuntu:~# lv
lvchange lvextend lvmconfig lvmpolld lvremove lvscan
lvconvert lvm lvmdiskscan lvmsadc lvrename
lvcreate lvmchange lvmdump lvmsar lvresize
lvdisplay lvmconf lvmetad lvreduce lvs
root@ubuntu:~# lvdisplay
--- Logical volume ---
LV Path /dev/ubuntu-vg/root
LV Name root
VG Name ubuntu-vg
LV UUID 5IqSEY-WHlf-5ylD-AvFv-VyGd-cdzY-exLVX8
LV Write Access read/write
LV Creation host, time ubuntu, 2015-08-08 13:50:35 +0200
LV Status available
# open 1
LV Size 40,00 GiB
Current LE 10240
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:0
--- Logical volume ---
LV Path /dev/ubuntu-vg/swap_1
LV Name swap_1
VG Name ubuntu-vg
LV UUID lEWmoj-j7VS-VVES-mc2v-IBx1-zWWR-Wy9MnU
LV Write Access read/write
LV Creation host, time ubuntu, 2015-08-08 13:50:35 +0200
LV Status available
# open 2
LV Size 3,87 GiB
Current LE 990
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:1
--- Logical volume ---
LV Path /dev/ubuntu-vg/zlog
LV Name zlog
VG Name ubuntu-vg
LV UUID tJLuzd-HawO-nU1f-8sI7-LD5v-NcNa-4r5gQh
LV Write Access read/write
LV Creation host, time ubuntu, 2015-10-12 09:50:19 +0200
LV Status available
# open 1
LV Size 4,00 GiB
Current LE 1024
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:2
--- Logical volume ---
LV Path /dev/ubuntu-vg/zcache
LV Name zcache
VG Name ubuntu-vg
LV UUID MiDmbL-IcN2-6YbV-LMhB-8H1v-tfCZ-YxPZuQ
LV Write Access read/write
LV Creation host, time ubuntu, 2015-10-12 09:51:17 +0200
LV Status available
# open 1
LV Size 63,68 GiB
Current LE 16302
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:3
root@ubuntu:~#
sdb pedig egy mezei 2TB-os wd merevlemez
Az ssh és az nfs szerveren kívül minden más az ubuntu szerver alapbeállításain van/volt, tehát sem az lvm, sem a zfs nem lett hangolva.
Ez a teszt szerver egy ideiglenes tárolásra is használt gép, vannak/voltak rajta NFS megosztások:
root@ubuntu:~# cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/media/repository 192.168.0.0/24(rw,no_root_squash,no_subtree_check,anongid=100)
/media/power 192.168.0.0/24(rw,no_root_squash,no_subtree_check,anongid=100)
/media/power/desktop/home 192.168.0.0/24(rw,no_root_squash,no_subtree_check)
/srv/storage 192.168.0.0/24(rw,no_root_squash,no_subtree_check,nohide,crossmnt,anongid=100)
/srv/tftpboot/sysrescd 192.168.0.0/24(ro,no_root_squash,no_subtree_check)
/media/repository/Filmek 192.168.122.0/24(rw,no_root_squash,no_subtree_check,anongid=100)
/media/repository/Zenék 192.168.122.0/24(rw,no_root_squash,no_subtree_check,anongid=100)
/media/power 192.168.122.0/24(rw,no_root_squash,no_subtree_check,anongid=100)
Ezután a kliens gépen is beállítottam a megosztások elérését.
megjegyzés
Itt még azért figyelembe kell vennetek, hogy én nem mérések, meg cikkírás miatt álltam neki ennek a problémának, hanem egyszerűen a probléma megoldása érdekében. Tehát ilyesmik nem lesznek benne.
Ha valakinek szüksége van egzakt adatokra, annak magának kell azokat beszerezni:))
Az esetleges megoldás pedig nem feltétlenül a leggyorsabb adatátvitelben, hanem a használhatóságban rejlik, amikor a gép elvégzi feladatát, de közben használható marad a felhasználó számára.
hiba? jelenség
A próbák alatt azt tapasztaltam, hogy a másolás kezdetén az átvitel 120-130 MB/mp, amikor megtelnek a cache-k a másolás - látszólag - megáll, az árviteli sebesség esni kezd, 80-90 MB/mp , majd az ablak elérhetetlenné válik hosszú percekre. amikor aztán az ablak újra elérhető lesz, már csak 50-60 MB/mp marad az átviteli sebesség, a cache újra feltöltődik, és kezdődik előröl.
NFS cache
Először a nfs hangolásában reméltem megtalálni a megoldást, kisebbre vettem a cache méretés, ill végül szinkron adatárvitelt állítottam be, de csak azt értem el, hogy a 'szürke zóna':) rövidebb ideig, de több alkalommal ütött be. vagyis zsákutcának bizonyult.
ZFS cache
A 'gugel' szerint a zfs prefetch kikapcsolása sok esetben gyorsít a zfs-en.
Hogyan nem tudom, de próba szerencse.
root@ubuntu:~# echo 'options zfs zfs_prefetch_disable=1' >> /etc/modprobe.d/local.conf
root@ubuntu:~# cat /etc/modprobe.d/local.conf
options zfs zfs_prefetch_disable=1
root@ubuntu:~# shutdown -r now
És valóban 1-2 mp-et hozott az eredeti állapothoz képest, de ez kevés, és a szürkület sem múlt el, és az átvitel sem lett egyenletesebb, ill nem lett érzékelhetően használhatóbb a rendszer.
ZFS cache II
Nem maradt más mint a zfs paraméterezése. Ha ugyan..
root@ubuntu:~# zpool get all data
NAME PROPERTY VALUE SOURCE
data size 1,81T -
data capacity 60% -
data altroot - default
data health ONLINE -
data guid 729470933508434949 default
data version - default
data bootfs - default
data delegation on default
data autoreplace off default
data cachefile - default
data failmode wait default
data listsnapshots on local
data autoexpand off default
data dedupditto 0 default
data dedupratio 1.01x -
data free 731G -
data allocated 1,10T -
data readonly off -
data ashift 0 default
data comment - default
data expandsize - -
data freeing 0 default
data fragmentation 36% -
data leaked 0 default
data feature@async_destroy enabled local
data feature@empty_bpobj active local
data feature@lz4_compress active local
data feature@spacemap_histogram active local
data feature@enabled_txg active local
data feature@hole_birth active local
data feature@extensible_dataset enabled local
data feature@embedded_data active local
data feature@bookmarks enabled local
data feature@filesystem_limits enabled local
data feature@large_blocks enabled local
dedup kikapcsolva, csak az előző próbálkozások eredménye a dedupratio 1.01x érték.
Üres hely van, tehát ez nem lehet probléma.
A 'gugel' azt mondja hogy további gyorsítás nem lehetséges, mégis egy blogon találtam valami érdekeset: ZFS primarycache: all versus metadata
root@ubuntu:~# zfs get primarycache data
NAME PROPERTY VALUE SOURCE
data primarycache all local
root@ubuntu:~#
root@ubuntu:~# zfs set primarycache=metadata data
root@ubuntu:~#
root@ubuntu:~# zfs get primarycache data
NAME PROPERTY VALUE SOURCE
data primarycache metadata local
A próbálgatás eredménye elég bíztató, ugyan az árviteli sebesség 100-120 MB/mp, de az átvitel egyenletes, a 'szürke ablak' nem jelentkezett, legalábbis egy kliens gép erőteljes átvitele esetén nem.
Hogy mi lesz akkor, ha több kliens gép is nagyobb átviteli igénnyel lép fel?
az majd akkor derül ki, ha ez a körülmény létrejön.
Epilógus
Az eredmények a javítandó gépre átvíve, a javulás látványos, ráadásul a javítandó gép nagyobb, gyorsabb és 2-vel több mag van a processzorában.
Ebből nekem az jön le, hogy a zfs metaadat kezelésén még volna mit javítani. Ahogy a zfs sebessége sem kielégítő igazán.
Meg kell kérdőjeleznem, hogy a zfs jól használható e kis irodákban, és/vagy viszonylag kis teljesítményű szervereken. meglátjuk..
Most szerencsém vol..t..
- apostroph3 blogja
- A hozzászóláshoz be kell jelentkezni
- 1122 megtekintés
Hozzászólások
En inkabb az ubuntu defaultok ertelmesseget kerdojeleznem meg, semmint a zfs kepessegeit. Lehetne valami olyan konfig package, ami megoldja, hogy ilyen ertelmu defaultokkal jojjon a zfs konfigja.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
+1 azzal a plusz kitétellel, hogy a ZoL nem "a ZFS" en bloc
------------------------
{0} ok boto
boto ?
- A hozzászóláshoz be kell jelentkezni
Jo, hat kontextusaban ertettem. Pillanatnyilag Linuxon ez "a" ZFS.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Jó lenne egy zfs get all. A primarycache=metadata nem jó ötlet, ahogy a blog mutatja. A dedup sem volt szerencsés, az okozhatja még a gondot.
- A hozzászóláshoz be kell jelentkezni
root@ubuntu:~# zfs get all data
NAME PROPERTY VALUE SOURCE
data type filesystem -
data creation k szept 15 8:01 2015 -
data used 1,11T -
data available 672G -
data referenced 96K -
data compressratio 1.02x -
data mounted yes -
data quota none default
data reservation none default
data recordsize 128K default
data mountpoint /data default
data sharenfs off default
data checksum on default
data compression lz4 local
data atime off local
data devices on default
data exec on default
data setuid on default
data readonly off default
data zoned off default
data snapdir hidden default
data aclinherit restricted default
data canmount on default
data xattr on default
data copies 1 default
data version 5 -
data utf8only off -
data normalization none -
data casesensitivity sensitive -
data vscan off default
data nbmand off default
data sharesmb off default
data refquota none default
data refreservation none default
data primarycache metadata local
data secondarycache all default
data usedbysnapshots 0 -
data usedbydataset 96K -
data usedbychildren 1,11T -
data usedbyrefreservation 0 -
data logbias latency default
data dedup off local
data mlslabel none default
data sync standard default
data refcompressratio 1.00x -
data written 96K -
data logicalused 1,14T -
data logicalreferenced 14,5K -
data filesystem_limit none default
data snapshot_limit none default
data filesystem_count none default
data snapshot_count none default
data snapdev hidden default
data acltype off default
data context none default
data fscontext none default
data defcontext none default
data rootcontext none default
data relatime on local
data redundant_metadata all default
data overlay off default
root@ubuntu:~#
az atime, a compression és persze a primarycache kivételével, minden 'gyári' állapotban van.
- A hozzászóláshoz be kell jelentkezni
és igaz, de a fickó kis méretű fájlokat scannel, ráadásul közvetlenül a vason indítva a scannt. nekem viszont az nfs, és a zfs összhangján kellet javítani, nagy fájlok esetén.
kis fájlok továbbra is bele fognak férni a cache-kbe. tehát itt a lassulás nem számottevő v nincs is, a nagy fájloknál viszont az átvitel látványosan nő.
és ez a lényeg :)
valamint a blog a clamscan 4k-s korlátjára hivatkozva állapítja meg, hogy sokszor kell újraolvasnia az adatokat. ettől a magas processzorhasználat.
- A hozzászóláshoz be kell jelentkezni
Hogy férne a kis adat a cache-be, ha csak metaadatot cachelsz? Persze amíg kicsi a terhelés, lehet nem nagyon érződik, de mi lesz, ha nem, vagy ha nagy fájlokat olvasni is akarják? Ellenben secondarycache=metadata már értelmes lehetne, gyakorlatilag az egész metaadat elférhetne az SSD-n (és jelenleg is csak az van benne).
Érdemes lehetne egy recordsize=1M is, a nagy fájlokon ez javíthat, meg a metaadat kevesebb helyet foglal. Linuxon még a xattr=sa szokták nagyon ajánlani.
Látom van egy 4GB SLOG is. Kipróbálnám, ugyanaz-e a tapasztalat secondarycache=always és =disabled mellett is. Mekkora ARC van maximum engedélyezve egyébként?
Edit: Átgondolva a primarycache próbálkozásodat az lehet a limit, hogy az ARC nem tud elég metaadatot cachelni. Ezen segíthet az ARC tuningja (de nem kell metadata only!) és a recordsize növelés is. Mindenképpen ezutóbbival kezdeném, 16M-ig mehet asszem.
- A hozzászóláshoz be kell jelentkezni
hát egyrészről az nfs-nek is van, másrészről a másodlagos cache is dolgozok.
ha megcserélem az cache-k beállításait, akkor az olvasási sebesség 80-90 MB körül van 4GB-nál - hálózaton keresztül -
az írási sebesség visszaesik 80-95 MB közé 4GB másolásakor
míg az általam először beállított állapotban az írási sebesség 100-120 MB között ingadozik, míg az olvasási sebesség 85 alá nem esik de nem megy 95 fölé. itt valószínűleg a kliens korlátjába ütközik.
az utóbbi esetben a zcache partició használata sokkal erőteljesebb, bár több területet nem használ, vagy nem mérhető az 1 mp-es frissítéssel, viszont a bandwidth sokkal magasabb.
vagyis mégis csak a primarycache=metadata, secondarycache=all beállítás lehet a jó
ennél sokkal magasabb nyilván nem lesz mert a hálózat, és az nfs korlátjába ütközök.
magán az zfs-en biztos lehet gyorsítani, de ennek hasznát nem igen látom mivel a rendszer, és a rendszeradatok a ssd-n vannak. vagyis olvasni, és írni csak a hálózaton keresztül lehet a zfs partíciót.
- A hozzászóláshoz be kell jelentkezni
xattr=sa gyakorlatilag semmit sem jelent sebesség szempontjából, de lehet hogy csak a átvitel közel maximalis volta miatt.
most még jön a arc tuning, de már nem ma azt hiszem, nem beszélve arról hogy csak az éles rendszeren tudom azt pontosan behangolni..
- A hozzászóláshoz be kell jelentkezni
vagyis mégis csak a primarycache=metadata, secondarycache=all beállítás lehet a jó
Ez továbbra sem így műküdik. :) Ami nincs az elsődlegesben az a másodlagosban sem lehet. Nem véletlenül:
demand_data_hits 4 0
demand_data_misses 4 71494
demand_metadata_hits 4 11223
demand_metadata_misses 4 2086
És az L2 sincs kihasználva jelenleg:
l2_hits 4 0
l2_misses 4 73540
Viszont az is látszik, hogy amire én gyanakodtam, az sem a probléma. Bár nem tudom ez mennyire fedi a másolás alatti állapotot, de bőven lehetne még metadata cache:
arc_meta_used 4 23904056
arc_meta_limit 4 1505306112
arc_meta_max 4 28761576
Ettől függetlenül recordsize=1M továbbra is ajánlanám.
az utóbbi esetben a zcache partició használata sokkal erőteljesebb, bár több területet nem használ, vagy nem mérhető az 1 mp-es frissítéssel, viszont a bandwidth sokkal magasabb.
A fentiek alapján csak tölti fel zcache-t, de nem olvas belőle.
Még az NFS sync módjából eredhet a probléma. Látom korábban jól elírtam, a sync=disabled amire gondoltam (nem a secondarycache), amivel minden írás async lenne. Sok más ötletem most nincs.
A dedup tábla mennyit helyet foglal? (zpool status -D)
- A hozzászóláshoz be kell jelentkezni
no sorban, mert közben az idő is halad :))
a dedup taábla:
# zpool status -D
pool: data
state: ONLINE
scan: scrub repaired 0 in 4h46m with 0 errors on Sun Nov 13 13:48:50 2016
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
sdb ONLINE 0 0 0
logs
ubuntu--vg-zlog ONLINE 0 0 0
cache
ubuntu--vg-zcache ONLINE 0 0 0
errors: No known data errors
dedup: DDT entries 4224729, size 509 on disk, 164 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 3,97M 507G 477G 478G 3,97M 507G 477G 478G
2 57,2K 7,10G 5,71G 5,71G 116K 14,4G 11,5G 11,5G
4 858 101M 46,4M 46,7M 4,15K 494M 227M 229M
8 286 35,3M 22,6M 22,7M 3,19K 403M 279M 281M
16 13 1,25M 20,5K 52K 273 26,2M 424K 1,07M
32 10 1,00M 27K 40K 434 45,4M 1,15M 1,70M
64 1 128K 1K 4K 67 8,38M 67K 268K
128 5 640K 17K 20K 1,07K 137M 3,78M 4,29M
256 3 384K 9K 12K 864 108M 2,38M 3,38M
512 1 128K 4K 4K 995 124M 3,89M 3,89M
Total 4,03M 514G 483G 483G 4,10M 523G 489G 490G
ez volt vasárnap, most valahogy igy néz ki, de még dolgozik a dedup megszüntetésén, mert hogy bogarat ültettél a fülembe, de közben meg más teendőim is akadtak.
root@ubuntu:/sys/module/zfs/parameters# zpool status -D
pool: data
state: ONLINE
scan: scrub repaired 0 in 4h46m with 0 errors on Sun Nov 13 13:48:50 2016
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
sdb ONLINE 0 0 0
logs
ubuntu--vg-zlog ONLINE 0 0 0
cache
ubuntu--vg-zcache ONLINE 0 0 0
errors: No known data errors
dedup: DDT entries 377221, size 5711 on disk, 1844 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 347K 43,4G 26,4G 26,4G 347K 43,4G 26,4G 26,4G
2 20,8K 2,60G 1,43G 1,43G 42,6K 5,32G 2,93G 2,93G
4 593 74,1M 32,8M 32,8M 2,80K 358M 161M 161M
8 97 12,1M 4,70M 4,70M 884 110M 41,7M 41,7M
16 2 256K 8K 8K 44 5,50M 176K 176K
32 3 384K 12K 12K 124 15,5M 496K 496K
128 4 512K 16K 16K 925 116M 3,61M 3,61M
256 2 256K 8K 8K 523 65,4M 2,04M 2,04M
512 1 128K 4K 4K 624 78M 2,44M 2,44M
Total 368K 46,0G 27,9G 27,9G 395K 49,4G 29,5G 29,5G
közben hétfőn hajnalban annyit tettem, hogy az éles rendszeren felemeltem a zfs_arc_max értékét 5368709120 (5GB) ami az elérhető ram mennyiségének közel 1/3. része, ezzel nagyjából meg is javult az éles rendszer, habár az átvitel most is ingadozó egy kicsit, de ad-hoc megoldásnak jó.
megtettem ezt a tesz rendszeren is, bár itt ez a beállítás a ram több mint fele, erre válaszul swap-elni kezdett.
ugyhogy levettel 4294967296 (4GB) ami pont a fele a ram mennyiségének. és az általad javasolt 1M-re vettel a recordsize-t.
most még játszom vele.
közben a dedup table:
dedup: DDT entries 50269, size 42859 on disk, 13838 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 46,9K 5,87G 3,04G 3,04G 46,9K 5,87G 3,04G 3,04G
2 1,77K 227M 117M 117M 3,93K 503M 262M 262M
4 336 42M 24,7M 24,7M 1,70K 218M 128M 128M
8 62 7,75M 4,33M 4,33M 547 68,4M 38,3M 38,3M
128 1 128K 4K 4K 173 21,6M 692K 692K
256 1 128K 4K 4K 410 51,2M 1,60M 1,60M
Total 49,1K 6,14G 3,18G 3,18G 53,7K 6,71G 3,46G 3,46G
- A hozzászóláshoz be kell jelentkezni
miket tudsz kérdezni :))
root@ubuntu:~# cat /proc/spl/kstat/zfs/arcstats
6 1 0x01 91 4368 4472106067 2073110806091
name type data
hits 4 11223
misses 4 73588
demand_data_hits 4 0
demand_data_misses 4 71494
demand_metadata_hits 4 11223
demand_metadata_misses 4 2086
prefetch_data_hits 4 0
prefetch_data_misses 4 0
prefetch_metadata_hits 4 0
prefetch_metadata_misses 4 8
mru_hits 4 3402
mru_ghost_hits 4 0
mfu_hits 4 7821
mfu_ghost_hits 4 0
deleted 4 50
mutex_miss 4 0
evict_skip 4 25
evict_not_enough 4 0
evict_l2_cached 4 0
evict_l2_eligible 4 548864
evict_l2_ineligible 4 0
evict_l2_skip 4 0
hash_elements 4 1687
hash_elements_max 4 2030
hash_collisions 4 378
hash_chains 4 0
hash_chain_max 4 2
p 4 1003537408
c 4 2007074816
c_min 4 33554432
c_max 4 2007074816
size 4 23904056
hdr_size 4 688704
data_size 4 0
metadata_size 4 20214784
other_size 4 3000568
anon_size 4 16384
anon_evictable_data 4 0
anon_evictable_metadata 4 0
mru_size 4 15555584
mru_evictable_data 4 0
mru_evictable_metadata 4 9585664
mru_ghost_size 4 0
mru_ghost_evictable_data 4 0
mru_ghost_evictable_metadata 4 0
mfu_size 4 4642816
mfu_evictable_data 4 0
mfu_evictable_metadata 4 4638720
mfu_ghost_size 4 0
mfu_ghost_evictable_data 4 0
mfu_ghost_evictable_metadata 4 0
l2_hits 4 0
l2_misses 4 73540
l2_feeds 4 2019
l2_rw_clash 4 0
l2_read_bytes 4 0
l2_write_bytes 4 12360704
l2_writes_sent 4 169
l2_writes_done 4 169
l2_writes_error 4 0
l2_writes_lock_retry 4 0
l2_evict_lock_retry 4 0
l2_evict_reading 4 0
l2_evict_l1cached 4 0
l2_free_on_write 4 0
l2_cdata_free_on_write 4 0
l2_abort_lowmem 4 0
l2_cksum_bad 4 0
l2_io_error 4 0
l2_size 4 14130176
l2_asize 4 4633088
l2_hdr_size 4 0
l2_compress_successes 4 1660
l2_compress_zeros 4 0
l2_compress_failures 4 36
memory_throttle_count 4 0
duplicate_buffers 4 0
duplicate_buffers_size 4 0
duplicate_reads 4 0
memory_direct_count 4 0
memory_indirect_count 4 0
arc_no_grow 4 0
arc_tempreserve 4 0
arc_loaned_bytes 4 0
arc_prune 4 0
arc_meta_used 4 23904056
arc_meta_limit 4 1505306112
arc_meta_max 4 28761576
arc_meta_min 4 16777216
arc_need_free 4 0
arc_sys_free 4 62717952
root@ubuntu:~#
- A hozzászóláshoz be kell jelentkezni