From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <753b3c2c5060c2ef38f39dbcd6c788d0@proxima.alt.za> To: 9fans@9fans.net Date: Tue, 3 Feb 2009 20:37:16 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] Fossil/venti performance (Was: Sources Gone?) Topicbox-Message-UUID: 94e4868c-ead4-11e9-9d60-3106f5b1d025 > i would imagine that cpu has nothing to do with it and encryption > would add no overhead at all. i would image that seeks dominate > your performance numbers. Well, there are numerous issues. The machine is a CPU server booting off another fossil/venti host; it has its own rather pristine, mostly unused Plan 9 distribution and a few other fossil partitions of which only one is backed by venti. I am hesitantly initialising the dump partition because I'm not convinced I have the efficient direcory hierarchy I want to live with. I can't easily check before fossil is active, but venti takes a long time to start and by the time the machine is "ready", memory is full and half of swap is in use :-( During "snap -a" load, context switching and interrupts tend to swing wildly and swap is often being accessed (it's on IDE and the drive light can only mean swap access, I do have DMA active :-) So I would not use this particular configuration to win any competitions. In passing, the first time I did this, I powered the machine down a few times because I was convinced it had stalled. That might have been pessimism on my part, because now that I am monitoring it (stats), it is clear that it occasionally shows no sign of disk activity (no seek, load in astronomical places) for long periods, only to proceed again later. But I do turn all snaptimes to none, which I superstitiously did the first time and seemed to make a difference (I bet it didn't, but if anyone suspects that a dump should finish before another starts, I have the equipment to test the theory. ++L