From owner-freebsd-questions@FreeBSD.ORG Wed Jan 21 06:21:11 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAA6816A4CE for ; Wed, 21 Jan 2004 06:21:11 -0800 (PST) Received: from gs166.sp.cs.cmu.edu (GS166.SP.CS.CMU.EDU [128.2.205.169]) by mx1.FreeBSD.org (Postfix) with SMTP id A912A43D1F for ; Wed, 21 Jan 2004 06:21:09 -0800 (PST) (envelope-from dpelleg@gs166.sp.cs.cmu.edu) Sender: dpelleg@gs166.sp.cs.cmu.edu To: Thane Sherrington References: <5.2.0.9.0.20040120145720.02132688@mail.auracom.com> From: Dan Pelleg Date: 21 Jan 2004 09:20:20 -0500 In-Reply-To: <5.2.0.9.0.20040120145720.02132688@mail.auracom.com> Message-ID: Lines: 69 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-questions@freebsd.org Subject: Re: Using FreeBSD to burn in computers X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 14:21:12 -0000 Thane Sherrington writes: > I'm new to this list, and I'm not a Free-BSD wizard by any means, but for > some time we've been using FreeBSD to burning new systems and to test > systems for stability issues. Below is the procedure we've been using. One > problem we seem to be having now is that if we run top while the various > makes are running, we don't appear to be filling the RAM, so I'm looking for > a way to stress the RAM more completely. If people would like to take a > look at the procedure below and comment on it, I'd really appreciate it. > Using this system has allowed be to find problems quickly that other > diagnostic procedures take days to find. > > [...] > d)type shutdown -h now to restart (I've no idea if this is necessary, but > coming from the Windows world, I reboot after most installs.) :) > Definitely not necessary. > > 5)Running the makes > a)cd /usr/src > b)make world; make world; make world; make world; make world (my idea here > is to run make world and make on XFree86 concurrently, thus stressing the > system further - I'm not sure if this is a good idea or not, but I'm sure > someone will correct me.) Have make start up many compiles in parallel with the -j switch: for example "make -j3". My rule of thumb for a most-effective make is 3 times the number of processor. You will probably want a higher number just so the strain on memory and disk is higher. > > c)cd /usr/ports/x11-servers/XFree86-4-Servers > d)make (it will tell you it doesn't have all the files, and will download > [...] > d)cd /usr/ports/x11/kde3 > e)make (it will tell you it doesn't have all the files, and will download > These are fairly big packages, and you're downloading them from sites operated by mostly non-profit organizations. To save on their bandwidth and costs, you should really make a local copy of the distribution files. An easy way to do this is to do a "make fetch" on one machine, which you keep up and exporting its /usr/ports/distfiles over NFS, and have all the other machines mount that directory over NFS. > This tests the power supply, motherboard, CPU, RAM, hard drive (not > completely of course), CDROM, and NIC. So any failures that crop up after > this are probably due to video or the windows software issues. > > > Please feel free to critique these steps and point out what I'm doing wrong > - I'm sure it could be improved a lot. There's a whole set of special-purpose programs in ports under benchmarks, but I assume you're already familiar with all of those which matter. Here's an idea - try and look at the tuning(7) man page, and apply every suggestion in reverse. I'm half-joking, but things like turning off softupdates should really increase the number of disk accesses. -- Dan Pelleg