Date: Tue, 15 Mar 2016 15:16:12 +0100 From: Gary Jennejohn <gljennjohn@gmail.com> To: Fabian Keil <freebsd-listen@fabiankeil.de> Cc: current@freebsd.org Subject: Re: how to recycle Inact memory more aggressively? Message-ID: <20160315151612.6b39604c@ernst.home> In-Reply-To: <20160313164117.0301b79e@fabiankeil.de> References: <20160312093835.727d7197@ernst.home> <20160313164117.0301b79e@fabiankeil.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 13 Mar 2016 16:41:17 +0100 Fabian Keil <freebsd-listen@fabiankeil.de> wrote: > Gary Jennejohn <gljennjohn@gmail.com> wrote: > > > In the course of the last year or so the behavior of the vm system > > has changed in regard to how aggressively Inact memory is recycled. > > > > My box has 8GB of memory. At the moment I'm copying 100s of gigabytes > > from one file system to another one. > > > > Looking at top I observe that there are about 6GB of Inact memory. > > This value hardly changes. Instead of aggressively recycling the > > Inact memory the vm now seems to prefer to swap. > > Are you using ZFS? > No, only UFS, so it's not due to pressure caused by ZFS. > > Last year, can't rmember excatly when, the behavior was totally > > different. The vm very aggessively recycled Inact memory and, > > even when copying 100s of GB of files, the system hardly swapped. > > > > It seems rather strange to me that the vm happily allows gigbytes > > of Inact memory to be present and prefers swapping to recyclincg. > > > > Are there any sysctl's I can set to get the old behavior back? > > I don't think so. > > I'm currently using this patch set to work around the issue: > https://www.fabiankeil.de/sourcecode/electrobsd/vm-limit-inactive-memory-more-aggressively.diff > > Patch 4 adds a couple of sysctls that can be used to let the ZFS > ARC indirectly put pressure on the inactive memory until a given > target is reached. > Thanks, I'll take a closer look at it. -- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160315151612.6b39604c>