DevOps Zone is brought to you in partnership with:

Harish Ganesan is the CTO and Co-Founder of 8KMiles and is responsible for the overall technology direction of the 8KMiles products and services. He is also frequent speaker at Cloud Connect, Cloud Summit, AWS Summit, Cloud Developer Conference, CII-Cloud Computing and other Popular Cloud conferences in the industry. Harish has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

Understanding the Amazon EBS IO Block Size and its Performance Impacts

04.20.2013
| 4183 views |
  • submit to reddit
The IOPS rate you get usually depends on the I/O size of your applications’ reads and writes. It is very important to know the I/O size your application operates and accordingly expect the performance from EBS Volumes. Provisioned IOPS volumes process your applications’ reads and writes in I/O sizes of 16KB blocks or less. Every increase in I/O size above 16KB will linearly increase the resources you need to achieve the same IOPS rate. For example, if you have provisioned a volume with 2000 IOPS, that means that it can handle 2000 16KB writes per second, or 1000 32KB writes per second, or 500 64KB writes per second, and so on. You can use Amazon CloudWatch to monitor your EBS Volumes throughput and I/O size for a while and decide what best suits for your case. Since PIOPS is especially designed for Database context, let us explore how it pans out in Amazon RDS.  Following are some of the important points to note on PIOPS + RDS context.
P1) The theoretical maximum IOPS rate is also a function of database I/O page size and available channel bandwidth. Each page read or write constitutes one I/O operation. Database operations that read or write more than a single page will use multiple I/O operations for each database operation. For example, for a page size of 16 KB, if a read operation requires 32 KB, you would need 2000 IOPS to achieve 1000 read operations per second.
P2) If you provision an IOPS rate that is higher than the maximum or that is higher than your realized IOPS rate, you may still benefit from reduced latency and improvements in overall throughput. Applicability of the following points and IOPS rates are based on the m2.4xlarge instance class with full duplex (1000 Mbit/second) and a workload that is perfectly balanced between reads and writes. ·MySQL uses a page size of 16 KB and can do 12,500 IOPS. On a DB instance with a full duplex I/O channel bandwidth of 1000 megabits per second (Mbps), the maximum IOPS for page I/O is about 6,250 IOPS in each direction for 16 KB I/O. This is for a workload consisting of 50% reads and 50% writes and could reach 12,500 IOPS with 16 KB I/O.
·Oracle uses a page size of 8KB and can do 25,000 IOPS. On a DB instance with a full duplex I/O channel bandwidth of 1000 megabits per second (Mbps), the maximum IOPS for page I/O is about 12,500 IOPS in each direction for 8 KB I/O. This is for a workload consisting of 50% reads and 50% writes and could reach 25,000 IOPS with 8 KB I/O.
·SQL Server uses a page size of 8KB and can do 10,000 IOPS. On a DB instance with a full duplex I/O channel bandwidth of 1000 megabits per second (Mbps), the maximum IOPS for page I/O is about 5,000 IOPS in each direction for 8 KB I/O. This is for a workload consisting of 50% reads and 50% writes and could reach 10,000 IOPS with 8 KB I/O.
Note : Please refer the AWS Documentation for latest PIOPS 
Published at DZone with permission of its author, Harish Ganesan.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)