Using Nstress to Stress your System

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>

Example:

nstress output

As you can see above, I spun up for processes using ncpu and you can see I saturated the amount of physical processors used, and as well as the entitlement.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *