Be sure to read the "RKT couplings" below for additional information and updates to this entry.
|Subject: (7.33) Help, INND gets real big|
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 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 1Both 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 <firstname.lastname@example.org> 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
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.
[Last Changed: $Date: 1997/09/16 01:25:57 $ $Revision: 2.25 $]
[Copyright: 1997 Heiko Rupp, portions by Tom Limoncelli, Rich Salz, et al.]