Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 May 2015 22:09:10 -0700
From:      Doug Hardie <bc979@lafn.org>
To:        kpneal@pobox.com
Cc:        FreeBSD - <freebsd-questions@freebsd.org>
Subject:   Re: Swap exhaustion
Message-ID:  <6F843A4D-8D2D-4DE2-B90E-A8033BEC1500@lafn.org>
In-Reply-To: <20150528000655.GA15385@neutralgood.org>
References:  <1CD13C1C-5344-4909-A061-F25FBB86AFF9@lafn.org> <20150528000655.GA15385@neutralgood.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> On 27 May 2015, at 17:06, kpneal@pobox.com wrote:
>=20
> On Wed, May 27, 2015 at 04:49:52PM -0700, Doug Hardie wrote:
>> I have a process that is eating up 6 GB of swap space.  At that =
point, FreeBSD 9.3 terminates a process.  However, occasionally its not =
the one eating up the space.  When I manually quit the process then the =
swap space returns to a few KB used.  The system runs fine after that.
>>=20
>> I have very little knowledge of what this process is doing internally =
but would like to know what might be causing this issue.  There are 5 of =
these processes running (parent plus 4 children).  Normally each uses =
about 90 MB RES/SIZE.  However when the problem occurs they are about =
2GB RES/SIZE each.  The system has 4 GB memory.  I thought that a malloc =
would not be able to grab that much memory, even with swapping as it has =
to be in memory.  Could a malloc cause this growth in process size or =
need I look elsewhere?
>=20
> There's a difference between "real" memory and "virtual" memory. The
> malloc() call allocates _virtual_ memory. So the maximum amount that =
can be
> malloc'd and used would be the size of your real memory plus the size =
of
> your swap space.

If I am understanding correctly, then it appears that a process can =
actually allocate enough memory to eat up the swap space.  Then I need =
to find out why that process is allocating so much memory.  Thanks.






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6F843A4D-8D2D-4DE2-B90E-A8033BEC1500>