Date: Thu, 29 Nov 2012 15:53:20 +0100 From: Olivier Smedts <olivier@gid0.org> To: Freddie Cash <fjwcash@gmail.com> Cc: Nikolay Denev <ndenev@gmail.com>, "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: ZFS memory management Message-ID: <CABzXLYOuVGX1wPuHMq8LAn=d%2BeVsjRDtfLt-2X-D_=ChAztG-w@mail.gmail.com> In-Reply-To: <CAOjFWZ4MsOmOEXuO8pzMKqN3_ykA7i=jkcMYxPT-6xdWVerfsw@mail.gmail.com> References: <7A88B836-C985-446C-A992-A295A2474A38@gmail.com> <CAOjFWZ4MsOmOEXuO8pzMKqN3_ykA7i=jkcMYxPT-6xdWVerfsw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/11/27 Freddie Cash <fjwcash@gmail.com>: > Read any ZFS tuning manual on the web, including the ones direct from > SUN/Oracle, and they all list: > - if you are running processes that need a lot of memory, then limit the > ARC to allow the apps to have access to that memory Or you could have at least a little swap (good practice) to allow ARC take the time to evict some memory when under pressure. > > :) > > > On Tue, Nov 27, 2012 at 12:10 PM, Nikolay Denev <ndenev@gmail.com> wrote: > >> Hello list, >> >> I have the following question : I have several machines with 196G of RAM >> that are using >> RELENG_9 with ZFS, and are running a very memory intensive java >> applications - ElasticSearch >> The machines are without swap configured and have "vm.swap_enabled=0" in >> /etc/sysctl.conf. >> The ElasticSearch processes are using mlockall(2) to pin down their memory >> (configured at 40G). >> And at this point I thought that there would be no problems, but from time >> to time, when the machine grows it's >> ARC memory and there are some other running processes like nginx with >> passenger and uwsgi the ElasticSearch >> process would get killed by the kernel OOM killer with reason "no swap >> space available" >> >> Of course, I've now tuned down arc_max in /boot/loader.conf, but isn't >> this supposed to work automatically? Like >> ZFS releasing some memory when there is a pressure, instead of the OOM >> killer going postal? (at the moment when >> the process was killed the ZFS ARC was 132G). >> >> I understand that this might be problematic as AFAIK ZFS releases memory >> asynchronously when the arc_reclaim_thread() is run, >> which might take some time to be scheduled and complete. >> >> Cheers, >> Nikolay >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > > > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABzXLYOuVGX1wPuHMq8LAn=d%2BeVsjRDtfLt-2X-D_=ChAztG-w>