Date: Tue, 20 Apr 2004 02:06:29 +0400 From: =?koi8-r?Q?=22?=Igor Shmukler=?koi8-r?Q?=22=20?= <shmukler@mail.ru> To: =?koi8-r?Q?=22?=Uwe Doering=?koi8-r?Q?=22=20?= <gemini@geminix.org> Cc: freebsd-performance@freebsd.org Subject: Re[2]: How does disk caching work? Message-ID: <E1BFguL-000EKA-00.shmukler-mail-ru@f16.mail.ru> In-Reply-To: <4083FD8B.3000900@geminix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Sorry, I shouldn't have been lazy and actually looked up the settings.
> > Yes, those are the settings I was reffering to. Someone else had cranked
> > them up so that the machine was maintaining about 1.7G in cache; he said
> > that he'd noticed a reduction in disk IO when he did that. I haven't
> > been able to see any difference in disk IO, though it seems logical that
> > setting cache too high would hurt write caching and actually increase
> > disk IO. It's currently set to whatever the kernel thought best, so I'll
> > just leave it there.
>
> Well, I'm afraid your colleague must have been imagining things. The
> cache queue ('Cache' column in 'top') is just a phase in the laundering
> procedure (VM page recyling) between the inactive queue ('Inact' in
> 'top') and the free queue ('Free' in 'top'). So these variables have
> nothing to do with disk i/o performance.
I am not sure you are correct here. I understand things very differently.
Why it is a fact that number of pages in the cache queue does not affect IO throughput, changing vm setting such as:
vm.stats.vm.v_cache_min, vm.stats.vm.v_cache_max, vm.stats.vm.v_free_target and vm.stats.vm.v_free_min should have an effect on disk IO.
The very reason JD came up with cache pages is to minimize IO traffic. If we require lagrer number of free pages we cause OS remove references at earlier point. This should cause kernel re-read some of the pages that otherwise would be just requeued to active queue.
Having larger cache queue would require VM to start cleaning dirty pages earlier, which results in some additional write traffic as well. However, this is not that bad, because here it is a zero sum game. If pages to become free, they would have to written out regardless of cache queue size, just at a later point. However there is a benefit to a larger cache bucket. The upside is that if machine often experiences burst in memory demand (pretty much any real-world server would), you are able to accamodate changing load without blocking.
IS.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1BFguL-000EKA-00.shmukler-mail-ru>