Re: Server testing.

I used the cpuburn program too ( http://users.ev1.net/~redelm/ ). It REALLY
heats up the processor - interesting to watch the +5 volt immediately drop
significantly (using healthd -d). The other voltages also change accordingly.

The test doesn't touch files unlike a kernel recompile, so if you find you
have a flaky system there's a lower chance of a corrupted filesystem.

Plus compiling doesn't put as much load on my CPU - the +5V doesn't drop as
much. I suspect there's not as much FPU access whilst compiling. And the
FPU units are significant power consumers.

Not sure what to use for testing P4s tho (there isn't a cpuburn test
specifically for P4s). I'm using an Athlon XP so I use the burnK7 program.

Good luck,
Link.

At 05:12 PM 12/16/02 -0700, scott.marlowe wrote:

>This recent thread about a server crashing got me to thinking of server
>acceptance testing.
>
>When you are faced with the daunting task of testing a server, you should
>be trying to break it. Honestly, this is the most common mistake I see,
>if folks ordering a new server and simply assuming there's no problems
>with it. Assume all hardware is bad until you've proven to yourself
>otherwise. No at what point your hardware will be brought to it's knees
>(or worse) before your users can do that to you.
>
>Here are a few good tests for bad hardware that I've found, if anyone else
>has any, please chip in. Note that not all failures are deterministic and
>repeatable. Some show up very seldomly, or only when the server room is
>above 70 degress. It's easy to know when you've got a big problem with
>your hardware, but often hard to see the little ones.
>
>The first thing I test with is compiling the linux kernel AND / OR
>compiling Postgresql. Both are complex projects that stress the system
>fairly well. Toss in a '-j 8' setting and watch the machine chew up
>memory and CPU time.