[Bug 262743] Memory leak in security/strongswan's charon daemon when communicating over vici socket.
Date: Wed, 27 Jul 2022 19:31:37 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262743 --- Comment #6 from Mark Millard <firstname.lastname@example.org> --- (In reply to Michał Skalski from comment #5) Use of the likes of vm.pageout_oom_seq=120 should delay any kills for failures to reclaim enough memory to reach FreeBSD's target figure for free RAM. This can get extra time to inspect/investigate evidence about the on-going memory/RAM usage. Note: Using an increased vm.pageout_oom_seq is useful for avoiding failed-to-reclaim kills only for bounded-duration "stays running" activities. This can allow buildworld buildkernel -j4 on Small Board Computers with 4 cores and only 2 GiBytes of RAM, for example, when using the default tends to suffer failed-to-reclaim kills.) Note: In sufficiently modern variants of FreeBSD the messages about kills were improved and no longer always report being out of available swap space as the reason for the kill. The messaging about reclaim failures is an example of the improved messaging. Reclaim failures can happen even with a swap space being configured but little/none of the swap space being put to use. All it takes is one process (or m ore) that stays runnable while keeping nearly all the RAM pages in the active state (so: unable to be reclaimed). Even now, if a FreeBSD is modern enough to have the failed-to-reclaim message, if the message reports "out of swap" as the reason for a kill, the message is somewhat of a misnomer, in that kernel data structures for managing the swap areas ran out of space (internal fragmentation?), not the swap media. Note: My references to "stays running" presume leaving the kernel configured to allow process kernel stacks to be swapped out when a process has not stayed runnable. FreeBSD does not do such swap outs for processes that are runnable at the time. -- You are receiving this mail because: You are the assignee for the bug.