From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <922c6aebbe45b34a9434acad628d6fb6@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] venti/fossil caches ratios? From: "Russ Cox" In-Reply-To: <200303181020.h2IAKgu22912@zamenhof.cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 18 Mar 2003 17:39:28 -0500 Topicbox-Message-UUID: 81a1ef78-eacb-11e9-9e20-41e7f4b1d025 > The wiki nicely suggests a ratio for the venti index/arena size. > Are there similar suggestions for fossil open -c, and venti -B -C -I ? > > (suppose I have a fossil buffer of 1 Gb, 50 Gb of venti arenas, 0.75 Gb > of ram, and I want the machine to be basically a file server, but still > be able to run rio and a few other things without running out of memory, > how do I use the memory I have in the most efficient way?) First decide how much memory you want for interactive use. Suppose this is 256MB. You probably want to set kernelpercent down to something small given how much memory you have. Suppose you set it to 20%. Then that leaves you 614MB. Suppose you keep 102MB for yourself, leaving 512MB for fossil+venti. Now the question is how to partition the 512. If the Venti is used primarily for backing the fossil, then it makes sense to give fossil most of the memory, since fossil does its own caching of Venti reads/writes, and reading even from the Venti cache is noticeably slower than satisfying requests entirely from the fossil cache. I would give 8MB to each of Venti's uses and leave the rest for fossil: venti -B 8M -C 8M -I 8M open -c 62424 62424 is (512-8*3)*1024*1024/8192, assuming you have an 8k block size. It is probably wrong that -c takes a block count instead of bytes like the others. I've been running with the config suggested in the wiki, 8M for each venti guy and also 8M (the default 1000 blocks) for fossil. I have been meaning to switch to some small amount of cache for Venti and more cache for fossil. I think that will help things a bit. venti -B 1M -C 1M -I 1M open -c 3712 seems like a much better use of the 32MB. Russ