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
Observations
- 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'? http://aws.amazon.com/ec2/instance-types/ )
- 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.