Disabling (part of the) timers ?
Christiaan den Besten
chris at prolocation.net
Thu Jun 9 00:11:57 UTC 2005
Sorry for that, meant to reply to the list .....
Just updated to STABLE-20050608, but I am still seeing "Jun 9 02:07:57 spool8 nnrpd: cache6.multikabel.net time 32740 idle
12561(15) readart 101(14) nntpwrite 19867(59)" in my log. So the timers are not diabled are they?
[root at spool8 etc]# grep timer inn.conf
[root at spool8 etc]#
That is what you meant to disable the timers right ?
PS: OS is Linux ia32, Fedora Core 3.
----- Original Message -----
From: "Russ Allbery" <rra at stanford.edu>
To: <inn-workers at isc.org>
Sent: Tuesday, June 07, 2005 8:52 PM
Subject: Re: Disabling (part of the) timers ?
(Please reply to the mailing list rather than to me individually.
Christiaan den Besten <chris at prolocation.net> writes:
> The first time I 'notices' the 'timers' were using more CPU than
> estimated was when Heith patched (as a request) the ovdb_server with the
> same 'timers' to see where it was spending its time. The server could
> barely serve more than 350mbit of feed (towards clients). After removing
> the timers again, we had no problem reaching 450mbit. So I decided to
> remove the timer from nnrpd and decrease the client-timeout check a
> factor (i++; if i>100 (now = time (); check possible timeout value;
> i=0)) etc... This did seem to decrease the CPU load.
> But you think we should have less overhead from all these 'gettimeofday'
> syscalls. nnrpd does a gettimeofday after each read/write sequence by
> default ... With 1000+ nnrpd's running probably makes some sence ?
It really shouldn't make a difference. If it is making a difference,
that's really a problem with your OS, I think, although some OSes
admittedly do have slow system calls. Tons of stuff uses gettimeofday.
That being said, I did incorporate a patch into STABLE and CURRENT that
would let you turn off the timer for nnrpd as well in inn.conf.
> PS: Are the patches for CNFS_BLOCKSIZE integrated into 2.4-STABLE or
> 2.4-CURRENT ? (or both or none ?).
If you're talking about the patch that zero-fills writes to CNFS_BLOCKSIZE
boundaries, it's in both STABLE and CURRENT.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers