Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Dec 1996 22:17:59 -0800 (PST)
From:      Peter Carah <pete@news.interworld.net>
To:        isp@freebsd.org
Subject:   Re: News machine FreeBSD config Question
Message-ID:  <199612050617.WAA16474@news.interworld.net>
In-Reply-To: <199612032229.QAA27483@brasil.moneng.mei.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <199612032229.QAA27483@brasil.moneng.mei.com> jgreco write:
>
>This will be a terse response :-)  Just because I don't have lots of time.
So will mine...
>
>> Hello, I am trying to configure our news machine for optimal performance running
>> FreeBSD 2.1.5R and I have a few config type questions I hope you can help me
>> with...

>
>> 4: Innd doesnt *seem* to be taking advantage of the memory I have in the
>> system... Its only about 18meg right now as reported by ps...
>> news     20373  9.0 13.7 18372 17688  ??  SNs  Sun09AM  250:23.06
>> /usr/local/news/etc/innd -p7 -i0            
>
>It will eat more as time goes on :-)  I have seen innd actively occupying
>160MB of RAM.

Try linking it with gnumalloc.  Works wonders and the growth is greatly
slowed...  Seems to run faster but that may be an illusion.  We are getting
about 1.5g/day from 5 feeds (about half from one of them) and (outbound)
feeding only two (we backfeed all the feeds but of course, most come out
refused, except for the (unnamed :-) one that can't accept or reject news 
nearly fast enough) with one uucp feed and 4-5 nnrp at a time. System is
HX board with P166 and 128mb and seems pretty stable this way.  (and nnrp
may increase a bunch soon).

Another memory leak I've seen is bash running innwatch; it grows to 18mb
after a couple of weeks; you really want to restart innwatch more often
than that.  Haven't (yet) tried bash with gnumalloc, and the default fbsd sh
at least used to core when used to run innwatch.  Then again, all that really
uses up is swap...

We're currently using 4 3g disks (that's what we had :-) with acceptable
performance.  It could be improved but certainly keeps up with the 2 T1's 
and all the readers.

I still have .overview distributed in the spool; is it a win to put it 
on its own partition?  (I'd guess for incoming it would be but not 
for readers; obviously it doesn't matter for feeds...)

-- Pete



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612050617.WAA16474>