Date: Tue, 20 Mar 2001 09:27:17 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: "Michael C . Wu" <keichii@iteration.net> Cc: dillon@FreeBSD.ORG, grog@FreeBSD.ORG, fs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: tuning a VERY heavily (30.0) loaded server Message-ID: <20010320092717.R29888@fw.wintelcom.net> In-Reply-To: <20010320111144.A51924@peorth.iteration.net>; from keichii@iteration.net on Tue, Mar 20, 2001 at 11:11:44AM -0600 References: <20010320111144.A51924@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Michael C . Wu <keichii@iteration.net> [010320 09:11] wrote: > [Lengthy email, bear with me please, it is quite interesting. > This box averages 30.0 load with no problems.] cool.. > system stats at > http://zoo.ee.ntu.edu.tw/~keichii/ Where's the crashdump/traceback? > Physical memory is 2.5 GB. We do MFS and it croaks/crashes > at midnight, our peak load time. We do md0, it croaks before > peak time. Explain the crash. What is md0/MFS being used for? Why do you need it? > Due to the structure of BBS's, we cannot split the load across > different servers. We also think that we probably cannot > get more performance out of hardware upgrades that we can afford. > (i.e. Please don't tell us to buy a Starfire 4500 :-) We are all volunteer > werkers at El Cheapo university budgets.) Well, getting hardware RAID is always a nice thing and really not too expensive. > We have followed Alfred's advice to do sysctl -w vfs.vmioenable=1 > It allows us to survive the peak load a little longer than before. cool.. > And we are putting our logs of sockstat, iostat 5, vmstat 5, > netstat 5, dmesg, uname -a on the following URL. > > http://zoo.ee.ntu.edu.tw/~keichii/ > > *DRUM ROLL* > What do you think we can do to make this server survive the > peak load of around 5000 users? :) > [snip several non-interesting ideas] > * Anything else we can do? Well first off, telling us which version of FreeBSD this is... Second, provide a crashdump with debug symbols, and show us the backtrace. Third, consider alternatives to MFS since it seems to be a key factor in your stability problems. If you just need a pretty fast /tmp, I would use a softupdates partition as it's probably more effecient than MFS/MD. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010320092717.R29888>