Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 04 Nov 2014 18:13:44 +0000
From:      Steven Hartland <killing@multiplay.co.uk>
To:        Allan Jude <allanjude@freebsd.org>, freebsd-current@freebsd.org,  gibbs@freebsd.org, George Kola <george.kola@voxer.com>
Subject:   Re: r273165. ZFS ARC: possible memory leak to Inact
Message-ID:  <54591758.7000909@multiplay.co.uk>
In-Reply-To: <54590B55.3040206@freebsd.org>
References:  <1415098949.596412362.8vxee7kf@frv41.fwdcdn.com> <5458CCB6.7020602@multiplay.co.uk> <1415107358607-5962421.post@n5.nabble.com> <54590B55.3040206@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 04/11/2014 17:22, Allan Jude wrote:
> snip...
> Justin Gibbs and I were helping George from Voxer look at the same issue
> they are having. They had ~169GB in inact, and only ~60GB being used for
> ARC.
>
> Are there any further debugging steps we can recommend to him to help
> investigate this?
The various scripts attached to the ZS ARC behavior problem and fix PR 
will help provide detail this.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594

I've seen it here where there's been bursts of ZFS I/O specifically 
write bursts.

What happens is that ZFS will consume large amounts of space in various 
UMA zones to accommodate these bursts.

The VM only triggers UMA reclaim when it sees pressure, however if the 
main memory consumer is ZFS ARC its possible that the require pressure 
will not be applied because when allocating ARC ZFS takes into account 
free memory.

The result is it will back off its memory requirements before the 
reclaim is triggered leaving all the space allocated but not used.

I was playing around with a patch, on that bug report, which added clear 
down of UMA within ZFS ARC to avoid just this behavior, but its very 
much me playing for testing the theory only.

 From what I've seen UMA needs something like the coloring which can be 
used to trigger clear down over time to prevent UMA zones sitting their 
eating large amounts of memory like they currently do.

     Regards
     Steve



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54591758.7000909>