From owner-freebsd-stable@FreeBSD.ORG Wed Dec 20 04:49:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 5E64B16A5A6 for ; Wed, 20 Dec 2006 04:49:09 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7E7543CA2 for ; Wed, 20 Dec 2006 04:49:08 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from [192.168.1.11] (121-72-71-65.dsl.telstraclear.net [121.72.71.65]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JAK00BH52PSOW20@smtp5.clear.net.nz> for freebsd-stable@freebsd.org; Wed, 20 Dec 2006 17:49:05 +1300 (NZDT) Date: Wed, 20 Dec 2006 17:48:59 +1300 From: Mark Kirkwood In-reply-to: <4588AA98.3030904@mawer.org> To: Antony Mawer Message-id: <4588C0BB.3000507@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <45888C68.10305@paradise.net.nz> <4588AA98.3030904@mawer.org> User-Agent: Thunderbird 1.5.0.8 (X11/20061129) Cc: freebsd-stable@freebsd.org Subject: Re: Cached file read performance with 6.2-PRERELEASE 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: Wed, 20 Dec 2006 04:49:09 -0000 > What does the memory-related stats from "top" show you? Did you have any > other memory intensive applications running at the time? A random > example from one of my systems (1GB RAM): > Thanks, good point - but no - absolutely nothing (machine is freshly booted, and the only thing running is this test). Before: ------ Mem: 4672K Active, 4260K Inact, 20M Wired, 14M Buf, 1974M Free After: ----- Mem: 5124K Active, 681M Inact, 126M Wired, 112M Buf, 1191M Free As I understand it, the pages for the file are cached in Inactive and the 112M Buf is essentially a 'window' to access 'em (probably said that a little wrong... someone who knows better can hopefully correct me) > > > That should give you an idea as to how much RAM is being used for the > buffer/block IO cache ("111M Buf" in the above example, as I understand > it), and the VM disk cache ("36M Cache" in the above example). > > You might also want to look at: > > sysctl vfs. > > and see whether or not there is anything there that may affect it. For > instance, whether there is a maximum size in terms of files that will be > cached...? Someone with more VFS/etc knowledge than I may be able to > better advise you there... > Thanks - I'll look into these. > It might be worthwhile trying with a series of different file size to > determine if there is a point where the caching performance drops... I > just did a few quick tests on a relatively old machine (2x P3-933Mhz, > 1GB RAM)... in this case, /tmp is on a 3ware SATA RAID controller > (8xxx?) running RAID1 on two 160gb SATA disks)... > Well that proved to be interesting: anything much bigger than 100M is pretty flat at 350MB/s... Cached file size read rate (8k blocks) ---------------- --------- 100MB 510MB/s 150MB 350MB/s 200MB 350MB/s 800MB 350MB/s 1.6Gb 350MB/s (Off-topic: a 2.5GB file still gets close to 350MB/s even tho it is - obviously - partially cached, helped no doubt by a fast IO system - 3ware 75xx + 4 disk RAID0, which can do 195MB/s for the uncached sections of the file...). Cheers Mark