[zfs-discuss] Zfs tuning advisory

Richard Elling richard.elling at richardelling.com
Thu Dec 8 00:50:24 EST 2016


> On Dec 7, 2016, at 2:12 AM, Gordan Bobic via zfs-discuss <zfs-discuss at list.zfsonlinux.org> wrote:
> 
> mysqltuner is worse than useless, in my 20-odd years experience as a MySQL DBA. If you know what you are doing, it becomes pretty obvious that some of the things it ends up suggesting aren't sane. If you are a newbie and have no idea what you are doing, it will lead you completely astray. Unless you really, _really_ know what you are soing, the _only_ setting you should be changing is the innodb_buffer_pool_size. The defaults for the rest are quite reasonable for anything that an inexperienced DBA should be allowed to touch unsupervised.
> 
> ZFS is similar - defaults are reasonable and auto-tuning for most reasonable uses, and if you don't have enough underlying knowledge about how your entire stack (from application, down to the file system, down to physical hardware and underlying disks) you should not be touching it.

I view the philosophy as: if you can determine a method for tuning, then put it in the code :-)

> 
> 
> On Wed, Dec 7, 2016 at 9:54 AM, Arman Khalatyan via zfs-discuss <zfs-discuss at list.zfsonlinux.org <mailto:zfs-discuss at list.zfsonlinux.org>> wrote:
> 
> hi,
> Are there any chance to design some zfs tuning advisory script based on the load using  arc_summary.py/arcstats <http://arc_summary.py/arcstats>?
> I was thinking something like mysqltuner.pl <http://mysqltuner.pl/> from http://mysqltuner.com/ <http://mysqltuner.com/> .
> based on the system load it gives some basic idea where to tune.
> Is it possible to do the same with zol? If not, please explain why?

Unfortunately, arcstats can only be effectively used to answer a few questions:
1. do you have enough RAM for ARC
2. would adding (more) L2ARC help the hit rate

To get a full understanding of system performance, there isn't enough instrumentation.
That said, for Solaris I do have an analyzer that can be ported and updated. Here is an
example of output for the ARC and prefetcher analysis:

## ZFS ARC analysis
Current size (GiB) = 17.0 (31% of locked memory)
+ Analysis: status=warning: ARC size is less than 80% of locked memory
	Buf size (GiB) = 0.4 (2%)
	Data size (GiB) = 15.2 (89%)
	L2 header size (GiB) = 1.2 (7%)
	Other size (GiB) = 0.2 (1%)
Metadata current size (GiB) = 1.8 (12% of data size)
	Metadata max size observed (GiB) = 2.3 (4% of physical memory)
Target size (GiB) = 32.0
	MRU target size (GiB) = 3.8 (12%)
	MFU target size (GiB) = 28.2 (88%)
	Max target size limit (GiB) = 40.0
	Min target size limit (GiB) = 32.000
ARC Efficiency
	Cache access total = 125,240,037
		Demand data access = 89,434,273 (71% of total accesses)
			Hits = 61,555,082 (69% of demand data accesses)
		Prefetch data access = 12,598 (0% of total accesses)
			Hits = 38 (0% of prefetch data accesses)
		Demand metadata access = 34,488,125 (28% of total accesses)
			Hits = 28,168,305 (82% of demand metadata accesses)
		Prefetch metadata access = 1,305,041 (1% of total accesses)
			Hits = 1,201,018 (92% of prefetch metadata accesses)
	Cache hits = 90,924,443 (73% of total accesses)
	Real hits (MFU + MRU) = 626,411,272 (500% of total accesses)
		MRU data hits = 606,566,383 (97% of real hits)
		MFU data hits = 19,844,889 (3% of real hits)
		MRU ghost hits = 0 (0% of real hits)
		MFU ghost data hits = 0 (0% of real hits)
	ARC eviction analysis
		Total data evicted (GiB) = 6,781
			Eligible for L2 (GiB) = 6,451 (95%)
			Ineligible for L2 (GiB) = 0 (0%)
			Already in L2 (GiB) = 329 (5%)
			Evicted from MRU (GiB) = 6,777 (100% of total data evicted)
			Evicted from MFU (GiB) = 3 (0% of total data evicted)
+ Analysis: status=info: Data evicted from ARC that is eligible for L2 > 50%, consider adding L2
	L2 cache efficiency
		L2 cache access total = 34,198,054
			Hits = 717,790 (2%)
	L2 cache statistics
		L2 header size (GiB) = 1
		L2 feeds = 114,375
		L2 writes sent = 48,274
		L2 writes done = 48,274 (100%)
		L2 write bytes (GiB) = 388.9
		Average L2 feed write size (KiB) = 8,448.4
		L2 read bytes (GiB) = 11.0
		Average L2 hit size (KiB) = 16.0
	L2 error statistics
		L2 abort due to lowmem = 1,705
		L2 write errors = 0
		L2 I/O errors = 0
		L2 bad checksum = 0
		L2 read/write clash = 0

## ZFS prefetcher analysis
Total accesses = 2,315,978,364
	Hits = 2,229,828,092 (96%)
+ Analysis: status=ok: ZFS prefetcher is effective, confidence in analysis is high

 -- richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20161207/4579cdca/attachment-0001.html>


More information about the zfs-discuss mailing list