Date: Thu, 01 Feb 2024 18:31:22 +0000 From: Karl Pielorz <kpielorz_lst@tdx.co.uk> To: Mark Millard <marklmi@yahoo.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: ... was killed: a thread waited too long to allocate a page [actually: was killed: failed to reclaim memory problem] Message-ID: <25AE8AA9598F0FDEB97B2C47@[10.12.30.106]> In-Reply-To: <B061D029-892A-48F8-8775-BE2A67D5BF3B@yahoo.com> References: <B061D029-892A-48F8-8775-BE2A67D5BF3B.ref@yahoo.com> <B061D029-892A-48F8-8775-BE2A67D5BF3B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--On 01 February 2024 08:30 -0800 Mark Millard <marklmi@yahoo.com> wrote: > [snip] > > One direction of control is . . . > > What do you have for ( copied from my /boot/loader.conf ): > ># ># Delay when persistent low free RAM leads to ># Out Of Memory killing of processes: > vm.pageout_oom_seq=120 loader.conf is empty - it's a pretty stock / out the box install. > The default is 12 (last I knew, anyway). Yes, default is 12 here. > The 120 figure has allowed me and others to do buildworld, > buildkernel, and poudriere bulk runs on small arm boards > using all cores that otherwise got "failed to reclaim > memory" (to use the modern, improved [not misleading] > message text). Similarly for others that had other kinds > of contexts that got the message. > > (The units for the 120 are not time units: more like a > number of (re)tries to gain at least a target amount of > Free RAM before failure handling starts. The comment > wording is based on a consequence of the assignment.) > > The 120 is not a maximum, just a figure that has proved > useful in various contexts. > > But see the notes below based as well. Thanks for the notes. I think I can reproduce this (but it's painful to do - as is pretty much any production server killing all it's procs) so I'll wait until next run. I've set the vm.pageout_oom_seq=120 if only because it's a runtime option (no reboot). It's been many, many years since I had to do anything with default arc sizing on FreeBSD (thankfully) - something I wouldn't want to really do again for such a 'simple' machine. I've noted the change here - and we'll see how it goes. > That 24G+ of wired meant that only 8GiBytes- were > available everything else. Avoiding that by limiting > the ARC (tuning ZFS) or adjusting how the work load > is spread over time or some combination also looks > appropriate. tbh - 8GiB is probably more than enough for what's running on that machine (very little) - but I take your point. Cheers, -Karl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25AE8AA9598F0FDEB97B2C47>