Date: Mon, 23 May 2005 14:50:04 -0400 From: Sven Willenberger <sven@dmv.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Manipulating disk cache (buf) settings Message-ID: <1116874204.10077.61.camel@lanshark.dmv.com> In-Reply-To: <20050523174415.GI959@funkthat.com> References: <1116860293.10083.43.camel@lanshark.dmv.com> <20050523174415.GI959@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2005-05-23 at 10:44 -0700, John-Mark Gurney wrote: > Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400: > > 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 incorrect... FreeBSD merged the vm and buf systems a while back, > so all of memory is used as a disk cache.. The buf cache is still used > for filesystem meta data (and for pending writes of files, but those buf's > reference the original page, not local storage)... > > Just as an experiment, on a quiet system do: > dd if=/dev/zero of=somefile bs=1m count=2048 > and then read it back in: > dd if=somefile of=/dev/null bs=1m > and watch systat or iostat and see if any of the file is read... You'll > probably see that none of it is... > Yes, confirmed as stated, this is great news then. In essence the PostgreSQL planner can be told that the effective cache size is *much* larger than that calculated by using vfs.hibufspace; should result in some [hopefully] marked performance boosts. btw: > dd if=/dev/zero of=zerofile bs=1m count=2048 2048+0 records in 2048+0 records out 2147483648 bytes transferred in 43.381462 secs (49502335 bytes/sec) > dd if=zerofile of=/dev/null bs=1m 2048+0 records in 2048+0 records out 2147483648 bytes transferred in 5.304807 secs (404818435 bytes/sec) and that was on a 3GB RAM system so the caching scheme works great. Sven
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1116874204.10077.61.camel>