Correction: INN STABLE 20011014: Expire takes ages

Ron Jarrell jarrell at solaris.cc.vt.edu
Tue Nov 13 20:34:43 UTC 2001


At 10:58 AM 11/12/01 +0200, you wrote:


>[ I'm sorry. I should have really read what I wrote before hitting C-c
>  C-c... So, please, ignore my previous message the Message-ID of
>  which is <qzulmhczblp.fsf at butler.cc.tut.fi>. ]
>
>Hello,
>
>I wonder what causes the problem when expire runs for ages. At the
>moment it has been running for a little bit over three days and I
>think it'll take at least one day more for it to finish.
> 
>I'm running INN STABLE 20011014 on Sun UE450. Articles are stored on
>CNFS and overview method used is buffindexed. The system has 512 MB of
>memory. The size of the history is over 1 GB (/remember/ is set to 5

I'll bet you ran into the bug I ran into.  For some reason on my system dbz didn't
properly understand how big to generate the history file; even when I explicitly
told it. It was picking the default, which was about 10 times too small, which causes
the performance of expire (and makedbz) to go straight into the toilet.  My expires
were taking about 3 days; I changed one line of code, and now they take about
5 minutes.  (I use cnfs, so, really, all expire is doing is regenerating the index.)

Check your history.dir file; is the 3rd field on the first line significantly smaller than
the size of your history file? In fact is it 750000 (the default value)?  If so, go
to {newssrc}/lib/dbz.c and change DEFSIZE from 750000 to something large
like 20000000.  The next time you regenerate it'll be much faster.

Never did have the time to track down *why* it was ignoring my arguments, or
guessing wrong, but the brute force solution of "if it's going to constantly default,
make the default rational for my site" worked.



More information about the inn-workers mailing list