how does history file get too large?
Anne Wilson
anne at unidata.ucar.edu
Wed Jan 28 01:39:51 UTC 2004
Thanks, Mark! I'll try setting the /remember/:n to something smaller. Also, the -c option to innd may be useful.
What I'd like to do is to keep history information as long as I can without getting this error. (That way, if a duplicate shows up after some awful long time, it would still be rejected. Although, the likelihood of that is probably pretty small.)
If there was something that would just check the size of the file and warn me if it's getting too big, then I could deal with it before it becomes a problem. news.daily? expire? Or, maybe that happened and I missed it? Just seems like there should be
a better way to deal with this problem besides the crash and burn approach. (The only error message was "ME source lost . Exiting")
I'm imagining a utility that would scan the timestamps in the history file and get the oldest one. And/or you could give it a timestamp and have it delete anything older than that time.
If I was to write such a script, could I just delete expired entries from the history file, remake the indexes and overview, and have INN run successfully?
I *am* one of the high volume sites - we relay and recieve only scientific data.
Anne
Mark Hittinger wrote:
>
> > One piece of information - about 45% of the entries in the history file
> > were "rejected or expired"
> > ...
> > Thanks much for any ideas.
>
> Sounds like spam and the cancels for that spam are being remembered too long.
>
> Look in your expire.ctl file. The /remember/:n value may be too large.
>
> You can also do something like:
>
> control:A:0:1:1
> control.*:A:0:1:1
>
> To get rid of control message history quicker.
>
> *.jobs:A:0:1:1
> *.jobs.*:A:0:1:1
>
> used to also be a good trick but I don't think these groups are quite the
> problem they once were. :-) :-(
>
> There are some other "high volume" groups like news.lists.filters and the
> alt.sex series where you might want to reduce the retention of history.
>
> Basically if the article has expired anyway (because of high volume and
> small cycbuffs) then it doesn't make too much sense to keep the history
> for it. If you look at the -c startup argument for innd you can reject
> articles that are older than a certain date and not have to keep lots
> of history.
>
> With a few of these changes you should be able to get the history file
> size reduced.
>
> Another side benefit of a reduced history file size is that things are
> faster.
>
> Later
>
> Mark Hittinger
> bugs at pu.net
--
***************************************************
Anne Wilson UCAR Unidata Program
anne at unidata.ucar.edu P.O. Box 3000
Boulder, CO 80307
----------------------------------------------------
Unidata WWW server http://my.unidata.ucar.edu/
****************************************************
More information about the inn-workers
mailing list