Thane Sherrington <[EMAIL PROTECTED]> 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.
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"