Swap exhaustion

[Michael Schuster]

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

> 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...

HTH
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'