From owner-freebsd-stable@FreeBSD.ORG Sun Oct 23 17:07:10 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC8F416A41F for ; Sun, 23 Oct 2005 17:07:10 +0000 (GMT) (envelope-from for.bounces@dun.ukr.net) Received: from dun.ukr.net (dun.ukr.net [212.42.67.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A95F43D49 for ; Sun, 23 Oct 2005 17:07:10 +0000 (GMT) (envelope-from for.bounces@dun.ukr.net) Received: from sharun by dun.ukr.net with local ID 1ETjJN-000Pqm-IA for freebsd-stable@freebsd.org; Sun, 23 Oct 2005 20:07:09 +0300 Date: Sun, 23 Oct 2005 20:07:09 +0300 From: Vladimir Sharun To: freebsd-stable@freebsd.org Message-ID: <20051023170709.GA99337@dun.ukr.net> Mail-Followup-To: Vladimir Sharun , freebsd-stable@freebsd.org References: <20051023074342.GA97095@dun.ukr.net> <20051023080622.GA76867@xor.obsecurity.org> <20051023082110.GA97329@dun.ukr.net> <20051023082948.GA90034@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051023082948.GA90034@xor.obsecurity.org> User-Agent: Mutt/1.5.9i Subject: Re: kmem_malloc(4096): kmem_map too small: 536870912 total allocated 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: Sun, 23 Oct 2005 17:07:10 -0000 Kris Kennaway wrote: > >>> We have 2xOpteron/2Gb RAM server with extrensive disk load. Every week or two > >>> it suddenly hangs with "kmem_malloc(4096): kmem_map too small 335bla-bla allocated". > >>> I look onto handbook and put vm.kmem_size_max="536870912" onto /boot/loader.conf. > >>> Today was the same with the new parameters. Is there any other solutions ? >> > KK>> If that's not enough, try making it larger. >> >> On what size we can be sure, that "that's enough" ? KK> It depends on your workload, so keep increasing it until the problem KK> stops or you discover that you need more RAM to handle your workload. Looks like kernel leak (thanks for tip to Gleb Smirnov) in lockf. # vmstat -zm | grep lock lockf 2257779 70556K - 19476940 32,64 ... and keep raising. That's another one machine with 1Gb RAM, having 512M for vm.kmem_size_max too. -- UKR.NET Postmaster