From owner-freebsd-stable@FreeBSD.ORG Mon May 10 16:03:38 2010 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 56B8A1065782 for ; Mon, 10 May 2010 16:03:38 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 263428FC17 for ; Mon, 10 May 2010 16:03:37 +0000 (UTC) Received: by pxi20 with SMTP id 20so1836764pxi.13 for ; Mon, 10 May 2010 09:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=lZ6fHs4ITlV3hIE6HEUwuRaW9xKFnHLduSmfY2kJGhY=; b=dyKoQDnOgNizPfX+IgMd6sbVL7+KoVo3ezeqPoTSM2CCM3xiZWDS/e+nl/jc63v7z2 y9NuYwJV9MM7pcspA74UOKUb1fWAv7TMpzYJIQBeOj3V4EHZ4CeZ8RowLKo5sWhRYcoO SnCeCqqUqUjj6gGCwrrrX0Qfr9SfBeVDoQhzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EFZCru21jrgWhTNcM5+BBxfSNVuaSkQBHoqwZhw/sc8eqgiuR3pOPs4/r3p7h2fbsu 9TMljUxkUkEXQXG9Ap/iCzz05bLPbw31xAqzVhBzlgBCgCFAMtBDFojUTx+ornmXJ5J2 R0XzM7qIfY78MEGqe+sRn8mGCQymVdex7Qigo= MIME-Version: 1.0 Received: by 10.141.106.21 with SMTP id i21mr2811357rvm.40.1273507417619; Mon, 10 May 2010 09:03:37 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Mon, 10 May 2010 09:03:37 -0700 (PDT) In-Reply-To: <4BE82C5D.1080806@bit0.com> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> Date: Mon, 10 May 2010 09:03:37 -0700 X-Google-Sender-Auth: 445fac100e68265b Message-ID: From: Artem Belevich To: Mike Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:03:38 -0000 > On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. =A0= The > latter was added per earlier suggestions on this list, but appears to be > ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway. Set vm.kmem_size to slightly below 2x the amount of physical memory your kernel *sees* (sysctl hw.physmem) . Chances are that real amount of physical memory available to kernel is slightly below 32G so your tunable is ignored. My guess would be that vm.kmem_size=3D63G would work much better. --Artem On Mon, May 10, 2010 at 8:55 AM, Mike Andrews wrote: > On 5/5/10 11:19 AM, Freddie Cash wrote: >> >> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro >> =A0wrote: >> >>> Giulio Ferro wrote: >>> >>>> Thanks, I'll try these settings. >>>> >>>> I'll keep you posted. >>>> >>> >>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G.= .. >>> I'm really astounded at how unstable zfs is, it's causing me a lot of >>> problem. >>> Why isn't it stated in the handbook that zfs isn't up to production yet= ? >>> >> >> As with everything related to computers, it all depends on your uses. > > Sorry to semi-hijack this, but... =A0I'm also running into frequent "kmem= _map > too small" panics on 8-STABLE, such as: > > panic: kmem_malloc(131072): kmem_map too small: 2023780352 total allocate= d > panic: kmem_malloc(131072): kmem_map too small: 2011525120 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(114688): kmem_map too small: 1849356288 total allocate= d > panic: kmem_malloc(131072): kmem_map too small: 2020409344 total allocate= d > panic: kmem_malloc(536576): kmem_map too small: 2022957056 total allocate= d > > (those are over the course of 3-4 days) > > On this specific system, it has 32 GB physical memory and has > vfs.zfs.arc_max=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. =A0= The > latter was added per earlier suggestions on this list, but appears to be > ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway. > > Unfortunately I have not yet found a way to reliably reproduce the panic = on > demand, so it's hard to iteratively narrow down which date the potentiall= y > offending commit was on. =A0It happened at least twice overnight, where > several memory-intensive jobs run. =A0Backing out to a previous 8-STABLE > kernel from March 28 appears (so far) to have stabilized things, so the > offending code was likely somewhere between then and May 5 or so. =A0I do= have > KDB/DDB and serial console on this box, if there's any more info I can gi= ve > to help troubleshoot other than just a one-month vague date range :) > > This is happening to more than just one system, but I figure it's easier = to > troubleshoot memory settings on the 32 GB i7 server instead of the 2 GB A= tom > one... > _______________________________________________ > 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" >