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
p...@nomadlogic.org
@nomadlogicLA
