Re: Chasing OOM Issues - good sysctl metrics to use?

From: Pete Wright <pete_at_nomadlogic.org>
Date: Fri, 29 Apr 2022 18:08:22 UTC

On 4/23/22 19:20, Pete Wright wrote:
>
>> The developers handbook has a section debugging deadlocks that he
>> referenced in a response to another report (on freebsd-hackers).
>>
>> https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-deadlocks 
>>
>
> d'oh - thanks for the correction!
>
> -pete
>
>

hello, i just wanted to provide an update on this issue.  so the good 
news is that by removing the file backed swap the deadlocks have indeed 
gone away!  thanks for sorting me out on that front Mark!

i still am seeing a memory leak with either firefox or chrome (maybe 
both where they create a voltron of memory leaks?).  this morning 
firefox and chrome had been killed when i first logged in. fortunately 
the system has remained responsive for several hours which was not the 
case previously.

when looking at my metrics i see vm.domain.0.stats.inactive take a nose 
dive from around 9GB to 0 over the course of 1min.  the timing seems to 
align with around the time when firefox crashed, and is proceeded by a 
large spike in vm.domain.0.stats.active from ~1GB to 7GB 40mins before 
the apps crashed.  after the binaries were killed memory metrics seem to 
have recovered (laundry size grew, and inactive size grew by several 
gigs for example).


maybe i'll have to gather data and post it online for anyone who would 
be interested in seeing this in graph form.  although, frankly i feel 
like it's a browser problem which i can work around by running them in 
jails with resource limits in place via rctl.

-pete

-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA