Date: Fri, 13 May 2022 13:43:11 -0700 From: Pete Wright <pete@nomadlogic.org> To: freebsd-current@freebsd.org Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Message-ID: <ab7ad096-109a-b14a-ea2f-bccbaf78c253@nomadlogic.org> In-Reply-To: <0E44A609-A040-4801-B3FA-E0B410F0C3D3@yahoo.com> References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <a5b2e248-3298-80e3-4bb6-742c8431f064@nomadlogic.org> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <DD98C932-A07F-4097-AE7F-D9CEF0BB6AEE@yahoo.com> <f43d7276-3718-df89-cbf0-5c1ef3d67e77@nomadlogic.org> <f00ccd1f-b6f6-bb00-f0a7-2f760c8953a0@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> <75C02C8C-6A5E-4E19-AC7D-B5DB704E8F16@transactionware.com> <C992DE63-AE7B-47F7-B679-B76D480AC0B1@yahoo.com> <D429A8ED-011A-4E67-9726-C49937861CCD@yahoo.com> <A3D29E7A-62C1-492F-9631-06437C17B264@yahoo.com> <0E44A609-A040-4801-B3FA-E0B410F0C3D3@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On 5/11/22 12:52, Mark Millard wrote:
>
>
> Relative to avoiding hang-ups, so far it seems that
> use of vm.swap_enabled=0 with vm.swap_idle_enabled=0
> makes hang-ups less likely/less frequent/harder to
> produce examples of. But is no guarantee of lack of
> a hang-up. Its does change the cause of the hang-up
> (in that it avoids processes with kernel stacks swapped
> out being involved).
thanks for the above analysis Mark. i am going to test these settings
out now as i'm still seeing the lockup.
this most recent hang-up was using a patch tijl@ asked me to test
(attached to this email), and the default setting of vm.pageout_oom_seq:
12. interestingly enough with the patch applied i observed a smaller
amount of memory used for laundry as well as less swap space used until
right before the crash.
cheers,
-p
--
Pete Wright
pete@nomadlogic.org
@nomadlogicLA
[-- Attachment #2 --]
From f3260a2eb1cdc86f9216b7923d7b09704a37e79d Mon Sep 17 00:00:00 2001
From: Tijl Coosemans <tijl@FreeBSD.org>
Date: Sun, 8 May 2022 12:19:28 +0200
Subject: [PATCH] vm: stop background laundering when no progress
Let vm_pageout_laundry_worker go to sleep when it cannot make
progress (nfreed == 0). This allows other threads to run so they
can hopefully free some memory.
This restores behaviour from before c098768e4dad and 60684862588f
and prevents some OOM kills.
Tested by: Pete Wright <pete@nomadlogic.org>
MFC after: 2 weeks
---
sys/vm/vm_pageout.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
index 36d5f3275800..fbb2cd4128f0 100644
--- a/sys/vm/vm_pageout.c
+++ b/sys/vm/vm_pageout.c
@@ -1061,15 +1061,13 @@ vm_pageout_laundry_worker(void *arg)
* clean pages freed by the page daemon since the last
* background laundering. Thus, as the ratio of dirty to
* clean inactive pages grows, the amount of memory pressure
- * required to trigger laundering decreases. We ensure
- * that the threshold is non-zero after an inactive queue
- * scan, even if that scan failed to free a single clean page.
+ * required to trigger laundering decreases.
*/
trybackground:
nclean = vmd->vmd_free_count +
vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt;
ndirty = vmd->vmd_pagequeues[PQ_LAUNDRY].pq_cnt;
- if (target == 0 && ndirty * isqrt(howmany(nfreed + 1,
+ if (target == 0 && ndirty * isqrt(howmany(nfreed,
vmd->vmd_free_target - vmd->vmd_free_min)) >= nclean) {
target = vmd->vmd_background_launder_target;
}
--
2.35.1
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ab7ad096-109a-b14a-ea2f-bccbaf78c253>