From owner-freebsd-stable@FreeBSD.ORG Tue Nov 27 20:22:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBBB9137 for ; Tue, 27 Nov 2012 20:22:16 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 45E848FC0C for ; Tue, 27 Nov 2012 20:22:15 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so12299305lah.13 for ; Tue, 27 Nov 2012 12:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UfRVJrfHxt6unY6c9bIW8SyNy3F2tIPM4QxtqteWRe4=; b=blWmG5/FrkIj6Xfmp7nmsumGmDcsJh3TxNn36EirmUGulT9J0Jopz4ZPQt/IfKFAvS NIV/pWBCQ+6Afblxn3LJA9QeV5JOVKkkRI/LHDZz7wST0t1YDuiirCRdjZj2F3Ad2A5C BiTEGQy4Xin84dzXccNeOnfbdhnFoKShjdTsHIJykfrIWE9PEbL9jJyAAE9PrI1QviI/ nCEVhEXXBPA4/qpM3T1Ia0VlTfjFQ9LFvh5OWvtlrFuo5fhyiqjdbtw3lGIvG/kdjwU2 ik1BNVH1qHvMjPDlDiUouu3ue6VsAABSNTg4rLugAV40HXoVGzQbzx8OXhBzZRAuQLG1 OIRg== MIME-Version: 1.0 Received: by 10.152.106.79 with SMTP id gs15mr15932254lab.31.1354047734950; Tue, 27 Nov 2012 12:22:14 -0800 (PST) Received: by 10.114.24.66 with HTTP; Tue, 27 Nov 2012 12:22:14 -0800 (PST) In-Reply-To: <7A88B836-C985-446C-A992-A295A2474A38@gmail.com> References: <7A88B836-C985-446C-A992-A295A2474A38@gmail.com> Date: Tue, 27 Nov 2012 12:22:14 -0800 Message-ID: Subject: Re: ZFS memory management From: Freddie Cash To: Nikolay Denev Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 20:22:16 -0000 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 :) On Tue, Nov 27, 2012 at 12:10 PM, Nikolay Denev 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