Re: wired memory
On Tue, Nov 10, 2020 at 02:11:32PM +, 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 +, 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
Re: wired memory
On Tue, Nov 10, 2020 at 05:26:26AM -0800, Chuck Silvers wrote: > On Tue, Nov 10, 2020 at 11:40:08AM +, 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 > > 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 > 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?) > > 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. > > Just looked at another amd64 box for comparison (also building - no swap): > > > > Memory: 15G Act, 3820K Inact, 16M Wired, 44M Exec, 14G File, 135G Free > > Swap: > > this system has a lot more RAM and most of it isn't even used, > so I would expect this system to perform much better than the first one. Yes, but also just 16M of "Wired" memory... Cheers, Patrick
Re: wired memory
On Tue, Nov 10, 2020 at 11:40:08AM +, 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. > 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" ? with 11GB of swap in use, it's not surprising that the system would be very slow. > 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 looked at another amd64 box for comparison (also building - no swap): > > Memory: 15G Act, 3820K Inact, 16M Wired, 44M Exec, 14G File, 135G Free > Swap: this system has a lot more RAM and most of it isn't even used, so I would expect this system to perform much better than the first one. -Chuck
wired memory
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)?) Memory: 3235M Act, 115M Inact, 10G Wired, 75M Exec, 2860M File, 2800M Free Swap: 64G Total, 11G Used, 53G Free it is "just" building... Could kern.maxfiles = 108928 be an issue? (3404 default below) Just looked at another amd64 box for comparison (also building - no swap): Memory: 15G Act, 3820K Inact, 16M Wired, 44M Exec, 14G File, 135G Free Swap: Cheers, Patrick