performance loss with inn 2.5.x (tradspool) ?

[Matija Nalis]

On Mon, Feb 13, 2012 at 01:41:25PM +0100, Julien ÉLIE wrote:
> Hi Matija,
> 
> >I've recently upgraded (xref master) news machine from Debian
> >Lenny with INN 2.4.6-snapshot-20090119 to Debian Squeeze with
> >INN 2.5.2-2~squeeze1
> >
> >I've done it before with xrefslave INN server (tradspool with
> >tradindex) on similar hardware, and it didn't have any performance
> >issues.
> >
> >However, now I've upgraded xref master server (tradspool, no readers
> >and no overview indexes, with about 45 realtime peers) and I'm seeing
> >severe performance degradation (loadavg went from 2 to 6!), which
> >started to create problems (server does not responded to nagios
> >connection probes to port 119, etc)
> 
> I do not know what could generate such a difference.

For the record: it seems to be the kernel, as going back to the one from
lenny restored most of the performance back.

But as that server was old anyway, and running old kernel was not a
long-term option, it got upgraded to new shiny server with 4 disks 
in RAID10 and working BBU RAID controller which made it fly!

> As far as I understand, the problem is related with "peering"-like
> functions.
> INN 2.5.x has a new parser for NNTP commands but I doubt it would
> cause a very huger load for innd.
> 
> The Perl and Python filters for innd also check the message-ID of
> articles arriving through TAKETHIS.  (Before, it was only for IHAVE
> and CHECK.)
> 
> Do you use wanttrash, logtrash, keyword generation?  These functions
> have changed.
> 
> Did you have a look at River's suggestion?

Yes, I did, although I'm somewhat slow to answer :)

The Debian upgrade didn't change ext3 to ext4 (they never do such things,
really).  New kernel might've enabled write barriers though; but trying to
explicitely disable them with remount,barrier=0 did not help (it would
not risk data corruption in our case BTW, because we were running with HW
RAID controller which is either battery-backed, or when battery dies [as it
did in our case year ago] it disables the write cache on itself
automatically: dropping the speed but preserving integrity even when OS
doesn't do barriers, as all writes get serialized and acknowledged only when
data hit the plates)

And on that feeder machine we've not been running NNRP for readers, so no
need for tradindexed over tradspool (updating overviews would only slow us
down additionally)...  As for CNFS, we've had few catastrophic CNFS failures
in the ages past and I don't like it anyway (I love ability to directly
access spool with homemade tools [everything from 'grep -r' to more
sophisticated perl crawlers], and tradspool expire flexibility)

-- 
Opinions above are GNU-copylefted.