On Mon, 12 Dec 2005 13:10:19 -0500, Mark Bucciarelli <[EMAIL PROTECTED]> wrote:
>On Mon, Dec 12, 2005 at 09:46:59AM -0800, J. C. Roberts wrote: > >> Please think about what Bob suggested for a moment and then look at your >> reply. -The overhead and resource usage of creating/maintaining a ram >> disk is greater than simply increasing the physmem allocation for >> caching files. > >I did think about it, but maybe incorrectly. > >I figured the kernel would not be smart enough to give a strong >preference to caching the files that are getting written to >(/var/db/spamd) over those files that are getting read a lot >(SpamAssassin and ClamAV). I figured that's why he qualified his >suggestion with spamd being the only running on the box. > >Or are you saying that caching the reads would help with the I/O bottle >neck just as effectively? I would be surprised by that, especially >since it's RAID1. > >m First of all, Bob suggested mucking around with buttons. You will see such suggestions *very* rarely from developers and kernel tweaking is generally discouraged. The defaults are there for a reason and were created/tested by folks who know the system a lot better than you and I combined. If you ever get a suggestion on this list to start twisting knobs and pushing buttons, make sure it's from a credible source and don't be surprised if said credible source decides to send you the suggestion privately off-list. There may be limitations to the approach Bob mentioned such as dependencies on how much physical memory you have in the box. I'm not sure how/if UBC has changed this... -A lot has changed since Feb 2004 but you might find this *old* post enlightening: http://www.monkey.org/openbsd/archive/misc/0402/msg00888.html Either way, Bob's suggestion of increasing bufcachepercent from 10% to 50% is a hypothetical example, so don't take the value as a hard fact since it might even be over-kill for your needs. The only way you'll find out is to run some tests for yourself. Unfortunately, you are the only one on this list that knows your memory and data set sizes as well as other system information, loads and requirements. Even if you provide the details, you'll still need to do your own testing... As you stated, your goal of a RAM Disk is use RAM to reduce Disk I/O on a system that is bound by disk I/O. -This is the reason why caching to RAM was invented. The type of RAID you're running really has nothing to do with it save one exception; if you are truly in need of better performance on a system that is disk I/O bound yet runs RAID1 as you indicated, why not run RAID0 to (help) solve your I/O problem? Are you running RAIDframe or hardware RAID? Any chance of adding a disk and using RAID5? Better/more caching in your RAID controller? Personally, I'd first test/benchmark a base install system. You might be pleasantly surprised by the results and not need to do anything else. Next I'd try the tweak Bob provided and test again, compare the results (I'm betting Bob's right). If it provides marked improvements that satisfy your requirements, try tweaking the value around a bit and run more tests. If I was still outside of my requirements, I'd probably throw more/better hardware at the problem before trying to do something esoteric in software. -Every time I try to get clever, the only thing I manage to prove is that my feet aren't bullet proof. ;-) Kind Regards, JCR
