IOPS(在Amazon EBS中)在实践中是什么意思? [英] What does IOPS (in Amazon EBS) mean in practice?

问题描述

我有一些应用程序需要的图像.图片很多(50,000+)，但整体大小很小(40 Mb).最初，我以为我只会使用S3，但是上传起来却很慢.作为一个临时解决方案，我想附加一个包含图像的EBS，这样就可以了.但是，在阅读有关EBS通用(gp2)的内容时，我注意到了以下描述:

I have some images needed for an app. There are many images (50,000+) but the overall size is small (40 Mb). Initially, I thought I would simply use S3 but it is painfully slow to upload. As a temporary solution, I wanted to attach an EBS containing the images and that would be fine. However, reading a bit about EBS General Purpose (gp2) I noticed the following description:

GP2是Amazon EC2实例的默认EBS卷类型.这些 卷由固态驱动器(SSD)支持，适用于 广泛的事务性工作负载，包括开发/测试 环境，低延迟交互式应用程序和启动卷. GP2旨在提供单位毫秒的延迟，提供 一致的基准性能为3 IOPS/GB ，最高为10,000 IOPS，并且每卷提供高达160 MB/s的吞吐量.

GP2 is the default EBS volume type for Amazon EC2 instances. These volumes are backed by solid-state drives (SSDs) and are suitable for a broad range of transactional workloads, including dev/test environments, low-latency interactive applications, and boot volumes. GP2 is designed to offer single-digit millisecond latencies, deliver a consistent baseline performance of 3 IOPS/GB to a maximum of 10,000 IOPS, and provide up to 160 MB/s of throughput per volume.

让我担心的是3 IOPS/GB数量.这实际上意味着什么?假设您需要一个用于少量用户的电子商务站点(例如，每分钟<10,000个请求)，并且需要检索这些图像.亚马逊描述如何测量IOPS:

It is that 3 IOPS/GB quantity that is worrying me. What does this mean in practical terms? Suppose that you need an e-commerce site for a small amount of users (e.g. < 10,000 requests per minute) and these images need to be retrieved. Amazon describes how IOPS are measured:

当小型I/O操作在物理上连续时，Amazon EBS 尝试将它们合并为最大大小的单个I/O.为了 例如，对于SSD卷，单个1,024 KiB I/O操作将很重要 作为4个操作，而每个4 KiB的256个I/O操作将算作 256次操作.

When small I/O operations are physically contiguous, Amazon EBS attempts to merge them into a single I/O up to the maximum size. For example, for SSD volumes, a single 1,024 KiB I/O operation would count as 4 operations, while 256 I/O operations at 4 KiB each would count as 256 operations.

这实际上是否意味着如果我想在一秒钟内检索50张10kB的图像，我将需要50 IOPS并轻易超过3 IOPS的基准?

Does this actually mean that if I want to retrieve 50 images of 10kB each in under a second, I would require 50 IOPS and easily exceed the baseline of 3 IOPS?

更新:

由于Mark B的建议，我能够使用S3上传文件.但是，我仍然想知道执行常见任务(例如运行数据库或为Web应用程序提供其他文件)所需的IOPS数量.根据您的经验，我很高兴听到一些有关IOPS最小值的参考值.

Thanks to Mark B's suggestion, I was able to use S3 to upload my files. However, I'm still wondering about the amount of IOPS needed to perform common tasks such as running a database or serving other files for a web application. I would be glad to hear some reference values regarding the minimal values of IOPS based on your experience.

推荐答案

您缺少该语句的"/GB "部分.基准是每GB 3 个IOPS.如果您的EBS容量为100GB，那么基线将为300 IOPS.对于GP2 EBS卷，您必须将卷的大小乘以3才能获得IOPS.

You are missing the "/GB" part of that statement. The baseline is 3 IOPS per GB. If your EBS volume is 100GB, then you would have a baseline of 300 IOPS. For a GP2 EBS volume you have to multiple the size of the volume by 3 to get the IOPS.

请注意，任何1TB以下的GP2卷也能够以高达3,000 IOPS的速度爆发，因此，任何有限的IO增长都应该表现得很好.

Note that any GP2 volume under 1TB is also able to burst at up to 3,000 IOPS, so any limited increases in IO should still perform very well.

此外，我还要补充一点，S3听起来更适合您的用例.如果您看到上传到S3的速度较慢，则可以解决此问题.您可以使用 CloudFront 提供您可以上传到附近的边缘位置.

Also, I will add that S3 sounds like a better fit for your use case. If you are seeing slow upload speeds to S3, that is a problem that can be solved. You can use CloudFront to provide a nearby edge location that you can upload to.

以我的经验，上传到S3永远不会比上传到您的EBS卷将附加到的EC2实例慢.

In my experience uploads to S3 are never any slower than uploads to an EC2 instance that your EBS volume would be attached to.

更新:

要回答其他问题，所需的最低IOPS取决于许多变量，例如可用的RAM量，运行的应用程序类型，应用程序在内存中缓存值的程度，IO操作的平均大小等等.确定一个确切的数字并指出应用程序需要X IOPS确实很困难.

To answer your additional question, the minimum IOPS needed will depend on many variables such as the amount of RAM available, the type of application you are running, how well the application caches values in memory, the average size of your IO operations, etc. It's really difficult to pin-down an exact number and state that you need exactly X IOPS for an application.

您还需要记住，任何小于1TB的卷都可以在几秒钟内爆裂到3,000 IOPS.因此，即使您的应用程序在使用时需要较高的IOPS，如果使用率不高，IOPS突发功能也可能是它所需要的.

You also need to remember that any volume under 1TB in size can still burst up to 3,000 IOPS for several seconds. So even if your application needs high IOPS when it is in use, if it doesn't see much usage the IOPS burst feature might be all it ever needs.

通常，我通常从100GB的卷开始，并具有300 IOPS，并以此测试我的应用程序的性能.完全在RAM中运行的Web服务器可能再也不需要更多了.对于诸如数据库之类的东西，您可能会从您认为需要的磁盘空间开始，然后开始性能测试. CloudWatch将显示您的应用程序正在使用的IOPS数量，如果您看到它在卷的限制处达到最大值，那么您将知道需要增加可用的IOPS.冲洗并重复操作，直到在性能测试期间不再使可用IOPS达到最大值为止.

In general I usually start with something like a 100GB volume with 300 IOPS and test the performance of my app against that. A web server that operates entirely within RAM might never need more than that. For something like a database you would probably start out with the amount of disk space you think you will need and then start performance testing. CloudWatch will show the amount of IOPS your application is using, and if you see it maxing out at the limits of your volume then you would know you need to increase the available IOPS. Rinse and repeat until you no longer max out the available IOPS during your performance tests.

这篇关于IOPS(在Amazon EBS中)在实践中是什么意思?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！