Date: Thu, 28 Sep 1995 01:00:39 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: taob@io.org (Brian Tao) Cc: hackers@freebsd.org Subject: News Server VM & I/O issues (was: Re: Big win for BSD/OS compatibility) Message-ID: <199509280600.BAA05493@brasil.moneng.mei.com> In-Reply-To: <Pine.BSI.3.91.950927164444.289k-100000@trepan.io.org> from "Brian Tao" at Sep 27, 95 04:47:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I've got the 2.0 sources here which I can poke through when I find > some time between rebuilding the news server (with FreeBSD!), getting > a dedicated RADIUS authentication server online, fixing a zillion bad > name server entries and looking for a place to live. :-/ :) FreeBSD works great as a news server (although INN inherently sucks more RAM than I think it really should, but for understandable reasons). Which leads me to an only-somewhat-related topic. Rod Grimes and I were having a small side discussion about news server problems as they relate to disk striping, mirroring, and other similar issues. News servers traditionally suffer somewhat from the design of UNIX file systems - just not optimized to deal with a few million small files ;-) and one of the traditional answers has been to stripe disks, or run multiple spool drives (like I do). While this helps, it still tends to create "filesystem hot spots" with no easy and fast solution. I was hoping to throw a striped disk of some sort at a particular problem I am experiencing. Obviously the _real_ solution is to throw more RAM at the problem, but that's not always possible. :-) With 48MB already in the box, there's no room for more, and I would have to buy 32 to go to 64 :-/ (and this is a non-profit type outfit). Of course this would be a pointless discussion if I could afford to purchase a gigabyte of RAM, but until that happens, it is impossible to cache everything "useful" in memory. Rod made an interesting suggestion: > Start chasing around in the UFS code and see if you can some how create > seperate priorities of importanace for meta data vs file block data in > the VM cache, in your application tossing out meta data is VERY expensive. > A few quick emails to John Dyson or David Greenman might point you to > some tuneable parameters in the system that would help you out. (David and John are invited to jump in any time now...) What, if anything, are other people doing to optimize towards news service? All I am really doing under 2.0.5R is to bump maxusers to 128. Are there other fun things to tweak? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509280600.BAA05493>