Correction: INN STABLE 20011014: Expire takes ages

Joe St Sauver JOE at OREGON.UOREGON.EDU
Tue Nov 13 22:01:30 UTC 2001


>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.

I've found this to be true, absolutely. 

Unfortunately, it doesn't solve the whole expiration problem (at least 
on large INN *reader* boxes) because if you run with CNFS plus tradindexed 
overviews, expireover ends up doing touching too many articles trying to 
see if they're still present in the CNFS spool... 

I'd be interested in hearing what other folks are doing for large article
count spool reader boxes in terms of overview solutions...

Regards,

Joe


More information about the inn-workers mailing list