NNRPd "option"?

Richard Michael Todd rmtodd at mailhost.ecn.ou.edu
Thu Jul 15 00:20:46 UTC 1999


In message <ylu2r66bcj.fsf at windlord.stanford.edu>you write:
>The Hermit Hacker <scrappy at hub.org> writes:
>
>> Since upgrading to INN 2.3, my FreeBSD 3.2-STABLE machine hasn't been
>> able to stay up for much more then 24hrs before grinding to a halt.
>> I've been working with Matt Dillon to resolve this, and we've got it
>> narrowed down to INN's 'footprint', with his suggestion being:
>
>>     nnrpd should not be getting that big.  There is an INN configuration
>>     parameter, I forget exactly what it is called... which causes nnrpd to
>>     load the hash table for the history file into memory after a certain
>>     number of message-id lookups.  Find it, turn it off, and recompile -- 
>>     so nnrpd *never* tries to load the hash table into memory.  This may
>>     solve your problem simply by reducing the size of nnrpd's footprint.
>
>> The thing is, I don't know of any parameter that allows, or disallows
>> this, and suspect it might be something from an older one?  Or I'm just
>> blind?  Is this an option we still have in 2.3?
>
>dbz_incore.  If mmap is available and you're not using tagged hash, it
>uses mmap() to load the indices rather than reading them into memory.
>
>I'm not following the dbz code well enough to be sure of when this gets
>set for nnrpd (innd is more straight-forward).

As far as I know, it isn't.   The dbz_incore stuff is set via dbzsetoptions()
these days, and there are no calls to dbzsetoptions() anywhere in nnrpd.
For that matter, with the current overview scheme, nnrpd never uses
history unless you do an explicit fetch-by-messageid (ARTICLE <foo at blah>).
A quick check of fstat on a running nnrpd seems to confirm this, since the
running nnrpd process doesn't have any of the history files open at all. 
/proc/<process-id>/map doesn't show any large history-sized mmaped areas 
either.



More information about the inn-workers mailing list