Re: wired memory

[Chuck Silvers <chuq%chuq.com@localhost>]

On Tue, Nov 10, 2020 at 02:11:32PM +0000, Patrick Welche wrote:
> On Tue, Nov 10, 2020 at 05:26:26AM -0800, Chuck Silvers wrote:
> > On Tue, Nov 10, 2020 at 11:40:08AM +0000, Patrick Welche wrote:
> > > My 4 Nov -current/amd64 build box seems to be building slowly, with a lot
> > > of "biowait", e.g. watching the RES of a cc1plus slowly crawl up to SIZE
> > > at around 3M per 5s.
> > > 
> > > Is 10G of "Wired" normal? (32G RAM + 64G swap)
> > > (lots of malloc(9) and no free(9)?)
> > 
> > kernel memory usage is not reported as "wired" memory.
> 
> I got that notion from:
> 
> https://www.netbsd.org/docs/internals/en/chap-memory.html#wired_memory

kernel memory is "wired" in the sense that it is not reclaimable
directly by the pagedaemon, but it is not reported as "wired" by top.
perhaps it used to be reported that way (I don't remember), but it's mostly now.
I'm not sure why the zfs pool memory was apparently being reported as "wired",
it looks like we are being inconsistent.


> > > Memory: 3235M Act, 115M Inact, 10G Wired, 75M Exec, 2860M File, 2800M Free
> > > Swap: 64G Total, 11G Used, 53G Free
> > 
> > no, 10GB wired memory out of 32GB total RAM is not a typical situation.
> > could you send me the output of "ps aux" and "vmstat -m" ?
> 
> Thanks - sent off list

I just committed a fix (in the "solaris" module) for the garbage pool names.


> > with 11GB of swap in use, it's not surprising that the system would be
> > very slow.
> 
> Part of the question is why it needs to swap... (where did the 10G go?)

looks like you figured that out.

however, if the 10GB of zfs/solaris kernel memory wasn't being freed up
even though it was no longer needed, then it looks like our memory-pressure
feedback mechanism is not working as well as it should.


> > > it is "just" building...
> > > 
> > > Could kern.maxfiles = 108928 be an issue? (3404 default below)
> > 
> > do you mean that on the system that is slow, kern.maxfiles is 108928?
> > that doesn't seem overly large for 32GB RAM.
> > 
> > I'm not sure what you mean by "3404 default below".
> 
> just that the box below had the default kern.maxfiles=3404 setting, but
> as you say that shouldn't be too large, and without it, one sees complaints
> of insufficient files.

oh, is the default maxfiles 3404 even on the system with a ton of memory?
if so, we ought to change that default to scale with system RAM,
like many other defaults do.

-Chuck