From owner-freebsd-amd64@FreeBSD.ORG Mon May 23 15:47:57 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 133CC16A4DC; Mon, 23 May 2005 15:47:57 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF39843D49; Mon, 23 May 2005 15:47:56 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 4A975B87A; Mon, 23 May 2005 11:47:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <1116860293.10083.43.camel@lanshark.dmv.com> References: <1116860293.10083.43.camel@lanshark.dmv.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Mon, 23 May 2005 11:47:55 -0400 To: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.730) Cc: Subject: Re: Manipulating disk cache (buf) settings X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:47:57 -0000 On May 23, 2005, at 10:58 AM, Sven Willenberger wrote: > We are running a PostgreSQL server (8.0.3) on a dual opteron system > with > 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show > values of 215MB and 225771520 (which equals 215MB) respectively. My > understanding from having searched the archives is that this is the > value that is used by the system/kernel in determining how much disk > data to cache. > This is correct, from what I understand. If you take the vfs.hibufspace and divide by the page size for postgres (normally 8192) you get the proper value for the postgres tunable effective_cache_size. However, the value you see is also the max FreeBSD will use without hacking up the kernel sources. I asked about this a while back and got a response on what to hack, but I hate keeping local patches to the core system which often tend to be forgotten on upgrades... But I would also love to see the max cache get bigger, especially with multi-gig servers becoming more common and affordable. This will kill us on benchmark comparisons for large databases for sure. Vivek Khera, Ph.D. +1-301-869-4449 x806