🚀 go-pugleaf

In article <1gvld4INNpkt@smurf.smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) wrote:
>In news.software.b, article <1gv12mINNcpm@grasp1.univ-lyon1.fr>,
>  Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel) writes:
>
[ I wrote: ]
>> > c)      does fairly important'' mean that INN will crash and
>> >        burn if it can't malloc  more than 2.5 MB of VM (e.g.)?
>> 
>> Did anyone try with so little ?
>> 
>It will crash and burn but if anybody runs a Usenet site with less than 16 MB
>of swap configured, it's their own fault if things don't work.

In article <1gvethINNje6@meaddata.meaddata.com> dem@meaddata.com (David Myers) wrote:
>   It means your performance will suffer if your system doesn't have
>enough memory.  Right now, the innd on our news machine has been
>running for one week, and is 10 MB in size.  I suppose a crash and
>burn is possible if your machine is really starved for memory.  If you
>have less than 16 MB of RAM, you should probably avoid INN.

swap != VM != RAM.  I'm posting this from an AT&T 3B1, 4MB physical RAM (the
maximum), 8 MB swap space.  Due to a design decision, the per-process VM
limit is 2.5 MB, regardless of how large the swap space is.  It certainly
sounds like INN won't run on a 3B1.

In article <1gvld4INNpkt@smurf.smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) wrote:
> 
>But note that INN keeps everything in memory (this includes the full text of
>every incoming article) and writes out everything in one fell swoop (that's
>what writev() is there for, folks ;-). 

Not every system *has* a writev().

In article <1gv6i6INNjnn@smurf.smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) wrote:
>In news.software.b, article <1992Dec18.135727.4601@sonyd1.Broadcast.Sony.COM>,
>  lilb@sony.compuserve.com (Bruce Lilly) writes:
>> 
>> Does innd have to be running continuously, or can it be run on an
>> as-required basis from inetd (suitable for machines with low
>> volume feeds and only occasional newsreader connections (nntpd
>> can be run from inetd))?
>> 
>When innd is not active, it gets mostly paged out. So there shouldn't be any
>performance degradation when innd is running and doing nothing.

Performance per se isn't the only issue involved. Among other things, the
advantages of running daemons from inetd includes having a smaller number of
processes in the process table (and therefore the possibility of a smaller
kernel).

>On the other hand, innd startup takes a few CPU seconds (grab the history
>file, scan the newsfeeds file, build all the in-core data structures).
>Besides, inetd can't listen on UNIX-domain sockets and innd doesn't have a
>way to pass an open file descriptor in (other than the TCP listener socket,
>which can only be opened as root under most Unixes).

Does INN *need* ``UNIX-domain'' sockets? (some vendor supplied socket
emulation libraries, e.g. Wollongong WIN/3B, do not support
``UNIX-domain'' sockets.)

inetd, running as root, opens the socket and can pass it to a child process
as stdin/stdout.  That's what happens, for example, with nntpd or sendmail -bs
running under inetd.

>> What other underlying assumptions and requirements exist for
>> INN? For example, somebody else claimed that because INN can
>> write to a pipe rather than to a disk file, it's performance can
>> be better than C news'.  That assumes that a pipe is
>> fundamentally different from a disk file, which is certainly not
>> the case for many varieties of the UNIX(R) operating system.
>
>Umm, that depends on what you regard as "fundamentally different".
>Read/write froma pipe usually doesn't hit the disk at all, you don't
>have to scan a directory and open/close a file every time the reader
>catches up with the writer, you can't call select() on a disk file...

And in article <1gvethINNje6@meaddata.meaddata.com> dem@meaddata.com (David Myers) wrote:
>   You must have disks that run at memory speeds.  Or else you have
>pipes that you can lseek() backwards on.  There *is* a fundamental
>difference.  But I don't think that INN's ability to use pipes this
>way is, by itself, reason to choose INN over C News.

From the beginning, the UNIX(R) operating system implemented pipes *via* the
file system (in fact, you could think of a pipe as a FIFO without a name,
although FIFOs were invented after pipes).  (see Bach, p. 111)
That also applies to commercial UNIX, up to at least SVR3.2 (see Stevens,
U.N.P. p. 381).  I suspect that it also applies to pre4.2 versions of BSD.
I don't know about Research versions >7. [ SVR3.2 and later use STREAMS (not
to be confused with streams, Streams, streams, streams, or streams :), and
BSD4.2+ uses UNIX-domain sockets to implement unnamed pipes. Most likely,
the more recent Research versions also use STREAMS. ]

I/O performance-wise, pipes implemented via the file system are likely to
have similar performance to disk files (and indeed they do (the 3B1 runs an
OS resembling SVR2.2)).  The other implementations of pipes do provide
better performance, but it's wrong to assume that pipes will always yield
performance better than disk files, for all systems.

By the way, you *can* call select() on (the file descriptor referencing) a disk
file, but it will always indicate readiness for reading and/or writing (at least
that's the case with the (admittedly buggy) version of select that Wollongong
supplies), so there's not much point in doing so.


Thanks to all who replied to my questions.

-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce