Disk I/O limited: C News or INN?

Thread View: news.software.b

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by John Schmitz Mon, 25 Jan 1993 17:06

#5035

Author: John Schmitz
Date: Mon, 25 Jan 1993 17:06

12 lines
1165 bytes

I have a system running the performance release of C News.
Everything is fine except for the fact that it gets quite a bit
behind in processing news relative to other systems I'm aware of (a
couple hours on similar cpu's).  A quick look at the system shows it
to be limited by disk I/O, not CPU.  The question:  is there any
reason to expect INN to be better in this case?  Presumably both C
News and INN have to shove the same bits around.  Or maybe INN will
be better since the data won't first get written to in.coming and
then re-written to the news spool?  The site in question gets a
nearly full feed via NNTP and uses the reference nntpd.
/usr/spool/news is on one disk (including in.coming) and
/usr/local/lib/news is on another.  Comments?

Re: Disk I/O limited: C News or INN?

#5037

Author: Rich Salz
Date: Mon, 25 Jan 1993 19:20

15 lines
1169 bytes

In <1k16lsINNm5q@hpsceo.scd.hp.com> schmitz@scd.hp.com (John Schmitz) writes:
>[my system seem]
>to be limited by disk I/O, not CPU.  The question:  is there any
>reason to expect INN to be better in this case?
You might expect INN to be better cause it doesn't have to create batches
in in.coming.  Many bright people (e.g., folks at LBL) found this, alone,
to be a significant performance win.  The C News folks have announced that
they will be providing a transfer NNTP.  It will probably be better then
the reference implementation, but I don't see how they can win over the
extra file copy.

On the other hand, knowing Henry, Geoff and their "unindicted
co-conspirators, there is probably some common version 7 Unix facility
that makes it all work quickly and cleanly. :-")
	/r$

Re: Disk I/O limited: C News or INN?

#5038

Author: Joseph Malcolm
Date: Mon, 25 Jan 1993 21:16

28 lines
1844 bytes

In article <1k16lsINNm5q@hpsceo.scd.hp.com> schmitz@scd.hp.com (John Schmitz) writes:
>I have a system running the performance release of C News.
>Everything is fine except for the fact that it gets quite a bit
>behind in processing news relative to other systems I'm aware of (a
>couple hours on similar cpu's).  A quick look at the system shows it
>to be limited by disk I/O, not CPU.  The question:  is there any
>reason to expect INN to be better in this case?  Presumably both C
>News and INN have to shove the same bits around.  Or maybe INN will
>be better since the data won't first get written to in.coming and
>then re-written to the news spool?

This will probably help significantly, especially if you get far
behind. (If you are significantly behind, the batches will probably
not be still cached when relaynews gets around to processing them.)

It is also true that with INN you can't build up a big queue of
unprocessed stuff on disk. (Well, with nntp, anyway.)

>The site in question gets a nearly full feed via NNTP and uses the
>reference nntpd.  /usr/spool/news is on one disk (including in.coming)
>and /usr/local/lib/news is on another.  Comments?

Sticking in.coming on a different disk than /usr/spool/news would
probably help more than does the same for newslib.

-- 
Joseph Malcolm				jmalcolm@sura.net		
SURAnet Operations			+1 301 982 4600

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads