Date: Tue, 25 Jan 2000 14:30:52 +0100 (CET) From: Millionaires in Underwear!!!! <kvindeservice@FLUFFY.GETS.AN.ANALPROBE.DK> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: big files, blocking in inode, kern.update, and so on... Message-ID: <Pine.BSF.3.96.1000125140547.51491E-100000@fLuFFy.iNt.tElE.dK> In-Reply-To: <fa.khq322v.1cnaia8@ifi.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Ooops, brane fart, I meant to send this to -stable, for some reason I've been thinking that -current is production code, that's what I get for being away so long and forgetting everything On Tue, 25 Jan 19100, Matthew Dillon wrote: > Hmm. It sounds like the system is doing a huge amount of seeking to > flush the dirty buffers. Your history file may be badly fragmented on > the disk. The first thing I would do is take the system down and copy > the history file to reorder all of its block. i.e. 'cp fubar fubar.bak' > then 'mv fubar.bak fubar'. Assuming you have the space. I don't think that's the problem, for the way I set up both new machines (FreeBSD and Slowaris) in order to get the benefit of the existing huge history file, was to wget the ~1GB text file off the existing machine, then makehistory to build the index/ hash files. Nothing special was done to newfs this particular disk -- I used the standard defaults here. Then I pumped the feed into it (starting with a backlog so that it could refuse several hundred message IDs per second, and then actually get articles at ten or so times normal flow), and watched the results. And after I run `expire' so that the index/hash files are rebuilt, I'm also starting with freshly-built files. So while the amount of seeking being done is probably quite high, I don't think it's due to fragmentation. If anything, I'd guess it's within the hash/index files themselves, but I haven't actually looked closely there. > You may be able to force the system to write more smoothly by reducing > the vfs.hidirtybuffers water mark. I'll look at this, thanks... > There are other possible solutions if you can track down the piece of > code causing the most trouble. I believe that newer versions of INN > use shared R+W mmap()'s which can cause fragmented dirty pages. The > syncer will push these pages out every 30 seconds or so. If this is what > is causing the problem you can solve it under -CURRENT by adding MAP_NOSYNC > to the mmap() call in question (though I don't know which one it is, I > haven't used INN recently). I'll also look at trying -CURRENT (I've allowed myself the possibility of several OSen on the r00t disk just in case the -STABLE that I started with might have problems, as it does), as well as OSen from the Enemy Camp to see how they handle this, once I can free this machine from its present position in production. I'm also curious as to what other people who are running a news swerver, INN 2.x or otherwise, which should have pretty large database files, see. One way to time the `sync' calls is by forcing them with a `time sync' command, although with regular 30 second updates, you need to hit it just before the scheduled sync. The way to figure out just when these happen, assuming your INN is running normally, is to give repeated commands `time ctlinnd mode', which normally should return after about 0.030 secs (give or take a bit), until the actual history disk activity takes place, that for me takes perhaps ten seconds at average article flows. On the other hand, at 115MB for the hash file, and 76MB for the index file, that's some 190MB, much of which needs to be updated at 40Mbit/sec or so... I'll have to eyeball the disks on the Slowaris box now. thanks, barry bouwsma, tele danmark internet or something To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1000125140547.51491E-100000>