Date: Sat, 9 Apr 2011 12:06:41 -0700 From: Artem Belevich <art@freebsd.org> To: Joe Schaefer <joesuf4@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: imposing memory limits in FreeBSD 8 Message-ID: <BANLkTimUbqen3cBVrK_DD_FA8jSKgM8pdA@mail.gmail.com> In-Reply-To: <BANLkTikttrxFR-Xa7TqGXFgipKxavioJWQ@mail.gmail.com> References: <BANLkTikttrxFR-Xa7TqGXFgipKxavioJWQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. =A0I have a few servers that occasiona= lly > 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. =A0About > the only thing I haven't tried is running httpd under djb's softlimit > executable. > Here's my daemon class in login.conf: > > daemon:\ > =A0 =A0 =A0 =A0:memoryuse=3D1g:\ > =A0 =A0 =A0 =A0:datasize=3D1g:\ > =A0 =A0 =A0 =A0:stacksize=3D1g:\ > =A0 =A0 =A0 =A0:tc=3Ddefault: > > 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=3DD. This way datasize limit will still be in effect. --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimUbqen3cBVrK_DD_FA8jSKgM8pdA>