How to stress test DragonFly with Peter Holms kernel-stress-test-suite

[Stefan Krüger]

Some people may have read about Peter Holms Stress Test Suite on
commits@, and yes, Matt and I have found several bugs with it.

To get wider testing I thought I could write a little Stress-Test-Suite
guide, so let's start :)

First of all, get the source, it's available at:

http://www.holm.cc/stress/

and this is the version I'm using in this guide:

SHA1 (stress2.tgz) = 844faff0b5372cdbcfbfbe66ac769df597c56599
Last modified: 23-May-2006 14:31

so let's fetch it:

# fetch http://www.holm.cc/stress/stress2.tgz

untar it somewhere and apply this patch:

http://tecneeq.dyndns.org/~cosmicdj/DragonFly/stress2dfly.patch.gz
SHA1 (stress2dfly.patch.gz) = df468e8ea4f625928fd284bceb8f69f0c5854edb

# cd stress2; zcat ../stress2dfly.patch.gz | patch -p1

but before you start compiling it you need to tell
stress2/lib/resources.c your swapsize, so start your editor and search
for "const int64_t sz = 524256;", now you need to replace 524256 with
your swapsize.

How to do that:

# swapinfo -k
Device          1K-blocks     Used    Avail Capacity
/dev/ad0s1b        637704      156   637548     0%
# echo "637704 / 4" | bc # take the second argument and devide it by 4
159426

Replace the (sz =) 524256 in lib/resources.c with this number!

You can compile the suite now:

# cd ../stress2
# make

One last thing before you can start stressing your machine, edit
default.cfg and change BLASTHOST to an IP with a machine running inetd
with UDP discard enabled. If you don't have such a machine you can set
it to 127.0.0.1 or your local NIC IP. More on that later.

So what's next?

First some considerations. You want to stress-test your machine?
Your machine could panic and fsck takes quite some time... and
uploading 1+GB crashdump isn't fun, too. So we'll do a reboot!

At the Beasty-bootmenu, select

6. Escape to loader prompt

and at the

ok

prompt we'll first limit the memory dragonflybsd sees (and thus the
crashdump size) to 256MB

ok set hw.physmem="256M"

and then we'll boot into single-user mode

ok boot -s

first thing we'll do is

$ fsck -p

and then we'll mount some important dir's read-only!

$ mount -r /home	# this is were the stress-test-suite is
$ mount -r /usr	# you can leave this out but some cmds might come handy
$ mount /tmp	# usualy MFS, if not: mount_mfs -s 262144 swap /tmp
$ mount /proc	# shouldn't hurt...

then we'll start some services:

$ /etc/rc.d/dumpon start # don't forget to set up a dumpdev in rc.conf
$ /etc/rc.d/swap1 start	 # a stress-test needs it
$ /etc/rc.d/netif start

If you don't have a blasthost with UDP discard in your network,
just start a local inetd (don't forget to uncomment

discard dgram   udp     wait    root    internal

in /etc/inetd.conf!)

$ inetd -R 0 -p /tmp/inetd.pid	# -R 0 disable rate limiting,
				# needed for the udp stress-test

some handy sysctl's:

$ sysctl -w vfs.ufs.dirhash_docheck=1
$ sysctl -w debug.dircheck=1
$ sysctl -w debug.ttydebug=1
$ sysctl -w lwkt.token_debug=1
$ sysctl -w debug.spin_lock_test=1
$ sysctl -w kern.syscall_mpsafe=1
(kern.intr_mpsafe/kern.trap_mpsafe aren't safe yet,
 so don't enable them!)

Quoting stress2/README: "Do not run the tests as root."

so let's switch to an ordinary user:

$ su -m localuser
# cd /home/localuser/stress2
# INCARNATIONS=10 ./run.sh

if you want some verbosity:

# VERBOSE=4 ./run.sh

and if you want to run all tests:

# ./run.sh all.cfg

and that's it. If the stress-test triggers a panic, you're on a safe
side because everything is mounted read-only.

One last hint, if you got a panic, you need to boot with the same
hw.physmem settings otherwise savecore will not find your crashdump!