Posts Tagged ‘IO’

Linode filesystem performance

January 19th, 2010

In a previous article, I wrote about using bonnie++ (http://www.coker.com.au/bonnie++/) to benchmark the performance of your hard drives and filesystem.  We went through a sample command, explained all the parameters (most notably, -s).

In this post I’d like to display and summarize the results from running bonnie++ on two systems:  a Linode (as the title suggests) and a physical server as the control.

Linode is a VPS hosting company with availability in the US and Europe.  They strive for the best service possible, and are a very well regarded provider within the hosting community.  The linode I chose for the purposes of this test is their “Linode 360″ which comes with 360MB RAM, 16GB of storage, 200GB of transit, and a price tag of $19.95 per month.  This is their entry-level setup, and their instances can scale up to 2.8GB RAM, 128GB storage, 1.6TB transit (for $159.95/month).

The command we’re running to invoke bonnie++ is:

# bonnie++ -u 0 -r 360 -s 7200 -n 256  -b -d /

Note the new values for -r and -s from my last post.

Results (click for a larger version):

On the far left of the results, in bold, you will see the machine’s hostname.  In my case, this is the Linode assigned hostname of li149-50.  The next column is labeled “Size: Chunk Size,” which is basically the size we specified as the size to use for IO performance measurements (the -s flag).

As stated in my last post, bonnie++ offers three specific metrics:

  1. Data read and write speed.
  2. Maximum seeks per second.
  3. Maximum file metadata operations per second.

Applying these three metrics to our results, the following correlations  can be established:

  • Sequential Input and Sequential Output apply to 1
  • Random Seeks apply to 2
  • Sequential Create and Random Create apply to 3

Now, let’s summarize with real numbers.

Server li149-50 was able to:

  • sustain ~85MBS at 13% CPU for sequential block writes.
  • sustain ~180MBS at 0% CPU for sequential block reads.
  • max out at 167.9 random seeks per second.
  • sequentially create 2,236 files per second.
  • randomly create 2,001 files per second.
  • sequentially read metadata from 395,067 files per second at 99% CPU.
  • randomly read metadata from 503,021 files per second at 99% CPU.
  • sequentially delete 1,014 files per second.
  • randomly delete 610 files per second.

Running the same bonnie++ command (with different -r and -s flags) on a physical server with an 80GB PATA drive yields the following (for reference, the values were “1024″ and “20480″ for “-r” and “-s”, respectively):

# bonnie++ -u 0 -r 1024 -s 20480 -n 256  -b -d /

Results (click for a larger version):

Summarizing in a similar fashion from above, we get the following:

Server tp.eliminated.org was able to

  • sustain ~41MBS at 29% CPU for sequential block writes.
  • sustain ~50MBS at 10% CPU for sequential block reads.
  • max out at 71 random seeks per second.
  • sequentially create 447 files per second.
  • randomly create 2,001 files per second.
  • sequentially read metadata from 288,111 files per second.
  • randomly read metadata from 503,021 per second.
  • sequentially delete 225 files per second.
  • randomly delete 610 files per second.

Note that the metrics regarding file metadata operations are based off of the number of files on which we test (the -n flag).  Since the value supplied to -n was the same on both servers (256), the results we get back are very similar (if not the same).

I will continue to benchmark various VPS and Cloud providers in order to ascertain IO performance from as many providers as possible.

Benchmarking hard drives and filesystems with bonnie++

January 18th, 2010

Bonnie++ (http://www.coker.com.au/bonnie++/) is “a benchmark suite that is aimed at performing a number of simple tests of hard drive and file system performance.”   Bonnie++ outputs a 80-column display report (to fit on braille keyboards), as well as csv values that can be converted to text or HTML (with bon_csv2txt and bon_csv2html, respectively).

Bonnie++ provides performance metrics on the following 3 things:

  1. Data read and write speed:  This should be fairly obvious.  This is how fast you can read and write to the drive(s) in question.
  2. Maximum number of seeks per second:   If the blocks that your computer needs are not sequentially stored (right next to each other), then the heads in the HD will have to do a seek (physically moves the heads to the right platter).
  3. Maximum number of file metadata operations per second:  Metadata operations include things like file creation, deletion, or gathering any other metadata about a file (permissions, size, etc).

In order to run all of the tests included, I ran the following command:

# bonnie++ -u 0 -r 1024 -s 20480 -n 256  -b -d /

Let’s break down the parameters passed to bonnie++:

  • -u 0:  The -u flag is used to indicated the UID that the test should run as.  UID 0, as we all know, belongs to the root user.
  • -r 1024:  The -r flag is used to indicate how much RAM (in megabytes) is in the machine.  As you can see I have 1gb (1024mb).
  • -s 20480:  The -s flag is used to indicate the size of the file(s) (in megabytes) to be used for IO performance testing.  More on this value later.
  • -n 256:  Specifies the number of files for the file creation test.  This is in multiples of 1024 files, so 256 = 252,144 (256*1024) files.
  • -b: The -b flag is used to disable any system-level buffering.  Basically this means an fsync() is called after every write operation.
  • -d /:  The -d flag is used to indicate the path on which to perform the tests.

Of all the runtime parameters, -s is probably the most important to define properly.  This flag (in megabytes) defines the size of the files used for IO performance benchmarking.  If the supplied size is greater than 1gb, then multiple 1gb files will be used until the value is reached.  In order to get proper results, you will want to specify a number much larger than the amount of RAM you have.  If possible, use a much higher multiple, like 20x.   To be sure to bypass any caching done by the hardware, you want at least 2-3x the amount of RAM.