Planet MySQL Planet MySQL: Meta Deutsch Español Français Italiano 日本語 Русский Português 中文
First sysbench results comparing Amazon AWS RDS instances
+2 Vote Up -0 Vote Down

RDS instance details

  • sysbench seeded 100Gb database and then snapshotted
  • 1Tb of RDS storage for the database
  • RDS MySQL 5.5.27
  • Default my.cnf RDS configuration except (find the full 'show global variables' output at the end of this post)
    • performance_schema is enabled
    • innodb_flush_logs_at_trx_commit = 0
  • provisioning an RDS instance for each instance size / PIOPS configuration from the seeded database. (10 in total) 

Test details

  • Amazon RDS 
  • Within an AWS VPC
  • US-East

First warm up innodb by running sysbench with options
  • oltp table size 1000000000
  • max-requests 0
  • max-time 300 (5 minute warm up)
  • oltp test mode complex
  • oltp index updates 10
  • oltp user delay max 10
  • oltp-order-ranges 1
  • oltp distinct ranges 5
  • number threads 3
(ie to warm up Innodb etc)
Then running sysbench with the following configuration options
  • oltp table size 1000000000
  • max-requests 0
  • max-time 1800 (Run each for 30 minutes)
  • oltp test mode complex
  • oltp index updates 10
  • oltp user delay max 10
  • oltp-order-ranges 1
  • oltp distinct ranges 5

for thread numbers of 2 4 8 12 16 20 24 28 32 64 128 sleeping 60 seconds between each run.

Note - I'm doing a mixed read/write complex workload attempting to be somewhere near a ball park of workload that we see in production.

Find the test results hereFind the full sized chart of the number of transactions for each instance type hereFind the show variables configuration here
Find the test script here


  • According to cloudwatch for 10,000 PIOPS tests,  I was unable to get past 3000 read & write IOPS.
  • Again according to cloudwatch, the 'upper limit' of IOPS was variable and changed throughout the tests (noisy neighbours).
  • The 128 threads db.m1.small test failed with "FATAL: error 1135: Can't create a new thread (errno 12);"

Summary of results

  • I'm surprised at the (lack of) performance of the db.m2.2xlarge vs db.m1.xlarge  (maybe because m2.2xlarge are not 'ebs optimised'? )
  • db.m2.xlarge was very disappointing and significantly worse than db.m1.xlarge - again perhaps its due to it not being 'ebs optimised'
  • You really dont get much performance unless you go down the PIOPS route. 
  • About a concurrency of 8 is really the tipping point

It would be good to know why the m2.X sized instances perform bad for the price in comparison to m1.X! 

I have captured additional data and will follow up this post after I traverse through it.


You must be logged in with a MySQL account to vote on Planet MySQL entries. More information on PlanetMySQL voting.

Planet MySQL © 1995, 2016, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.