Date: Wed, 13 Dec 2000 22:03:47 +0100 (CET) From: News Accountant <newsuser@free-pr0n.netscum.dk> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Patches available (was Re: Extreme high load with 12/7 4-releng) Message-ID: <200012132103.eBDL3lw45492@crotchety.newsbastards.org> In-Reply-To: <200012131826.eBDIQaX84247@earth.backplane.com> References: <200012120230.SAA32402@pathlink.net> <200012121801.KAA42878@pathlink.net> <200012122138.NAA69074@pathlink.net> <200012122231.eBCMVE353411@earth.backplane.com> <200012130209.eBD290M79194@earth.backplane.com> <200012130621.eBD6LPa80568@earth.backplane.com> <200012131405.eBDE50G03431@crotchety.newsbastards.org> <200012131826.eBDIQaX84247@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ freebsd-stable removed from cc: list just cuz ] > :> sysctl -w vm.debug_pageout_stats=1 > :> This output would be invaluable to me coming from people who still have > :> major performance problems on heavily loaded machines. > : > :Okay, I'm gathering data as we speak, but, would you still want to see > :this data from a news box, if I had *not* been noticing major performance > > Well, sure! Ego-stuffing is what we programmers live for :-) Great, I'll gladly help you to get stuffed. Watch yer mailbox, no good point in cluttering up the list with an hour+ of logs... > What I would be most interested in on your particular system is how > this patchset performs with your madvise() hack removed and comparing > that with your original numbers (prior to when you add the madvise()). I'm going to guess that you mean the mlock() userland hack here. If so you're in luck, as I updated everything to incorporate the latest fixes to the BerkeleyDB overview method, which means that in error, I compiled the binary without the mlock() call. I caught that after a few minutes and restarted things with the binary that does mlock(), so you'll see these two sets of conditions in the logs I'll be sending. Comments are added between the two sets of stats. More details: I had been running with 02.Dec vm kernel-kode; before applying your patch I sup'ed to what was available this morning. Meaning if something broke over the last week, as the mailing list leads me to believe, I missed out on the fun. I've had to increase the size of the two history database files slightly as they were overflowing, so now they are about 135M (updated on disk) and 90M (disk timestamp never changes) in size. I still haven't researched why the larger of the two isn't acting the way I want (its on-disk updates cause noticeable lags in responsiveness, in spite of the mlock() call and other calls succeeding, and the timestamps on this file stabilize on a different transit-only machine, although on a smaller file)... I haven't made any attempts as were suggested to run helper programs to lock both files' data in memory rather than use the mlock() userland hack, yet. Mostly I've just ignored the machine since it went down last weekend. It's presently in the process of catching up since Saturday. When this is complete and it's operating normally, I'll try reverting things to closer to the default INN source k0dez. As a reminder, the changes I've made have been to... * first, enable mmap() MAP_NOSYNC on both database .index/.hash files * secondly, adding madvise() WILL_NEED for the two files, in addition to the program-supplied RANDOM * finally, cheating by enabling userland mlock() for INN only on these. There's pretty heavy disk activity on the overview BerkeleyDB database as well, and if for some reason you want more than the 1+ hour of debug numbers I'll be sending you from startup, until I start messing around with mmap/mlock/madvise options, I'll be happy to send them too. thanks, barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012132103.eBDL3lw45492>