Date: Mon, 19 Apr 2004 10:16:16 -0500 From: "Jim C. Nasby" <jim@nasby.net> To: Uwe Doering <gemini@geminix.org> Cc: freebsd-performance@freebsd.org Subject: Re: How does disk caching work? Message-ID: <20040419151616.GT87362@nasby.net> In-Reply-To: <408373C0.7080502@geminix.org> References: <20040416163845.GG87362@nasby.net> <E1BEbKR-000ISM-00.shmukler-mail-ru@f7.mail.ru> <20040416221211.GM87362@nasby.net> <4080DF9F.3040302@geminix.org> <20040419022043.GO87362@nasby.net> <408373C0.7080502@geminix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 19, 2004 at 08:37:52AM +0200, Uwe Doering wrote: > Jim C. Nasby wrote: > >On Sat, Apr 17, 2004 at 09:41:19AM +0200, Uwe Doering wrote: > >[...] > >A few questions if I may... > > > >What's a good way to tune amount of space dedicated to IO buffers? > > You can tune the number of i/o buffers, and therefore indirectly the > amount of memory they may allocate, by using the variable 'kern.nbuf' in > '/boot/loader.conf'. Note that this number gets multiplied by 16384 > (the default filesystem block size) to arrive at the amount of memory it > results in. > > My experience is that with large amounts of RAM this area becomes > unduely big, though. It's not that you have to skimp on RAM in this > enviroment, but the disk i/o buffers eat away at the KVM region (kernel > virtual memory), which happens to be just 1 GB by default and doesn't > grow with the RAM size. So it can be a good idea to actually reduce the > number of disk i/o buffers (compared to its auto-scaled default) on > systems with plenty of RAM (since you don't need that many buffers, > anyway, due to the VM interaction I just described) and save the > available KVM rather for other purposes (kernel resources). Systems > that run out of KVM are prone to kernel panics, given the right > combination of circumstances. Yes, I was thinking the same thing. What I don't know is what would be a good value to use. dirtybuf in systat -v is typically less than 3000, which makes 261,000 buffer seem wasteful, but of course that's neglecting the read caching aspect. > >What impact will vm_min|max_cache have on system performance? Is there > >any advantage to setting it fairly high? > > I'm not quite sure which variables you are referring to. In FreeBSD > there are 'vm.v_cache_min' and 'vm.v_cache_max'. I don't recommend > tuning them, though, without having a very deep and thorough look at the > kernel sources. Many of these variables don't really do what their name > suggests, and there are interdependencies between some of them. You can > lock up your server by tuning them improperly. 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. > >The machine I'm tuning is a dual Opteron box with 4G of ram, a mirror > >and a 6 disk RAID10. It's running PostgreSQL. > > I'm not a PostgreSQL expert, but there have been discussions on this > mailing list and elsewhere about tuning PostgreSQL. I suggest to take a > look at the archives. Yes, I'm familiar with them. The big question that always seems to come up is about how the disk caching actually works, but I think that's been cleared up now. -- Jim C. Nasby, Database Consultant jim@nasby.net Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040419151616.GT87362>