DragonFly kernel List (threaded) for 2006-06
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
How to stress test DragonFly with Peter Holms kernel-stress-test-suite
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!
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]