Expire takes longer and longer each time.

[Hubbard, Matt]

Hi,

I had set up "INN 2.2.3pre 11-Jul-2000" (CNFS) on a SPARC Ultra1 with
Solaris 7, 128MB RAM and several disks: the buffers are held on a 17GB disk
and the rest of the spool is on a 4GB disk, and the db is on yet another
disk.

We are sent roughly 1 million articles a day, of which we accept 30%.

The system worked fine at the start. But after about a week, the expire
process started taking significantly longer each day - currently it's taking
over 40 hours. The system seems to spend it's whole time in iowait. The
expire process currently is 280MB of only which 90MB is resident.

The system ought to be using the GNU sort, instead of the Solaris one which
appeared not to obey the "use this directory as the temp dir" argument last
time I checked.

Before I upgraded the machine it was running INN 1.something and obviously
used the traditional spool - there were no performance problems, except for
the occasional running out of space in the article spool.

Are we being unrealistic in our expectations of the hardware? If so what
would be a reasonable system?
Would increasing the RAM fix the problem?
Would returning to trad spool or using tagged hash help?
Would changing to INN version 2.3 help?
Are the memory requirements of expire directly proportional to the size of
the history?

Many thanks,

Matt.