INN not keeping up with incoming news

[Fabien Tassin]

According to bill davidsen:
> 
> In article <20010202185655.A7590 at opentransit.net> fta at sofaraway.org wrote:
> | 
> | According to Alex Kiernan:
> 
> | > My suspicion is the history performance problem is platform dependent
> | > - what platforms are people running on (we're using Solaris 2.6/8 and
> | > seeing it)?
> | 
> | I'm using Linux 2.4.1 and I'm seeing it.
> 
>   I've seen a bit of light on this, the systems I'm using have RAID
> controllers with small stripe sizes. My Linux systems with software RAID
> and 256k stripe work better. However, since I am forced to use only 2GB
> cycbuffs until the issues of getting INN to compile again in a modern
> Linux have been addressed, I changed to SEQUENTIAL for the metacycbuff.
> Just took it down, changed and restarted. Played hell with the data org
> no doubt, but after a few hours performance picked up, and has been
> better for two days now.

I'm using hardware RAID under Linux 2.4.1 with 6 * 50GB cycbuffs
(10 * 36GB disks in a RAID0 array) and history files are in a 9GB RAID1 array.
I changed to SEQUENTIAL with limited to no success at all.

INTERLEAVE    article write 14.5% - history write 13.7%
SEQUENTIAL    article write 12.1% - history write 12.6%

(cnfsstat behaves strangely with SEQUENTIAL).

>   Interestingly, the hiswrite is large, but it went down more than the
> artwrite. Don't understand that one. Still tuning, I want to make the
> initial article buffer size larger, and see if that helps. My first try
> broke something, so I have to look at the code a bit more carefully. I
> have less than 200 streams, so a MB/stream is not an issue for memory,
> as I usually have at least a GB free (4GB machine).

I have far less memory on that server (around 1.5 GB) but most of the time,
only a third is in use. 

-- 
Fabien Tassin -+- fta at sofaraway.org