I have a spanking new machine destined to be a high-volume production mail
server. I want to try and stress-test it to see what will break (if
anything) - I'd like to detect as many problems as possible before we put it
in the computer room. I'm looking for typical things like
memory/controller/problems which surface quickly.
The machine's specs are:
Dual PII/350
128MB 100Mhz RAM
3c590 network adapter
2x AHA2970
4x IBM scsi (4GB), destined to be a raid5'ed /var/ partition.
Small IDE disk for the root (should be 95% read-only).
I'll be using kernel 2.0.36 to begin with, anxiously anticipating the
release of 2.2.0. :-)
My question is, what methods do people use to stress test sw/hw
combinations?
I've currently got the machine in lots of tight loops making TCP connections
to itself constantly, and compiling the kernel willy-nilly, but I was
wondering if any of you had any better ideas for me.
Also, are there any obvious problems with this hardware configuration?
Btw, I think I came up with a pretty clear-cut demonstration of why 2.0.x
SMP isn't good enough:
dd if=/dev/urandom bs=1024k count=24 | gzip -c |zcat >/dev/null
locks the machine up reeeal tight for 1-2 seconds, with incredibly delayed
(or missing) responses from the console itself (just switching VTs could
take 2-3 seconds). This is actually bad enough to be a primitive denial of
service attack..
This same command didn't have any noticable effect on my trusty old
single-processor 5x86/160 here at home, so it appears that enabling SMP can
in some cases cause a performance hit instead of a gain. (I suppose this is
probably old news, but I thought I'd see if any interesting discussions
would result from my experience.. ;)
Thanks in advance, and happy holidays!
-- Bjarni R. Einarsson [ PGP: 02764305 / B7A3AB89 ] bre@netverjar.is -=- http://www.mmedia.is/~bre/ -=- Juggler@IRCnet* http://www.europarl.eu.int/dg4/stoa/en/publi/166499/execsum.htm * Encrypt the covert narcotics, launder nuclear biotechno cash on the way to Swiss with your GSM phone - are you paranoid enough?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/