Date: Sun, 9 Oct 2016 09:13:28 +0200 From: Michael Schuster <michaelsprivate@gmail.com> To: Doug Hardie <doug@mail.sermon-archive.info> Cc: FreeBSD - <freebsd-questions@freebsd.org> Subject: Re: Swap exhaustion Message-ID: <CADqw_gL8hT_P=4-L9w9d9emYbAq=9vt2bEw5Q4G7=%2BuO-P6Q9Q@mail.gmail.com> In-Reply-To: <9DB5B54C-2AE4-4200-AB78-F86913E1E433@mail.sermon-archive.info> References: <1CD13C1C-5344-4909-A061-F25FBB86AFF9@lafn.org> <9DB5B54C-2AE4-4200-AB78-F86913E1E433@mail.sermon-archive.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 9, 2016 at 3:33 AM, Doug Hardie <doug@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'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADqw_gL8hT_P=4-L9w9d9emYbAq=9vt2bEw5Q4G7=%2BuO-P6Q9Q>