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[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 DBZhash 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. ------------------------------ [Last Changed: $Date: 1997/09/16 01:25:57 $ $Revision: 2.25 $] [Copyright: 1997 Heiko Rupp, portions by Tom Limoncelli, Rich Salz, et al.] |
