imposing memory limits in FreeBSD 8

[Joe Schaefer]

On Sat, Apr 9, 2011 at 3:17 PM, Joe Schaefer <joesuf4 at gmail.com> wrote:
> On Sat, Apr 9, 2011 at 3:06 PM, Artem Belevich <art at freebsd.org> wrote:
>> On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer <joesuf4 at gmail.com> wrote:
>>> While I am thrilled about the newfound zfs stability that upgrading to 8
>>> has brought, one of the things that seems to have been dropped is
>>> support for process memory limits.  I have a few servers that occasionally
>>> run out of swap due to runaway httpd daemons, and the ulimit -m settings
>>> in the startup scripts we use stopped working upon upgrading from FreeBSD 6.
>>>
>>> I've tried fiddling with the daemon class in login.conf to no avail
>>> either.  About
>>> the only thing I haven't tried is running httpd under djb's softlimit
>>> executable.
>>> Here's my daemon class in login.conf:
>>>
>>> daemon:\
>>>        :memoryuse=1g:\
>>>        :datasize=1g:\
>>>        :stacksize=1g:\
>>>        :tc=default:
>>>
>>> and proof that `limits` groks the config:
>>>
>>> # limits -eHC daemon
>>> ulimit -t unlimited;
>>> ulimit -f unlimited;
>>> ulimit -d 1048576;
>>> ulimit -s 1048576;
>>> ulimit -c unlimited;
>>> ulimit -m 1048576;
>>> ulimit -l unlimited;
>>> ulimit -u unlimited;
>>> ulimit -n unlimited;
>>> ulimit -b unlimited;
>>> ulimit -v unlimited;
>>> ulimit -p unlimited;
>>> ulimit -w unlimited;
>>>
>>> Any tips from admins who have successfully imposed memory constraints in 8.x?
>>
>> If I recall it correctly, in -8 malloc defaults to mmap for memory
>> allocations, so RLIMIT_DATA no longer applies.
>> You have to set RLIMIT_VMEM, but be careful as that would include
>> everything mmapped in even if it does not use much of that. rpc.statd
>> is one example of that -- it mmaps in ~256M but has only ~400K
>> resident set size.
>>
>> Another option would be to make malloc() switch back to  sbrk() with
>> MALLOC_OPTIONS=D. This way datasize limit will still be in effect.
>
> Thanks for the tip.   My concern is with runaway processes that are pushing the
> server into swap, so it's pretty easy to pick them out based on what top reports
> for their SIZE.  I'll try the vmem limit and let you know how that works out.
>

Sweet- if the expected behavior is to send the process a SIGABORT when
it hits the limit,
it's working perfectly.