INN not keeping up with incoming news

bill davidsen davidsen at
Thu Feb 22 16:50:30 UTC 2001

In article <72snlt4hun.fsf at>,
Alex Kiernan  <alexk at> wrote:

| What I thinks happening is that (at least on Solaris) is that the IO
| load is causing the mmaped history file to be paged out, causing IO
| wait when the mem* routines happen in the dbz code. I've hacked a
| server here so that it locks the history.{hash,index} files in core to
| demonstrate this...
| Before:
| history lookup 11:54:37.225 49.8% 16618668 0.006 2.580 8.002 
| history write 04:36:32.542 19.3% 995949 7.404 16.660 33.993 
| After:
| history lookup 00:02:03.073 0.1% 20674300 0.003 0.006 0.403 
| history write 00:07:40.148 0.5% 1206923 0.174 0.381 12.178 

  I have the slow hiswrite, but mlock doesn't see to help. I tried
locking the hash, the index, even the active. All no significant help. I
even contemplated but didn't try mlocking the history cache by making it
shm or mmap to a small file.

  About all I got out of it was some practive writing little daemons to
lock file in memory...

| Chucking memory at the problem probably works because the break point
| moves far enough out that the kernel doesn't do completely the wrong
| thing.

  Tried that, to date I haven't really helped. I added memory until it
stopped helping, about 2GB. I added 2GB more just to see what happened,
and the main result was more free memory.

| I'm going to clean up my mlock() code so that inndstart spawns a
| helper process which innd can use to lock the history files into
| memory.

  This is a good thing, maybe (hopefully) I'm still doing something
wrong. This has been known to happen when I have to do stuff late at
bill davidsen <davidsen at>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

More information about the inn-workers mailing list