mirror of
https://github.com/scylladb/scylladb.git
synced 2026-04-20 08:30:35 +00:00
0c29289c22
We can use iotunev2 (or any other I/O generator) to test for the limits of the disks for the i2 and i3 instance classes. The values I got here are the values I got from ~5 invocations of the (yet to be upstreamed) iotune v2, with the IOPS numbers rounded for convenience of reading. During the execution, I verified that the disks were saturated so we can trust these numbers even if iotunev2 is merged in a different form. The numbers are very consistent, unlike what we usually saw with the first version of iotune. Previously, we were just multiplying the concurrency number by the number of disks. Now that we have better infrastructure, we will manually test i3.large and i3.xlarge, since their disks are smaller and slower. For the other i3, and all instances in the i2 family storage scales up by adding more disks. So we can keep multiplying the characteristics of one known disk by the number of disks and assuming perfect scaling. Example for i3, obtained with i3.2xlarge: read_iops = 411k read_bandwidth = 1.9GB/s So for i3.16xlarge, we would have read_iops = 3.28M and 15GB/s - very close to the numbers advertised by AWS. Signed-off-by: Glauber Costa <glauber@scylladb.com>