From owner-freebsd-performance@FreeBSD.ORG Mon Apr 19 22:45:37 2004 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0751916A4CE for ; Mon, 19 Apr 2004 22:45:37 -0700 (PDT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCBB543D1F for ; Mon, 19 Apr 2004 22:45:36 -0700 (PDT) (envelope-from gemini@geminix.org) Message-ID: <4084B8FD.9080302@geminix.org> Date: Tue, 20 Apr 2004 07:45:33 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040119 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <20040416163845.GG87362@nasby.net> <20040416221211.GM87362@nasby.net> <4080DF9F.3040302@geminix.org> <20040419022043.GO87362@nasby.net> <408373C0.7080502@geminix.org> <20040419151616.GT87362@nasby.net> <4083FD8B.3000900@geminix.org> <20040419182345.GV87362@nasby.net> In-Reply-To: <20040419182345.GV87362@nasby.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1BFo4d-000Ey8-00; Tue, 20 Apr 2004 07:45:35 +0200 Subject: Re: How does disk caching work? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 05:45:37 -0000 Jim C. Nasby wrote: > Thanks very much for all your help. Only remaining question I have is: > is there something we can monitor to gauge what impact (if any) changes > to these settings have? Will changes to hi|lowrunningspace just result > in increased KB/s or TPS write performance in gstat? How can we tell if > we've advanced it too much? I don't know of any simple means of monitoring the effect, short of doing your own benchmark tests. If these variables are too low you will notice that the write throughput suffers during peak read demand. That's when we started to examine the kernel sources and found the reason. To be on the safe side, don't make 'vfs.hirunningspace' larger than a fraction of the overall disk i/o buffer space (derived from 'kern.nbuf'), and also not larger than the buffer space in the disk controller. 'vfs.lorunningspace' is used to implement a hysteresis and should be 1/2 or 3/4 of 'vfs.hirunningspace'. > Likewise, what can we measure regarding nbuf? If I'm understanding > things correctly, runningspace comes out of nbuf, so obviously it needs > to be greater than that, but what symptoms will we see if it's set too > low? Maybe just bad performance due to the complete flushing of the disk i/o buffers (remember that meta data is cached in there), maybe system lockup. Can't tell. Just make sure that these variables stay smaller than the disk i/o buffer cache, and you won't have to bother with the consequences of overdoing it. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net