dbz/tagged hash stability concerns

Olaf Titz olaf at bigred.inka.de
Tue Mar 13 12:11:07 UTC 2001


I'm currently running INN 2.3.1 (with mode cancel patch but otherwise
vanilla). That is a small server and it has only 32M of RAM, so in the
past I've always used tagged-hash.

Recently I had to rebuild the history, which at that time already had
accumulated quite a few dupes. Unfortunately makehistory has no option
to delete them. I got tons of dupe warnings on the next expire, and on
the next-next expire, and so on. The next makehistory left me with a
bigger history than before (not good). Just for testing, I switched to
non-tagged-hash. The result: Tons of dupe warnings from makehistory,
after a few days everything seems okay now.

Is there any wisdom about the current state of tagged-hash? It looks
rather unstable to me; I had the above kind of problems more than once
everytime I missed a number of nightly expire runs. The docs state
that you should use tagged-hash unless you have tons of RAM, however I
don't have a problem with that by now:

-rw-rw-r--    1 news     news     74072803 Mar 13 12:45 history
-rw-rw-r--    1 news     news           67 Mar 13 12:49 history.dir
-rw-rw-r--    1 news     news      8755830 Mar 13 12:50 history.hash
-rw-rw-r--    1 news     news      5837220 Mar 13 12:45 history.index

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
news     22211  0.1 29.1 21280 9088 ?        SN   Mar09  11:17 /usr/news/bin/innd

Perhaps the docs should be updated to officially deprecate tagged-hash
and remove the tons-of-RAM recommendation for smaller history files.
Is there a rule to calculate the .hash file (which is mmapped) size
wrt. number of articles/history file size?

Olaf


More information about the inn-workers mailing list