Date: Sat, 9 Apr 2011 15:17:10 -0400 From: Joe Schaefer <joesuf4@gmail.com> To: Artem Belevich <art@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: imposing memory limits in FreeBSD 8 Message-ID: <BANLkTinowLi7dyy46hwLB3VCCa5Gpni8MQ@mail.gmail.com> In-Reply-To: <BANLkTimUbqen3cBVrK_DD_FA8jSKgM8pdA@mail.gmail.com> References: <BANLkTikttrxFR-Xa7TqGXFgipKxavioJWQ@mail.gmail.com> <BANLkTimUbqen3cBVrK_DD_FA8jSKgM8pdA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 9, 2011 at 3:06 PM, Artem Belevich <art@freebsd.org> wrote: > On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer <joesuf4@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinowLi7dyy46hwLB3VCCa5Gpni8MQ>