zfs - NFS Performance

gadean

Depp vom Dienst!
Hi,
schon wieder ich mit einem Thema rund um zfs, dieses mal geht es um die Schreibgeschwindigkeit über NFS, ein ESXi Server nutz den Pool als Speicher und ist mittels NFS angebunden, ESXi nutzt eine "sync connection" (mir fällt gerade die deutsche Übersetzung nicht ein). Also ein ZIL hinzugefügt um die Schreibperformance zu verbessern, was auch geringfügig bei kleineren Dateien funktioniert. Bei größeren jedoch bricht die Verbindung ein und schreibt nur noch "burst"-artig.

Nun, nach mehreren Tagen der Recherchen, habe ich immer noch keine Lösung für eine produktive Umgebung gefunden, nur etwas mit "nfs_nfsdport.c" editieren (den nfs-server modifizieren: Link), jedoch finde ich dass das absolut nicht für ein Prod. System geeignet ist, weswegen ich mich Hilfe suchend an euch wende.

Den Pool konnte ich bisher noch nicht überarbeiten (Zeit ist Geld und andere Projekte haben atm. vor rang), die Platten hängen (abgesehen vom ZIL & L2ARC) "roh" im Pool.

OS: FreeBSD 9.1-RELEASE
Anbei mal die zfs-stats Ausgabe:
Code:
------------------------------------------------------------------------
ZFS Subsystem Report				Wed Apr  9 23:24:22 2014
------------------------------------------------------------------------

System Information:

	Kernel Version:				901000 (osreldate)
	Hardware Platform:			amd64
	Processor Architecture:			amd64

	ZFS Storage pool Version:		28
	ZFS Filesystem Version:			5

FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root
11:24PM  up  6:59, 1 user, load averages: 0.05, 0.12, 0.09

------------------------------------------------------------------------

System Memory:

	0.20%	12.11	MiB Active,	0.39%	23.14	MiB Inact
	37.54%	2.17	GiB Wired,	0.15%	8.74	MiB Cache
	61.71%	3.56	GiB Free,	0.01%	568.00	KiB Gap

	Real Installed:				6.00	GiB
	Real Available:			99.52%	5.97	GiB
	Real Managed:			96.68%	5.77	GiB

	Logical Total:				6.00	GiB
	Logical Used:			40.11%	2.41	GiB
	Logical Free:			59.89%	3.59	GiB

Kernel Memory:					1.98	GiB
	Data:				98.99%	1.96	GiB
	Text:				1.01%	20.50	MiB

Kernel Memory Map:				3.31	GiB
	Size:				57.09%	1.89	GiB
	Free:				42.91%	1.42	GiB

------------------------------------------------------------------------

ARC Summary: (HEALTHY)
	Memory Throttle Count:			0

ARC Misc:
	Deleted:				505.81k
	Recycle Misses:				3.78k
	Mutex Misses:				248
	Evict Skips:				12.86k

ARC Size:				39.11%	1.87	GiB
	Target Size: (Adaptive)		88.13%	4.21	GiB
	Min Size (Hard Limit):		12.50%	610.93	MiB
	Max Size (High Water):		8:1	4.77	GiB

ARC Size Breakdown:
	Recently Used Cache Size:	91.30%	3.84	GiB
	Frequently Used Cache Size:	8.70%	374.94	MiB

ARC Hash Breakdown:
	Elements Max:				257.50k
	Elements Current:		36.21%	93.25k
	Collisions:				1.19m
	Chain Max:				11
	Chains:					21.16k

------------------------------------------------------------------------

ARC Efficiency:					4.38m
	Cache Hit Ratio:		89.95%	3.94m
	Cache Miss Ratio:		10.05%	440.62k
	Actual Hit Ratio:		71.62%	3.14m

	Data Demand Efficiency:		93.39%	3.08m
	Data Prefetch Efficiency:	43.15%	384.61k

	CACHE HITS BY CACHE LIST:
	  Anonymously Used:		19.12%	754.03k
	  Most Recently Used:		23.84%	940.25k
	  Most Frequently Used:		55.79%	2.20m
	  Most Recently Used Ghost:	0.49%	19.22k
	  Most Frequently Used Ghost:	0.77%	30.40k

	CACHE HITS BY DATA TYPE:
	  Demand Data:			72.84%	2.87m
	  Prefetch Data:		4.21%	165.98k
	  Demand Metadata:		6.45%	254.43k
	  Prefetch Metadata:		16.50%	650.85k

	CACHE MISSES BY DATA TYPE:
	  Demand Data:			46.14%	203.29k
	  Prefetch Data:		49.62%	218.63k
	  Demand Metadata:		3.87%	17.04k
	  Prefetch Metadata:		0.38%	1.66k

------------------------------------------------------------------------

L2 ARC Summary: (HEALTHY)
	Passed Headroom:			849.23k
	Tried Lock Failures:			10.13k
	IO In Progress:				74
	Low Memory Aborts:			2
	Free on Write:				651
	Writes While Full:			2.85k
	R/W Clashes:				1
	Bad Checksums:				0
	IO Errors:				0
	SPA Mismatch:				0

L2 ARC Size: (Adaptive)				3.66	GiB
	Header Size:			0.13%	5.03	MiB

L2 ARC Evicts:
	Lock Retries:				0
	Upon Reading:				1

L2 ARC Breakdown:				440.49k
	Hit Ratio:			13.99%	61.63k
	Miss Ratio:			86.01%	378.86k
	Feeds:					28.02k

L2 ARC Buffer:
	Bytes Scanned:				14.97	TiB
	Buffer Iterations:			28.02k
	List Iterations:			1.77m
	NULL List Iterations:			20.04k

L2 ARC Writes:
	Writes Sent:			100.00%	12.13k

------------------------------------------------------------------------

File-Level Prefetch: (HEALTHY)

DMU Efficiency:					9.41m
	Hit Ratio:			42.33%	3.98m
	Miss Ratio:			57.67%	5.43m

	Colinear:				5.43m
	  Hit Ratio:			0.07%	3.87k
	  Miss Ratio:			99.93%	5.42m

	Stride:					3.85m
	  Hit Ratio:			100.00%	3.85m
	  Miss Ratio:			0.00%	102

DMU Misc:
	Reclaim:				5.42m
	  Successes:			1.48%	80.05k
	  Failures:			98.52%	5.34m

	Streams:				136.72k
	  +Resets:			0.46%	624
	  -Resets:			99.54%	136.09k
	  Bogus:				0

------------------------------------------------------------------------

VDEV cache is disabled

------------------------------------------------------------------------

ZFS Tunables (sysctl):
	kern.maxusers                           384
	vm.kmem_size                            6198607872
	vm.kmem_size_scale                      1
	vm.kmem_size_min                        0
	vm.kmem_size_max                        329853485875
	vfs.zfs.l2c_only_size                   2977833472
	vfs.zfs.mfu_ghost_data_lsize            1582170624
	vfs.zfs.mfu_ghost_metadata_lsize        54956544
	vfs.zfs.mfu_ghost_size                  1637127168
	vfs.zfs.mfu_data_lsize                  291110912
	vfs.zfs.mfu_metadata_lsize              9934848
	vfs.zfs.mfu_size                        304603136
	vfs.zfs.mru_ghost_data_lsize            2745696256
	vfs.zfs.mru_ghost_metadata_lsize        96553472
	vfs.zfs.mru_ghost_size                  2842249728
	vfs.zfs.mru_data_lsize                  1556236800
	vfs.zfs.mru_metadata_lsize              98225152
	vfs.zfs.mru_size                        1670819328
	vfs.zfs.anon_data_lsize                 0
	vfs.zfs.anon_metadata_lsize             0
	vfs.zfs.anon_size                       2281472
	vfs.zfs.l2arc_norw                      1
	vfs.zfs.l2arc_feed_again                1
	vfs.zfs.l2arc_noprefetch                1
	vfs.zfs.l2arc_feed_min_ms               200
	vfs.zfs.l2arc_feed_secs                 1
	vfs.zfs.l2arc_headroom                  2
	vfs.zfs.l2arc_write_boost               8388608
	vfs.zfs.l2arc_write_max                 8388608
	vfs.zfs.arc_meta_limit                  1281216512
	vfs.zfs.arc_meta_used                   154853312
	vfs.zfs.arc_min                         640608256
	vfs.zfs.arc_max                         5124866048
	vfs.zfs.dedup.prefetch                  1
	vfs.zfs.mdcomp_disable                  0
	vfs.zfs.write_limit_override            0
	vfs.zfs.write_limit_inflated            19235143680
	vfs.zfs.write_limit_max                 801464320
	vfs.zfs.write_limit_min                 33554432
	vfs.zfs.write_limit_shift               3
	vfs.zfs.no_write_throttle               0
	vfs.zfs.zfetch.array_rd_sz              1048576
	vfs.zfs.zfetch.block_cap                256
	vfs.zfs.zfetch.min_sec_reap             2
	vfs.zfs.zfetch.max_streams              8
	vfs.zfs.prefetch_disable                0
	vfs.zfs.mg_alloc_failures               8
	vfs.zfs.check_hostid                    1
	vfs.zfs.recover                         0
	vfs.zfs.txg.synctime_ms                 1000
	vfs.zfs.txg.timeout                     5
	vfs.zfs.vdev.cache.bshift               16
	vfs.zfs.vdev.cache.size                 0
	vfs.zfs.vdev.cache.max                  16384
	vfs.zfs.vdev.write_gap_limit            4096
	vfs.zfs.vdev.read_gap_limit             32768
	vfs.zfs.vdev.aggregation_limit          131072
	vfs.zfs.vdev.ramp_rate                  2
	vfs.zfs.vdev.time_shift                 6
	vfs.zfs.vdev.min_pending                4
	vfs.zfs.vdev.max_pending                10
	vfs.zfs.vdev.bio_flush_disable          0
	vfs.zfs.cache_flush_disable             0
	vfs.zfs.zil_replay_disable              0
	vfs.zfs.zio.use_uma                     0
	vfs.zfs.snapshot_list_prefetch          0
	vfs.zfs.version.zpl                     5
	vfs.zfs.version.spa                     28
	vfs.zfs.version.acl                     1
	vfs.zfs.debug                           0
	vfs.zfs.super_owner                     0

------------------------------------------------------------------------
 
Hallo gadean,

das thema interessiert mich auch... Und Du musst keine deutschen Übersetzungen suchen ("sync connection") - fast wäre es mir sogar lieber, wenn alles andere hier (auch) auf Englisch wäre ;-)

Aber zurück: ich arbeite schon länger mit ZFS/NFS, Solaris und FreeBSD. Die ersten Erfahrungen habe ich unter Solaris 10 gesammelt. Und ich habe festgestellt, dass beispielsweise ein Löschen vieler winzig kleiner Dateien remote mind. 100 mal langsamer ist, als lokal - wobei ja nun nicht wirklich was übers Netzt geht... Gestern habe ich zu Hause auf einem PC auch ein ähnliches Verhalten (wie Deines) beobachtet, dass mich stört: Wenn ich z.B. von einem auf einen anderen Rechner Dateien synchronisiere, dann ist die Antwortzeit auf dem Zielrechner zu Eingaben wie etwa "emacs file" oder "ls -al dir" manchmal etliche Sekunden. Habe mal geschaut, und festgestellt das das ARC (Das "Komplement" zum ZIL) nahezu all meinen RAM konsumiert. Ich werde mal schauen, ob mit Modifikationen in /boot/loader.conf wie etwa 'vfs.zfs.arc_max="2G"' sich Verbesserungen sehen lassen... Dieses langsame Verhalten ist ganz besonders bei grossen Dateien zu bemerken...

Naja, das ist keine Antwort auf Deine Frage, vielleicht hilft es trotzdem weiter

Grüße, Norbert
 
Also, den ARC zu begrenzen ist Quatsch, solange keine andere Anwendung viel Arbeitsspeicher braucht. Auch hat der ARC mal nichts mit der NFS-Performance zu tun. Wie verhält sich denn der Datentransfer, wenn du lokal große Dateien erzeugst, also nicht über NFS?

Rob
 
Ach entschuldige, da hab ich einige wichtige Infos doch echt vergessen mit zu posten - Schande über mein Haupt

Also die schlechte Performance hängt mit der "sync connection" mit dem ESXi zusammen, eig. sollte ein ZIL das Problem lösen (tut es auch teilst), ohne ist die Performance noch wesentlich schlechter. Als ZIL wird eine SSD genutzt, die über SATA3 angeschlossen ist.
Code:
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <MKNSSDCR120GB-DX 506ABBF0> ATA-8 SATA 3.x device
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4

Also über samba läuft alles ziemlich gut: Link

Lokal sieht es genauso aus, wobei mich die erhöhte Aktivität des cache0 Device verwundert?
Code:
[ohaucke@stor01 /tank/files]# /usr/bin/time -h dd if=/dev/zero of=testfile bs=1G count=5
5+0 records in
5+0 records out
5368709120 bytes transferred in 39.507639 secs (135890407 bytes/sec)
        40.45s real             0.00s user              8.52s sys

Anbei noch ein paar Zeilen aus "zpool iostat" während dem lokalen schreiben
Code:
                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           598G  1.23T      0  1.22K      0  82.8M
  mirror       299G   629G      0      0      0      0
    ada1          -      -      0      0      0      0
    ada2          -      -      0      0      0      0
  mirror       299G   629G      0      0      0      0
    ada3          -      -      0      0      0      0
    ada4          -      -      0      0      0      0
logs              -      -      -      -      -      -
  gpt/log0    1.04M  7.94G      0  1.22K      0  82.8M
cache             -      -      -      -      -      -
  gpt/cache0  31.7G  68.3G      0    319      0  40.0M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           598G  1.23T      0  1.36K      0   126M
  mirror       299G   629G      0    422      0  45.9M
    ada1          -      -      0    372      0  45.9M
    ada2          -      -      0    436      0  53.9M
  mirror       299G   629G      0    399      0  43.0M
    ada3          -      -      0    351      0  43.4M
    ada4          -      -      0    348      0  43.0M
logs              -      -      -      -      -      -
  gpt/log0    1.04M  7.94G      0    575      0  37.1M
cache             -      -      -      -      -      -
  gpt/cache0  31.8G  68.2G      3    301   511K  36.8M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           598G  1.23T      8  1.18K  1.12M   106M
  mirror       299G   629G      1    555   255K  52.1M
    ada1          -      -      0    483      0  52.1M
    ada2          -      -      1    419   255K  44.1M
  mirror       299G   629G      6    636   894K  53.7M
    ada3          -      -      3    522   511K  54.5M
    ada4          -      -      2    517   383K  53.7M
logs              -      -      -      -      -      -
  gpt/log0    1008M  6.95G      0     20      0   339K
cache             -      -      -      -      -      -
  gpt/cache0  31.8G  68.2G      3    302   511K  36.9M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           598G  1.23T      3  1.45K   511K   156M
  mirror       299G   629G      2    766   384K  77.4M
    ada1          -      -      2    680   384K  77.4M
    ada2          -      -      0    684      0  77.4M
  mirror       299G   629G      0    704   128K  78.5M
    ada3          -      -      0    667   128K  77.3M
    ada4          -      -      0    677      0  78.5M
logs              -      -      -      -      -      -
  gpt/log0    1008M  6.95G      0     14      0   168K
cache             -      -      -      -      -      -
  gpt/cache0  31.8G  68.2G      0    342   128K  42.1M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           598G  1.23T      3  1.19K   511K   130M
  mirror       299G   629G      0    646   128K  72.6M
    ada1          -      -      0    587      0  72.6M
    ada2          -      -      0    587   128K  72.6M
  mirror       299G   629G      2    552   384K  56.8M
    ada3          -      -      2    465   384K  56.8M
    ada4          -      -      0    474      0  57.9M
logs              -      -      -      -      -      -
  gpt/log0    1.08M  7.94G      0     20      0   392K
cache             -      -      -      -      -      -
  gpt/cache0  31.9G  68.1G      4    330   639K  41.0M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           599G  1.23T      3   1018   511K  88.4M
  mirror       299G   629G      0    534   128K  41.1M
    ada1          -      -      0    419      0  41.1M
    ada2          -      -      0    422   128K  41.5M
  mirror       299G   629G      2    466   384K  46.9M
    ada3          -      -      0    436   128K  46.9M
    ada4          -      -      1    435   256K  46.8M
logs              -      -      -      -      -      -
  gpt/log0    1.86M  7.94G      0     17      0   328K
cache             -      -      -      -      -      -
  gpt/cache0  31.9G  68.1G      5    321   655K  39.7M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           599G  1.23T      2  1.21K   384K   129M
  mirror       299G   629G      0    614   128K  60.1M
    ada1          -      -      0    518      0  60.1M
    ada2          -      -      0    531   128K  61.7M
  mirror       299G   629G      1    614   256K  68.5M
    ada3          -      -      0    612   128K  72.8M
    ada4          -      -      0    571   128K  67.7M
logs              -      -      -      -      -      -
  gpt/log0    2.95M  7.93G      0     11      0   244K
cache             -      -      -      -      -      -
  gpt/cache0  32.0G  68.0G      3    304   511K  37.7M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           599G  1.23T      3  1.28K   511K   136M
  mirror       299G   629G      1    609   256K  70.0M
    ada1          -      -      0    588   128K  70.0M
    ada2          -      -      0    605   128K  72.3M
  mirror       299G   629G      1    684   256K  65.6M
    ada3          -      -      1    539   256K  61.4M
    ada4          -      -      0    614      0  70.8M
logs              -      -      -      -      -      -
  gpt/log0    3.62M  7.93G      0     18      0   120K
cache             -      -      -      -      -      -
  gpt/cache0  32.0G  68.0G      4    336   639K  41.0M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           599G  1.23T      3  1.30K   511K   117M
  mirror       299G   629G      0    665   128K  54.8M
    ada1          -      -      0    507      0  54.8M
    ada2          -      -      0    472   128K  50.6M
  mirror       299G   629G      2    643   384K  61.5M
    ada3          -      -      0    550   128K  61.5M
    ada4          -      -      1    508   256K  56.3M
logs              -      -      -      -      -      -
  gpt/log0    3.62M  7.93G      0     21      0   336K
cache             -      -      -      -      -      -
  gpt/cache0  32.0G  68.0G      5    327   767K  40.0M
------------  -----  -----  -----  -----  -----  -----

                 capacity     operations    bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
tank           599G  1.23T     13  1.52K  1.75M   154M
  mirror       300G   628G      7    755  1023K  76.4M
    ada1          -      -      4    651   639K  76.4M
    ada2          -      -      2    651   384K  76.4M
  mirror       299G   629G      5    716   767K  76.1M
    ada3          -      -      1    646   256K  76.1M
    ada4          -      -      3    645   511K  76.1M
logs              -      -      -      -      -      -
  gpt/log0    4.14M  7.93G      0     80      0  1.16M
cache             -      -      -      -      -      -
  gpt/cache0  32.1G  67.9G      8    314  1.12M  38.6M
------------  -----  -----  -----  -----  -----  -----

Code:
[ohaucke@stor01 ~]$ zfs get all tank/files
NAME        PROPERTY              VALUE                  SOURCE
tank/files  type                  filesystem             -
tank/files  creation              Fri Aug 23 17:22 2013  -
tank/files  used                  5.00G                  -
tank/files  available             1.20T                  -
tank/files  referenced            5.00G                  -
tank/files  compressratio         1.00x                  -
tank/files  mounted               yes                    -
tank/files  quota                 none                   default
tank/files  reservation           none                   default
tank/files  recordsize            128K                   default
tank/files  mountpoint            /tank/files            default
tank/files  sharenfs              off                    default
tank/files  checksum              on                     default
tank/files  compression           off                    inherited from tank
tank/files  atime                 off                    inherited from tank
tank/files  devices               on                     default
tank/files  exec                  on                     default
tank/files  setuid                on                     default
tank/files  readonly              off                    default
tank/files  jailed                off                    default
tank/files  snapdir               hidden                 default
tank/files  aclmode               discard                default
tank/files  aclinherit            restricted             default
tank/files  canmount              on                     default
tank/files  xattr                 off                    temporary
tank/files  copies                1                      default
tank/files  version               5                      -
tank/files  utf8only              off                    -
tank/files  normalization         none                   -
tank/files  casesensitivity       sensitive              -
tank/files  vscan                 off                    default
tank/files  nbmand                off                    default
tank/files  sharesmb              off                    default
tank/files  refquota              none                   default
tank/files  refreservation        none                   default
tank/files  primarycache          all                    default
tank/files  secondarycache        all                    default
tank/files  usedbysnapshots       0                      -
tank/files  usedbydataset         5.00G                  -
tank/files  usedbychildren        0                      -
tank/files  usedbyrefreservation  0                      -
tank/files  logbias               latency                default
tank/files  dedup                 off                    inherited from tank
tank/files  mlslabel                                     -
tank/files  sync                  standard               inherited from tank
tank/files  refcompressratio      1.00x                  -
tank/files  written               5.00G                  -


Offtopic:
Wie schaut das eig. unter R10.0 aus mit 4k Sektorgröße, nutzt man da immer noch gnop, oder kann man sich das da mittlerweile sparen?
 
Also, den ARC zu begrenzen ist Quatsch, solange keine andere Anwendung viel Arbeitsspeicher braucht. Auch hat der ARC mal nichts mit der NFS-Performance zu tun. Wie verhält sich denn der Datentransfer, wenn du lokal große Dateien erzeugst, also nicht über NFS?

Rob

da hast Du bestimmt recht. Aber trotzdem... da laufen immer ein paar andere Anwendungen, von daher begrenze ich den ARC meistens auf 1-8 GB, je nach Maschine

Grüße, Norbert
 
@gadean: gegen die langsame NFS performance habe ich bei dem betroffenen ZFS set das sync auf Serverseite abgeschaltet:
Code:
appdata/nfs/db  sync                  disabled               local
damit ist NFS schnell, die (vorrangig Linux) Clients kacken nicht ab, weil die Verbindung hängt/langsam ist.
 
@gadean: gegen die langsame NFS performance habe ich bei dem betroffenen ZFS set das sync auf Serverseite abgeschaltet
Achtung! Ich zitiere mal:
Code:
sync=disabled
  Synchronous requests are disabled.  File system transactions
  only commit to stable storage on the next DMU transaction group
  commit which can be many seconds.  This option gives the
  highest performance.  However, it is very dangerous as ZFS
  is ignoring the synchronous transaction demands of
  applications such as databases or NFS.
  Setting sync=disabled on the currently active root or /var
  file system may result in out-of-spec behavior, application data
  loss and increased vulnerability to replay attacks.
  This option does *NOT* affect ZFS on-disk consistency.
  Administrators should only use this when these risks are understood.
 
@makenoob: Danke, aber die Methode kenne ich schon und wollte ich nicht in einem Produktiv System einsetzten.
[...] Nun, nach mehreren Tagen der Recherchen, habe ich immer noch keine Lösung für eine produktive Umgebung gefunden, nur etwas mit "nfs_nfsdport.c" editieren (den nfs-server modifizieren: Link), jedoch finde ich dass das absolut nicht für ein Prod. System geeignet ist, [...]
 
Achtung! Ich zitiere mal:
Code:
sync=disabled
  Synchronous requests are disabled.  File system transactions
  only commit to stable storage on the next DMU transaction group
  commit which can be many seconds.  This option gives the
  highest performance.  However, it is very dangerous as ZFS
  is ignoring the synchronous transaction demands of
  applications such as databases or NFS.
  Setting sync=disabled on the currently active root or /var
  file system may result in out-of-spec behavior, application data
  loss and increased vulnerability to replay attacks.
  This option does *NOT* affect ZFS on-disk consistency.
  Administrators should only use this when these risks are understood.
Ja, ich weiss. Ich schalte sowas auch nicht ein, ohne mich vorher darüber zu informieren. Leider war die Performance mit einer MLC als ZiL auch nicht wirdklich besser. In top lässt sich die ARC-Ausnutzung beobachten und nachdem der sync auf dem Set disabled ist, wird er wesentlich großzügiger gefüllt, bevor er geflusht wird
 
Hallo,
schau mal unter ESXI / Config / Advanced Settings/ Net / NET.TcpipHeapSize Standart 0 änden auf 32

ob dann das Problem noch besteht.

Gruss

Jörg

PS: und was Für SSD und HD verwendest zu pro zpool.
 
Die Heapsize ändere ich nachher mal.

Code:
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <MKNSSDCR120GB-DX 506ABBF0> ATA-8 SATA 3.x device
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4
ada1 at ata2 bus 0 scbus2 target 0 lun 0
ada1: <Hitachi HDS721010CLA330 JP4OA3MA> ATA-8 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad8
ada2 at ata3 bus 0 scbus3 target 0 lun 0
ada2: <Hitachi HDS721010CLA330 JP4OA3MA> ATA-8 SATA 2.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada2: Previously was known as ad10
ada3 at ata4 bus 0 scbus4 target 0 lun 0
ada3: <Hitachi HDS721010CLA330 JP4OA3MA> ATA-8 SATA 2.x device
ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada3: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada3: Previously was known as ad12
ada4 at ata5 bus 0 scbus5 target 0 lun 0
ada4: <Hitachi HDS721010CLA330 JP4OA3MA> ATA-8 SATA 2.x device
ada4: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada4: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada4: Previously was known as ad14
 
FreeBSD 10.0 benutzt gnop während der Installation. Du kannst herausfinden, ob der zpool sie übernommen hat mit
Code:
zdb
Der Parameter ashift sollte da 12 zurückgeben. Da Du Platten roh an den zpool gehängt hast, sind sie zwangsweise aligned.
 
Danke, dann werde ich das beim Update auf 10 mal in angriff nehmen, aber an den Performance Probleme sollte das eig. nichts ändern? Lokal und über smb läuft es immerhin ohne Probleme.
 
Wie sehen denn die mount-Optionen bei den NFS-Mounts aus? Kannst du die betreffenden Einträge aus der /etc/fstab hier mal hinpasten?
 
Weils etwas hier reinpasst: Weiß jmd, ob ein Ändern von sync=disabled auf sync=standard (oder sogar "always") sofort in dem Moment alles rausschreibt, was noch im ARC hängt, oder gilt das nur für "neue" writes?

Hintergrund ist der, dass ich auch mit sync=disabled rumgurke. Ist halt nur Hobby zu Hause. Wenn die UPS sich meldet, wollte ich vorsichtshalber die datasets auf "sicher" schalten.
 
@nakal Wenn ich wüsste wo ich die beim ESXi finde :D hab den Speicher übers UI vom ESXi ge-mounted und eine Windows VM drauf die ein Netzlaufwerk zur Verfügung stellt
 
@TCM: Ich bin mir nicht zu 100% sicher, aber ich glaube der Charakter einer Transaktion wird beim Anlegen durch den Transaktionsmanager gesetzt. Das würde bedeuten, dass ein Umstellen der Sync-Eigenschaft nur neu geschriebene Daten betrifft, aber nichts was noch im Flug ist.
 
Achso (falls ich das jetzt überhaupt verstanden habe)... wenn das virtuell vom VM-Host an VM-Client übergeben wird, kann es eine Inkompatibilität zwischen VM-Software und dem NFS-Server geben. Ich hatte das auch mal mit Virtualbox, dass der Zugriff seltsame Muster aufwies (bei dem VBox-Share). Oft empfiehlt sich das ganze als 'ne Bridge zu gestalten und dann direkt im Client zu mounten.
 
Die FreeBSD Kiste ist mittels NFS am ESXi Server direkt angebunden, auf dem Speicher der FreeBSD Maschine liegen die VMs die mit dem ESXi virtualisiert werden. Übertrage ich Daten von einer echten Maschine in eine der VMs ist die Übertragung burst-artig
wie hier zusehen ist:
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
 
Das Problem besteht immer noch :(
ich hab mich jetzt noch weiter mit dem Thema beschäftigt und verdächtige den ZFS write cache. Soweit ich das verstanden habe wird jede synchrone Schreibanweisung in "transaction groups" gruppiert, dort werden die Schreibprozesse zusammen gefasst (default größe: 1/8 des Memory) und danach geschrieben, wenn jetzt eine neue "transaction group" gefüllt wird bevor die alte fertig geschrieben wurde, wird der I/O pausiert bis die alte gruppe fertig ist. Das ganze würde zumindest auf die Symptome passen? Aber müsste da nicht das SLOG gegen wirken?

Quelle: Link
Absatz: Tangent: Dangers of overly large ZFS write cache.

Mich interessiert nun welche Einstellungen (sysctl, etc...), wie viel RAM und welches Gerät als SLOG ihr (jene die ein ZFS-Pool über NFS sharen *mit synchronen Schreibprozessen*) habt.
 
Zuletzt bearbeitet:
Deaktiviere mal testweise TSO. Sollte das etwas ändern gibt es den Bugfix in 10-stable die Anzahl der "Header" wurde von 32 auf 35 erhöht. Ich habe gerade keinen Zugang zu meinen Mails mit dem passenden ML Thread dazu.
 
Die NET.TcpipHeapSize hab ich nicht geändert, recordsize teste ich morgen mal und mehr als 8GB RAM mag das Board nicht :(
Danke für den Link zum PDF, werde es mir morgen mal in Ruhe durchlesen :)

@Crest du meinst sicher net.inet.tcp.tso ?

Ich bin euch allen dankbar für eure Hilfe :)
 
Zurück
Oben