[ 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.
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
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.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message