ubuntu server & zfs --> accelR8

Baj van! Ha nagy, több GB méretű fájlt másolok a szerverre, akkor a másolás alatt használhatatlan a fájlkezelő (ubuntu) beszürkül, és a windowsnál is hasonlóan lassú a másolás.

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..

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

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.


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.

é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.

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.

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.

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)

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

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:~#