Date: Wed, 21 Aug 96 11:34 PDT From: pete@pelican.altadena.net (Pete Carah) To: C.R.Harding@massey.ac.nz Cc: isp@freebsd.org Subject: Re: INN Message-ID: <m0utI6d-0000RwC@pelican.altadena.net> In-Reply-To: <199608152213.PAA28830@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199608152213.PAA28830@freefall.freebsd.org> you write:
>At 12:43 PM 8/15/96, Jason Wilson wrote:
>>It starts at around 2MB, goes upto about 8MB within an hour or so, then
>>sits at around 11MB thereafter. I haven't really put it to any use other
>>than one incoming feed (ie. there's no nnrp clients yet) due to the
>>performance problems. As for swap though it sits quite low. The ram
>>will go from (24MB current) to 64MB after this issue is resolved. The
>>only time I see any real performance is in the first minute before any
>>incoming feeds start.
>Sorry, I think I'm stumped now. I've never encountered anything like this in
>INN, the swap thing was the one idea I had. From what you say above, do you
>mean that INN's performance gradually slows down over that 15-30minutes, or
>does it stop suddenly? What do the ends of your news log files say when it
>stops? Are any other networking subsystems on your server affected?
That last question is probably the key. Did you remember the rather
important overrides in the kernel config
maxusers 200 (AT LEAST 128 for any news server)
options "NMBCLUSTERS=4096"
You also need child_max and open_max overrides if you expect to have many
readers (see "LINT" for details). I have 200 on each.
Actually I'd like to see DG's sizing for ftp.cdrom... *that* should handle
any load any isp could throw at a non-smp machine.
Lacking that nmbcluster override can easily cause symptoms like you see.
It should, however, influence other TCP speeds besides news. See
"netstat -m"
For example (this is my home machine on a full-time 28k link)
pelican:10% netstat -m
81 mbufs in use:
14 mbufs allocated to data
5 mbufs allocated to packet headers
45 mbufs allocated to protocol control blocks
17 mbufs allocated to socket names and addresses
1/146 mbuf clusters in use
302 Kbytes allocated to network (4% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
The 146 is a high-water mark, NOT the sysgen max. DG can elaborate
on what this actually means; I'm not really sure, as long as those denied
and delayed lines are both 0 all should be OK.
My *home* innd (unoff3 right now; to be upgraded) is:
news 195 9.0 11.0 9960 3388 ?? DNs 10Aug96 355:28.50 /usr/lib/newsbin/innd/innd -p4 -r -i0
or 39 megs virt 15 real. That is for a fairly small feed (no alt.bin at all,
and the only big-8 group that I get all of is 'news.*'. :-)
Note that innd has been up since the last boot which was only needed because
of a power failure ("THE" power failure); it took down santa clara nap and cix
and fix-west, and all the other western interchange points too :-(.
Normally I boot about once/month unless my daughter gets to the red button.
I also run two "full-feed" machines, both P120s with 4x3g 5400RPM Micropolis
SCSI drives (one drive is alt.binaries only; that now allows an expire
of 2.5 days for that drive. Alt.binaries has gone crazy lately :-).
Those say:
news 207 1.8 25.6 20820 7908 ?? DNs Tue05AM 40:16.86 /usr/lib/newsbin/innd/innd -p4 -r -i0
and
news 221 11.2 26.7 19240 17020 ?? SNs Mon08AM 235:45.45 /usr/lib/newsbin/innd/innd -p4 -r -i0
These are also both unoff3. Both of them were started during boots; I
don't know the reason for either boot. Note that virt is around 80mb
for both. Interestingly the one with expire running is the one with
the smaller "real" size (and it has a somewhat bigger feed, too).
However, the "real" may not be comparable since the smaller one is
running on a 2.0.5 system and the other has been upgraded to 2.1.5;
sometimes ps gets tinkered with.
The biggest change that matters (streaming) was introduced in unoff3.
That makes the 28k feed actually work :-) A couple of the unoff4 changes
look useful; I'm going to upgrade all of these servers over the next week
or two.
The netstat -m from them is:
147 mbufs in use:
109 mbufs allocated to data
9 mbufs allocated to packet headers
24 mbufs allocated to protocol control blocks
5 mbufs allocated to socket names and addresses
106/254 mbuf clusters in use
526 Kbytes allocated to network (43% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
and
103 mbufs in use:
30 mbufs allocated to data
9 mbufs allocated to packet headers
50 mbufs allocated to protocol control blocks
14 mbufs allocated to socket names and addresses
28/126 mbuf clusters in use
264 Kbytes allocated to network (26% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
in the same order.
Both of these two systems often last a month or more.
>From these numbers it would seem that 4096 is way high, but DG has
recommended that number in the past to anyone with a news server who
has performance problems. I don't really know how it relates to the
netstat -m output (i.e. if the 254 is limited at 4096 or if there is
some other relationship there.)
-- Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0utI6d-0000RwC>