I think it’s important to stress your hardware as much as possible. It’s kind of like when you buy a new car, you always punch the gas a little bit to see what the thing can do! Likewise, with your enterprise hardware, you want to give it a little gas. What I like to do is stress new hardware out as much as I can – and in this way you can record what the theoretical max on what you can get out of your new purchase.
One of the tools I like to use (for POWER hardware), is a tool called nstress. This is a free tool you can download from IBM’s website, and its goal is to stress your hardware in different ways. There are some utilities that you’ll be able to simulate different kinds of load and stress:
- ncpu – loads/stresses the CPU
- ndisk64 – loads/stresses disks
- nfile – creates / removes files in order to stress your filesystem
- nipc – stresses shared memory
- nmem64 – loads/stresses memory
Now there are several other utilities provided by nstress, but I’ll be focusing on ncpu and ndisk respectively. Nstress comes with some shell scripts that wrap some of these utilities to simulate things like web servers and database servers.
You can get nstress from IBM’s website, like so:
gvicaixnim01:/ # mkdir /tmp/stress gvicaixnim01:/ # cd /tmp/stress gvicaixnim01:/tmp/stress # wget http://public.dhe.ibm.com/systems/power/community/wikifiles/PerfTools/nstress_AIX6_April_2014.tar Resolving public.dhe.ibm.com... 170.225.15.112 Connecting to public.dhe.ibm.com[170.225.15.112]:80... connected. HTTP request sent, awaiting response... 200 OK 18:06:56 (775.55 KB/s) - `nstress_AIX6_April_2014.tar' saved [665600/665600] gvicaixnim01:/tmp/stress # tar -xvf nstress_AIX6_April_2014.tar x ndisk64posix, 134345 bytes, 263 media blocks. x ncpu, 29034 bytes, 57 media blocks. x ndisk64, 134077 bytes, 262 media blocks. x nmem, 26007 bytes, 51 media blocks. x nmem64, 29242 bytes, 58 media blocks. x nlog, 147085 bytes, 288 media blocks. x nipc, 23290 bytes, 46 media blocks. x nfile, 39501 bytes, 78 media blocks. x ipctest, 27746 bytes, 55 media blocks. x nram, 40579 bytes, 80 media blocks. x createfs.sh, 353 bytes, 1 media blocks. x dbstart.sh, 1458 bytes, 3 media blocks. x webstart.sh, 985 bytes, 2 media blocks. x README, 10685 bytes, 21 media blocks.
ncpu
Syntax: nstress -p <number of processes to spool up> -s <time>
ndisk
The first thing I’m going to do is create a large file, around one gigabyte:
dd if=/dev/zero of=bigfile bs=1m count=1024
Next, I’m going to kick off an ndisk64 process that’s going to do 100% sequential reads across different block sizes:
./ndisk64 -f bigfile -S -r100 -b 4096:8k:64k:1m -t 600
You’ll get an output similar to below:
Proc - | RunTime Num - TOTAL IO/sec | MB/sec KB/sec Seconds 1 - 225901254 376501.0 | 1470.71 1506004.06 600.00 ----> Running test with block Size=8192 (8KB) .
Now you have to be careful about trusting some of the output here from ndisk when dealing with reads and writes. Some of the time, you’re going to be hitting cache, so what I do is run a few of them in the background. You can play with the different ratio of reads and writes, as well as sequential vs random writes and reads.
