Date: Tue, 22 Oct 2024 17:34:14 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page Message-ID: <bug-280846-227-fy7sFUpX9f@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-280846-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846 --- Comment #52 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Henrich Hartzer from comment #50) Were Active, Inact, Laundry, Wired, and Free such that Laundry was huge in each case (and the others were not)? Did the lead up to the failures have Laundry increasing at a notable sustained rate vs. did it more suddenly jump? If you had spare USB media and a USB port, for example, having a swap space that is say, something like 3.6*RAM (so RAM+SWAP == 4.6*RAM) and seeing if the RAM+SWAP use stabilized before running out of RAM+SWAP could be interesting. If it stabilized, you might be able to see how much RAM+SWAP your example-being-tested needs. That can help for future planning. (The 3.6 factor should avoid warnings when the swap is added about potentially being mistuned.) (This USB or analogous test need not be biased for the performance you would like in normal operation.) Now that you get reasonable/useful Active, Inact, Laundry, Wired, and Free figures while monitoring in top, such explorations should now be possible via use of top. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-280846-227-fy7sFUpX9f>