Q: Innd gets real big over time - is there any way to prevent this?

This comes at least partly from the design goal to get it fast, so it
trades memory vs. I/O.
There are some configuration options and patches which could reduce
this a bit.

If you have lots of stdin nntplinks, you should incorporate the 
innd.spool.pathc which is in unoff[23] already.
Then the value of DBZINCORE also changes the way INND behaves:
        ##  Value of dbzincore(FLAG) call in innd.  Pick 1 or 0.
        #### =()<INND_DBZINCORE         @<INND_DBZINCORE>@>()=
        INND_DBZINCORE          1
  Both innd and nnrpd have the option of keeping the DBZ
  hash table in memory, under the control of the INND_DBZINCORE and
  NNRP_DBZINCORE_DELAY parameters, respectively.
  This can consume lots of RAM proportional to the size of your history
  database, but it can also avoid a great deal of disk I/O.
  You should probably see the DBZ manpage in the doc directory
  for some (brief) additional discussion of this issue. (From Rich Salz)
Matthias Urlichs <urlichs@noris.de> adds:
If you still find that INND grows beyond all bounds, eg. after a week days
it's twice as big than after three days, you may have a problem with your
system malloc.
Many malloc implementations try to coalesce free blocks, and to split big
chunks into smaller ones. It can be shown that no matter what strategy you
use to split and combine blocks, there's an allocation sequence which lets
your used-up space grow without bounds.
To fix this problem, use the malloc that comes with INND. It wastes a bit
more space initially (around 25%, to be exact), but behaves a lot better --
INND allocates more memory pages, but actually needs fewer to do its job. 

Some parts © 2009 Advameg, Inc.