Swap exhaustion

Michael Schuster michaelsprivate at gmail.com
Sun Oct 9 07:13:50 UTC 2016

On Sun, Oct 9, 2016 at 3:33 AM, Doug Hardie <doug at mail.sermon-archive.info>

> I have been trying periodically to resolve this issue.  I modified the
> application to log (syslog) every memory location it allocates.
> Interestingly enough they are all around 0x100F380.  However, the segments
> that are increasing in number all have the highest order address bit set,
> i.e., 0x83ac00000.  These are shown by procstat as type "df".  The number
> of these increases with time.  The sizes vary from what appears to be small
> to over 5000 resident pages.  They never seem to go away unless I restart
> the process.  Right after a restart there are 7 "df"s.  However, with time
> there can eventually be hundreds.  Since these do not have any file backing
> them, they eat up swap space and thus cause the system to run out of swap
> and start killing processes.
> What things allocate memory at the top of the address space?  The
> application mallocs and mmaps all allocate much lower in the address space.

Not a direct answer, but a few thoughts:
1) think about disabling memory overcommit (temporarily) (
https://wiki.freebsd.org/SystemTuning). Perhaps this can shed some light on
the culprit.

2) this is something I'd use dtrace to analyse - as a start, I'd watch
everything remotely malloc()-ish (both syscall and libc) and trigger on
return values you're interested in. If that doesn't help, loosen the
restrictions on your tracing until something interesting shows up...

Michael Schuster
recursion, n: see 'recursion'

More information about the freebsd-questions mailing list