Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 May 2008 01:43:36 -0700
From:      "Brad Penoff" <penoff@cs.ubc.ca>
To:        freebsd-questions@freebsd.org
Subject:   Re: resident memory limit
Message-ID:  <b89c3c270805210143l2019442am233aeeb8748fc776@mail.gmail.com>
In-Reply-To: <b89c3c270805201439nf8adbd4s954a80bb82c72ba@mail.gmail.com>
References:  <b89c3c270805201320i36955dccv9c643543e1b3c291@mail.gmail.com> <20080520165437.36413c46.wmoran@potentialtech.com> <b89c3c270805201439nf8adbd4s954a80bb82c72ba@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 20, 2008 at 2:39 PM, Brad Penoff <penoff@cs.ubc.ca> wrote:
> On Tue, May 20, 2008 at 1:54 PM, Bill Moran <wmoran@potentialtech.com> wrote:
>> In response to "Brad Penoff" <penoff@cs.ubc.ca>:
>>>
>>> I have an application that runs on Linux or Mac OS X but seems to have
>>> a problem when I run on FreeBSD (6.3 or 7).  The issue is the memory
>>> footprint for the application (osubw_sctpclien below) is quite large;
>>> on Linux it can be as much as 950 MB in resident memory, according to
>>> top.  However, on FreeBSD I start to get ENOMEM always around the time
>>> my resident memory size is about 200 MB.
>>>
>>> I read a few posts and have seen people fixing their problems by
>>> adjusting kern.maxdsiz in /boot/loader.conf and/or by adding a swap
>>> file.  I've tried both and for my application, it still seems to be
>>> limited to 200 MB resident memory regardless of maxdsize and swap file
>>> setting.  I wrote a toy application (malloctest below) that calls
>>> malloc in a while(1) and breaks once it gets ENOMEM (doing another
>>> while(1) so it doesn't exit); this application's memory size in top
>>> always matches the kern.maxdsiz setting, however it has a very low
>>> resident memory number, according to top.
>>
>> Have a look at /etc/login.conf and the associated man pages.
>>

BTW, we've seen the exact behavior on FreeBSD 7 as well (6.3 was
reported here).  We've tried on different hardware as well, and keep
getting haunted by this resident memory limit that we don't know how
to set.

Any idea why, in the data I originally reported, I can allocate
kern.maxdsiz + swap (see SIZE from top output) for malloc(1 MB) in a
while loop, yet the top value for RES is always really low?

How come, in contrast, my application starts to report ENOMEM when
SIZE is 203 MB and RES is 201 MB?  This is why I titled the thread
asking about an unknown (to me ;-) limit for resident memory...

Any other suggestions?

brad

>
> Thanks for the prompt reply.
>
> This system has the default settings for all users set to "unlimited"
> for more or less all login.conf categories.  I've pasted them below.
> My application uses a raw socket so I was running it as root, which
> also uses the default settings.
>
> It mentioned that setting memoryuse is the same as setting both -cur
> and -max ; any ideas why memoryuse is saying it's unlimited even
> though it is not?  I tried explicitly setting -cur to 1000M and it
> still started giving ENOMEM around 200 MB resident memory in top...
>
> brad
>
>
> default:\
>        :passwd_format=md5:\
>        :copyright=/etc/COPYRIGHT:\
>        :welcome=/etc/motd:\
>        :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
>        :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin
> /usr/local/bin /usr/X11R6/bin ~/bin:\
>        :nologin=/var/run/nologin:\
>        :cputime=unlimited:\
>        :datasize=unlimited:\
>        :stacksize=unlimited:\
>        :memorylocked=unlimited:\
>        :memoryuse=unlimited:\
>        :filesize=unlimited:\
>        :coredumpsize=unlimited:\
>        :openfiles=unlimited:\
>        :maxproc=unlimited:\
>        :sbsize=unlimited:\
>        :vmemoryuse=unlimited:\
>        :priority=0:\
>        :ignoretime@:\
>        :umask=022:
>
> root:\
>        :ignorenologin:\
>        :tc=default:
>
>
>
>> --
>> Bill Moran
>> http://www.potentialtech.com
>>
>>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b89c3c270805210143l2019442am233aeeb8748fc776>