Date: Sat, 4 Aug 2018 15:47:57 -0400 From: Mark Johnston <markj@freebsd.org> To: Mark Martinec <Mark.Martinec+freebsd@ijs.si> Cc: stable@freebsd.org Subject: Re: All the memory eaten away by ZFS 'solaris' malloc - on 11.1-R amd64 Message-ID: <20180804194757.GD12146@raichu> In-Reply-To: <87f6a55cc2ee3d754ddb89475bbfbab8@ijs.si> References: <1a039af7758679ba1085934b4fb81b57@ijs.si> <3e56e4de076111c04c2595068ba71eec@ijs.si> <20180731220948.GA97237@raichu> <2ec91ebeaba54fda5e9437f868d4d590@ijs.si> <b3aa2bbe947914f8933b24cf0d0b15f0@ijs.si> <20180804170154.GA12146@raichu> <87f6a55cc2ee3d754ddb89475bbfbab8@ijs.si>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 04, 2018 at 08:38:04PM +0200, Mark Martinec wrote:
> 2018-08-04 19:01, Mark Johnston wrote:
> > I think running "zpool list" is adding a lot of noise to the output.
> > Could you retry without doing that?
>
> No, like I said previously, the "zpool list" (with one defunct
> zfs pool) *is* the sole culprit of the zfs memory leak.
> With each invocation of "zpool list" the "solaris" malloc
> jumps up by the same amount, and never ever drops. Without
> running it (like repeatedly under 'telegraf' monitoring
> of zfs), the machine runs normally and never runs out of
> memory, the "solaris" malloc count no longer grows steadily.
Sorry, I missed that message. Given that information, it would be
useful to see the output of the following script instead:
# dtrace -c "zpool list -Hp" -x temporal=off -n '
dtmalloc::solaris:malloc
/pid == $target/{@allocs[stack(), args[3]] = count()}
dtmalloc::solaris:free
/pid == $target/{@frees[stack(), args[3]] = count();}'
This will record all allocations and frees from a single instance of
"zpool list".
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180804194757.GD12146>