我目前正在手动将数据从一个 EBS 卷复制到另一个较小的 EBS 卷，因为我们有 XFS 文件系统，该文件系统无法缩小。
我正在使用带有 Amazon Linux 2 AMI 的 t3.micro 实例（EBS 优化），该实例将两个 EBS 卷（gp2）附加到主实例上（所有内容都位于同一可用区中）
我已经这样做了，复制 95GB 的数据大约需要 5-10 分钟（也就是 10 分钟，吞吐量为 162MB/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
如您所见，我的吞吐量低于 10MB/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%。
编辑：它已经停止发生在一个新的时间我已经这样做了
答案1
打开 Amazon Cloudwatch 并查看实例的“CPUCreditBalance”。以每 5 分钟的采样率查看可用的总积分。积分是否在任何时候都下降到接近 0？
“T” 型 AWS 实例是一种突发、性能受限的类型。t2.micro 实例每小时只能获得 6 个 CPU 积分。这意味着您的 CPU 只能以持续 10% 的使用率运行，否则它将耗尽所有积分并变得非常缓慢。
增加实例类型的大小。我建议在复制完成之前更改为足够大小的“C”类型实例。之后您可以降级回较小的实例。
答案2
2019 年更新
另一个更可能的答案是实例吞吐量限制，这已经经过测量和记录这里。t2.micro 的基线为 0.06Gbps，约为 7.5MB/秒，但它可以突发到该速度的 10 倍左右。
EBS 积分
一种可能是您用完了 EBS 信用额度，这与 t2/t3 CPU 余额是分开且不同的。阅读这篇关于它的 AWS 文章。
将所有卷的“EBS 突发平衡”添加到 CloudWatch 仪表板。如果任何卷处于或接近零，那就是您的答案。如果不是，请继续寻找。
这是我链接到的文档的一部分。
许多 AWS 客户使用我们在 2014 年中期推出的通用 SSD (gp2) EBS 卷获得了出色的效果（有关详细信息，请参阅新的 SSD 支持的弹性块存储）。如果您不确定要为您的工作负载使用哪种卷类型，gp2 卷是最佳默认选择，因为它们为各种数据库、开发和测试以及启动卷工作负载提供了平衡的性价比。此卷类型最有趣的方面之一是突发功能。
我们设计了 gp2 的突发功能，以适应我们在客户群中观察到的实际工作负载的 I/O 模式。我们的数据科学家发现，卷 I/O 具有极强的突发性，会在短时间内出现峰值，并且在突发之间有大量空闲时间。正是由于流量的这种不可预测和突发性，我们设计了 gp2 突发存储桶，以便即使最小的卷也能突发到 3000 IOPS，并在空闲时间或执行低水平 I/O 时补充其突发存储桶。突发存储桶设计使我们能够为所有 gp2 用户提供一致且可预测的性能。实际上，很少有 gp2 卷会完全耗尽其突发存储桶，现在客户可以跟踪他们的使用模式并进行相应调整。
我们已经广泛撰写了有关不同卷类型的性能优化以及基准测试和实际工作负载之间的差异的文章（有关更多信息，请参阅 I/O 特性）。正如我在原始帖子中所描述的那样，突发信用以每秒每配置 GB 3 个的速度累积，每个信用用于一次读取或一次写入。每个卷最多可以累积 540 万个信用，每个卷每秒最多可以花费 3,000 个信用。要开始使用，您只需创建所需大小的 gp2 卷，启动您的应用程序，然后您对该卷的 I/O 将尽可能快速高效地进行。