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>