Working with Provisioned IOPS Storage

The theoretical maximum IOPS rate is also a function of database I/O page size and available channel bandwidth. MySQL uses a page size of 16 KB, while Oracle and SQL Server use 8 KB. 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 and 12,500 IOPS in each direction for 8 KB I/O. A workload consisting of 50% reads and 50% writes could reach 12,500 IOPS with 16 KB I/O or 25,000 IOPS with 8 KB I/O.

If traffic on one of the channels reaches capacity, available IOPS on the other channel cannot be reallocated. As a result, the attainable IOPS rate will be less than the provisioned IOPS rate.

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. IO requests larger than 16 KB are treated as more than one IO for the purposes of PIOPS capacity consumption. A 20 KB IO request will consume 1.25 IOs, a 24 KB request will consume 1.5 IOs, a 32 KB request will consume 2 IOs, and so on. The IO request is not split into separate IOs; all IO requests are presented to the storage device unchanged. For example, if the database submits a 128 KB IO request, it goes to the storage device as a single 128 KB IO request, but it will consume the same amount of PIOPS capacity as eight 16 KB IO requests.

The following table shows the page size and the theoretical maximum IOPS rate for each DB engine. IOPS rates are based on the m2.4xlarge instance class with full duplex and a workload that is perfectly balanced between reads and writes.

If you are using Provisioned IOPS storage, we recommend that you use the m1.large, m1.xlarge, m2.2xlarge, and m2.4xlarge instance classes. These instance types are optimized for Provisioned IOPS storage; other instance types are not. In addition, the available network bandwidth for Provisioned IOPS for m1.large instance class is 500 megabits per second (Mbps) compared to 1000 Mbps for an m1.xlarge, m2.2xlarge, or m2.4xlarge instance. As a result, for a similar IOPS-intensive workload, the number of realized IOPS for m1.xlarge, m2.2xlarge, and m2.4xlarge will be higher than that of m1.large.

System activities such as automated backups, DB snapshots, and scale storage operations may consume some I/O, which will reduce the overall capacity available for normal database operations. If your database design results in concurrency issues, locking, or other forms of database contention, you may not be able to directly use all the bandwidth that you provision.

If you provision IOPS capacity to meet your peak workload demand, during the non-peak periods, your application will probably consume fewer IOPS on average than provisioned.

To help you verify that you are making the best use of your Provisioned IOPS storage, we have added a new CloudWatch Metric called Disk Queue Depth. If your application is maintaining an average queue depth of approximately 5 outstanding I/O operations per 1000 IOPS that you provision, you can assume that you are consuming the capacity that you provisioned. For example, if you provisioned 10,000 IOPS, you should have a minimum of 50 outstanding I/O operations in order to use the capacity you provisioned.