[Bug 262743] Memory leak in security/strongswan's charon daemon when communicating over vici socket.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262743

--- Comment #6 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(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.