dbz/tagged hash stability concerns
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?
More information about the inn-workers