AWS EBS卷上的磁盘吞吐量非常低

Question

我目前正在手动地将数据从一个EBS卷复制到另一个大小较小的EBS卷，因为我们有XFS文件系统，这是无法减少的。

我对AmazonLinux2AMI使用了一个t3微实例(优化的EBS )，它将两个EBS卷(gp2)附加到来自实例的主实例(同一可用性区域中的所有内容)。

我已经这样做了，大约需要5-10分钟才能复制95 of的数据(如果是10分钟，162 of /S的吞吐量)，但是现在，同样的容量，它是非常慢的。

复制过程是：

tar cSf - /mnt/nvme1n1p1/ | cat | (cd ../nvme2n1p1/ && tar xSBf -)

我让它在后台运行，同时使用iostat -xm 5 3进行检查，我得到了以下结果：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.07    0.02    0.86   39.62    0.05   59.39

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme1n1           0.00     0.00   54.20    0.00     6.70     0.00   253.19     0.94   34.62   34.62    3.56  17.32  93.90
nvme2n1           0.00     0.28    0.06   27.20     0.00     6.71   503.98     0.14    6.67    0.31    6.68   1.22   3.32
nvme0n1           0.00     0.02    2.10    0.90     0.04     0.00    30.65     0.00    0.63    0.63    0.62   0.08   0.02

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.10    0.00    0.70   37.54    0.00   61.66

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme1n1           0.00     0.00   46.40    0.00     5.80     0.00   256.00     1.00   43.16   43.16    0.00  21.48  99.68
nvme2n1           0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
nvme0n1           0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.90   38.66    0.10   60.34

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme1n1           0.00     0.00   53.80    0.00     6.73     0.00   256.00     1.00   36.67   36.67    0.00  18.57  99.92
nvme2n1           0.00     0.00    0.00   16.00     0.00     4.00   512.00     0.03    3.20    0.00    3.20   0.80   1.28
nvme0n1           0.00     0.60    0.00    1.40     0.00     0.02    23.14     0.00    0.00    0.00    0.00   0.00   0.00

如您所见，我的吞吐量低于10 is /S，而且越来越少。我一直在阅读关于EBS吞吐量的文章，我不知道它会是什么，如果有任何惩罚或类似的事情.

你知道会是什么吗？

谢谢！)

更多被要求的信息：

ulimit -a：

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3700
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3700
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

df -h：

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        463M     0  463M   0% /dev
tmpfs           480M     0  480M   0% /dev/shm
tmpfs           480M  380K  480M   1% /run
tmpfs           480M     0  480M   0% /sys/fs/cgroup
/dev/nvme0n1p1  8.0G  1.1G  7.0G  13% /
tmpfs            96M     0   96M   0% /run/user/1000
/dev/nvme1n1p1  500G   93G  408G  19% /mnt/nvme1n1p1
/dev/nvme2n1p1  150G   55G   96G  37% /mnt/nvme2n1p1

EBS突发余额一直是+98%。

编辑:它已经在新的时间停止了--我已经完成了--

Answer 1

打开Amazon并检查实例的“CPUCreditBalance”。看看总学分，每5分钟抽样率。学分在任何时候都会下降到接近0吗？

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-monitoring-cpu-credits.html

‘T’类型的AWS实例是一个可扩展的、性能有限的类型。一个t2.微型实例每小时只赚6个CPU学分。这意味着你的CPU只能在持续的10%的使用率下运行，否则它会消耗掉所有的学分并缓慢地爬行。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-monitoring-cpu-credits.html

增加实例类型的大小。我建议在复制完成之前更改为足够大小的“C”类型实例。之后，您可以将其降级为较小的实例。

Answer 2

更新2019年

另一个可能也是更有可能的答案是实例吞吐量限制，它已经测量并记录了这里。一个t2微型的基线是0.06Gbps，大约是7.5MB/秒，尽管它可以爆到大约10倍。

EBS信贷

一种可能是，您已经用完了EBS学分，这是独立的，有别于t2/t3 CPU平衡。读这篇AWS关于它的文章。

在您的CloudWatch仪表板中添加所有卷的"EBS突发余额“。如果有人处于或接近零，那就是你的答案。如果没有，继续找。

这是我链接到的文档的一部分。

很多AWS客户都在我们2014年年中推出的通用SSD (gp2) EBS卷中获得了很好的结果(有关更多信息，请参见新的SSD支持的弹性块存储)。如果您不确定工作负载使用哪种卷类型，那么gp2卷是最好的默认选择，因为它们为各种各样的数据库、开发和测试以及引导卷工作负载提供了均衡的价格/性能。这种卷类型的一个更有趣的方面是突发特性。我们设计了GP2‘S突发功能，以适应我们在客户基础上观察到的真实世界工作负载的I/O模式。我们的数据科学家发现，音量I/O是非常迅速的，在短时间内猛增，在爆发之间有大量的空闲时间。这种不可预测和突发的流量特性是我们设计gp2突发桶的原因，它允许即使最小的卷也能在空闲时间或执行低级别I/O时突发多达3000个IOPS并补充它们的突发桶，这种突发桶设计允许我们为所有gp2用户提供一致和可预测的性能。在实践中，很少有gp2卷完全耗尽了它们的突发桶，现在客户可以跟踪它们的使用模式并进行相应的调整。我们已经编写了关于不同卷类型的性能优化以及基准测试和实际工作负载之间的差异的大量文章(有关更多信息，请参见I/O特性)。正如我在最初的文章中所描述的，突发积分以每秒3 GB的速度累积，每个人支付一次读或写的费用。每卷可累积540万学分，每卷每秒可花费3 000多个学分。首先，您只需创建所需大小的gp2卷，启动应用程序，您对卷的I/O将尽可能快速有效地进行。