Date: Thu, 29 Nov 2012 19:16:54 +0200 From: Nikolay Denev <ndenev@gmail.com> To: Olivier Smedts <olivier@gid0.org> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: ZFS memory management Message-ID: <D0B12906-2E5A-4CD5-B7E3-78EB7CD04A4C@gmail.com> In-Reply-To: <CABzXLYOuVGX1wPuHMq8LAn=d%2BeVsjRDtfLt-2X-D_=ChAztG-w@mail.gmail.com> References: <7A88B836-C985-446C-A992-A295A2474A38@gmail.com> <CAOjFWZ4MsOmOEXuO8pzMKqN3_ykA7i=jkcMYxPT-6xdWVerfsw@mail.gmail.com> <CABzXLYOuVGX1wPuHMq8LAn=d%2BeVsjRDtfLt-2X-D_=ChAztG-w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 29, 2012, at 4:53 PM, Olivier Smedts <olivier@gid0.org> wrote: > 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 >=20 > Or you could have at least a little swap (good practice) to allow ARC > take the time to evict some memory when under pressure. >=20 Yes, this was already suggested off-list, and it seems like a solution. Thanks to all for the input! >>=20 >> :) >>=20 >>=20 >> On Tue, Nov 27, 2012 at 12:10 PM, Nikolay Denev <ndenev@gmail.com> = wrote: >>=20 >>> Hello list, >>>=20 >>> 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=3D0" 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" >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> Cheers, >>> Nikolay >>>=20 >>>=20 >>> _______________________________________________ >>> 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" >>>=20 >>=20 >>=20 >>=20 >> -- >> 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" >=20 >=20 >=20 > --=20 > Olivier Smedts _ > ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org - against HTML email & vCards X > www: http://www.gid0.org - against proprietary attachments / \ >=20 > "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?D0B12906-2E5A-4CD5-B7E3-78EB7CD04A4C>