ZFS performance help sought

Fabian Keil freebsd-listen at fabiankeil.de
Fri Jan 22 13:08:25 UTC 2016


Mason Loring Bliss <mason at blisses.org> wrote:

> On Thu, Jan 21, 2016 at 06:55:45PM -0500, Mason Loring Bliss wrote:
> 
> > Here's what I set:
> > 
> > vfs.zfs.arc_max="4096M"
> > vfs.zfs.arc_min="1024M"
> > vfs.zfs.txg.timeout="3"
> > vfs.zfs.write_limit_override="512M"
> > 
> > I'm not seeing any obvious way to verify the write_limit_override setting -
> > it appears not to show up in sysctl output.
> > 
> > I'll wait for the current big transfer to finish and then I'll try it with
> > prefetch disabled too.  
> 
> Disabling prefetch doesn't do a thing here - the system is still painfully
> overloaded, doing something that was simply unproblematic under Linux.
> 
> I'd be grateful for further debugging or tuning tips. Is it possible this has
> nothing to do with ZFS and that I need to play with FreeBSD's scheduling
> somehow?
> 
> Again, FreeBSD 10.2, ZFS tuned at noted above, and with prefetch disabled.
> Eight gigs of RAM, pools less than 1TB. Doing a send/receive between pools on
> different disks is bringing the system to its knees, where the literal same
> hardware under Linux/ZoL doesn't break a sweat.
> 
> What else can I try?

It's conceivable that you are seeing the result of lock contention that
is slowing down arc_get_data_buf(), for details see:
https://www.fabiankeil.de/gehacktes/electrobsd/zfs-arc-tuning/
You could try the referenced DTrace script to check if that's the case.

Even if it's a different issue, you may be able to work around it by
throttling the send/receive throughput with mbuffer or a similar tool.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20160122/61db7d40/attachment.sig>


More information about the freebsd-questions mailing list