我有一组运行 Carbon 和 Graphite 的机器，需要扩展它们以获取更多存储空间，但我不确定是否需要扩大或缩小规模。
该集群当前由以下部分组成：
- 1 个中继节点：接收所有指标并转发到相关存储节点
- 6 个存储节点：存储所有 Whisper DB 文件
问题在于，当磁盘使用率达到 80% 左右时，性能似乎会急剧下降。集群写入 IOPS 从接近恒定的 13k 下降到更混乱的平均值 7k 左右，IOwait 时间平均为 54%。
我查看了我们的配置库，自 4 月初以来没有任何变化，所以这不是配置更改的结果。
问题：增加磁盘大小是否会使 IO 性能重新得到控制，还是需要添加更多存储节点？
笔记：这里没有固态硬盘 (SSD)，只有很多很多的主轴。
相关图表：
统计数据和资料：
e2freefrag：
[root@graphite-storage-01 ~]# e2freefrag /dev/vda3
Device: /dev/vda3
Blocksize: 4096 bytes
Total blocks: 9961176
Free blocks: 4781849 (48.0%)
Min. free extent: 4 KB
Max. free extent: 81308 KB
Avg. free extent: 284 KB
Num. free extent: 19071
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range : Free extents Free Blocks Percent
4K... 8K- : 4008 4008 0.08%
8K... 16K- : 1723 3992 0.08%
16K... 32K- : 703 3495 0.07%
32K... 64K- : 637 7400 0.15%
64K... 128K- : 1590 29273 0.61%
128K... 256K- : 4711 236839 4.95%
256K... 512K- : 2664 265691 5.56%
512K... 1024K- : 2359 434427 9.08%
1M... 2M- : 595 213173 4.46%
2M... 4M- : 75 49182 1.03%
64M... 128M- : 6 118890 2.49%
e4defrag：
[root@graphite-storage-01 ~]# e4defrag -c /dev/vda3
<Fragmented files> now/best size/ext
1. /opt/graphite/storage/graphite.db 17/1 4 KB
2. /var/log/cron 13/1 4 KB
3. /var/log/wtmp 16/1 4 KB
4. /root/.bash_history 4/1 4 KB
5. /var/lib/rpm/Sha1header 10/1 4 KB
Total/best extents 182256/159981
Average size per extent 183 KB
Fragmentation score 2
[0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
This device (/dev/vda3) does not need defragmentation.
Done.
iostat：
[root@graphite-storage-01 ~]# iostat -k -x 60 3
Linux 3.10.0-229.7.2.el7.x86_64 (graphite-storage-01) 07/05/2016 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
7.99 0.00 2.54 29.66 0.35 59.46
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 100.34 177.48 1808.94 2715.66 7659.19 10.45 0.26 0.13 0.65 0.08 0.23 46.14
avg-cpu: %user %nice %system %iowait %steal %idle
6.17 0.00 7.00 73.21 0.58 13.04
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 23.87 672.40 656.47 8729.87 2752.27 17.28 7.36 5.50 2.72 8.35 0.73 96.83
avg-cpu: %user %nice %system %iowait %steal %idle
7.06 0.00 7.31 73.03 0.59 12.01
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 42.68 677.67 614.88 8634.93 2647.53 17.46 6.66 5.15 2.72 7.83 0.74 96.08
df：
[root@graphite-storage-01 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda3 39153856 33689468 3822852 90% /
devtmpfs 1933092 0 1933092 0% /dev
tmpfs 1941380 0 1941380 0% /dev/shm
tmpfs 1941380 188700 1752680 10% /run
tmpfs 1941380 0 1941380 0% /sys/fs/cgroup
/dev/vda2 999320 2584 980352 1% /tmp
[root@graphite-storage-01 ~]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/vda3 2490368 239389 2250979 10% /
devtmpfs 483273 304 482969 1% /dev
tmpfs 485345 1 485344 1% /dev/shm
tmpfs 485345 322 485023 1% /run
tmpfs 485345 13 485332 1% /sys/fs/cgroup
/dev/vda2 65536 22 65514 1% /tmp
编辑：我已经调整了其中一个存储节点的大小，但没有效果。我还在cachestat[https://github.com/brendangregg/perf-tools性能工具集合）让我可以查看 VFS 缓存内部。此时，我似乎已经达到了存储可以提供的 IO 吞吐量的极限。
此时，我认为我要么继续扩展到更多的集群成员，要么寻找更具写入效率的时间序列存储解决方案。
示例输出来自cachestat：
storage-01 [resized disk]
HITS MISSES DIRTIES RATIO BUFFERS_MB CACHE_MB
9691 14566 7821 40.0% 160 2628
36181 14689 7802 71.1% 160 2631
8649 13617 7003 38.8% 159 2628
15567 13399 6857 53.7% 160 2627
9045 14002 7049 39.2% 160 2627
7533 12503 6153 37.6% 159 2620
storage-02 [not resized]
HITS MISSES DIRTIES RATIO BUFFERS_MB CACHE_MB
5097 11629 4740 30.5% 143 2365
5977 11045 4843 35.1% 142 2344
4356 10479 4199 29.4% 143 2364
6611 11188 4946 37.1% 143 2348
33734 14511 5930 69.9% 143 2347
7885 16353 7090 32.5% 143 2358
超晚编辑：此后，我们迁移到了另一个可以使用 SSD 的平台，虽然一段时间内情况还不错，但随着我们添加越来越多的指标，我们最终看到了性能的急剧下降。虽然我没有任何确凿的证据，但我相信这是 Carbon/Whisper 存储的工作方式与我们存储的大量指标之间的一个极端情况。
基本上，只要系统有足够的 RAM 来轻松地缓存 Whisper 文件以供读取，IO 几乎就是纯写入，一切都很顺利。但是，一旦 FS 缓存不足，Whisper 文件需要不断地从磁盘读取，这会占用您的 IO 带宽，一切都会开始变得糟糕。
答案1
听起来你正在运行 SSD，当它们装满时，性能可能会出现一些奇怪的特征。当使用率下降到 6/1 左右时，性能并没有恢复正常，这一事实证实了这一理论。
背后的原因相当复杂，但基本上可以归结为需要先清空已写入但当前未使用的闪存块，然后才能再次写入。看起来您正在进行非常繁重的写入，因此驱动器中运行的清空过程没有机会在一次性写入所有已清空的块后保持足够的供应。
不同型号的驱动器具有不同的控制器，并且可以使用不同数量的“备用”闪存块，而较大的驱动器显然在用完新位之前有更多的块要写入，因此几乎可以肯定，升级到更大的驱动器至少可以暂时“解决”您的问题。“企业”级驱动器在这方面往往表现更好，但较新的闪存控制器型号也是如此，因此，在没有可靠的第三方测试特定驱动器型号的情况下，使用模式与您自己的类似，这有点像掷骰子。
你也可以继续使用你现在的驱动器一段时间，如果你挥动类似的东西fstrim告诉驱动器“你绝对可以立即擦除所有这些块现在“，尽管在需要同时做其他事情的系统上执行此操作可能不会那么顺利（您需要注意fstrim手册页中的性能警告）。
至于您是否需要更多节点，我不能肯定地说，但我认为不需要。CPU 看起来没有失控，而且我怀疑您是否会在其他地方使 I/O 系统饱和。
答案2
从性能角度来看，Ext3/4 的利用率会超过 80-85%，这是众所周知的问题。这是由于碎片增加和写回性能降低造成的。
您能否提供两种iostat -k -x 60 3输出，一种是容量低于 80% 时，另一种是容量高于 80% 时？
编辑：从您的看来e2freefrag，似乎有足够的可用空间。您可以添加和/dev/vda3的输出吗？dfdf -i
无论如何，iostat结合您的图表（尤其是“磁盘 IOPS”），您的结果非常有趣。看来您的工作负载非常以写入为中心；当总发出 IOPS 的 95% 以上是写入时，您没有问题。但是，当您的性能下降时，您的磁盘开始提供一致的读取 IOPS。这种混合的读取/写入会破坏磁盘将多个较小的写入合并为较大的写入的能力（读取通常是阻塞操作），从而导致性能大大降低。
例如，让我们看看显示的第一个结果iostat：当总磁盘 IOPS 由写入主导时（如在这种情况下），和avgqu-sz都await非常低。
但是在第二次和第三次中，iostat我们看到更多的读取，这些读取是阻塞/停顿操作（参见列rrqm/s：它显示 0，因此在您的情况下无法合并任何读取），会破坏延迟（await）和吞吐量（KB/s）。
当主机用完 inode 缓存时，我见过类似的行为，这可能是由于存储的小文件数量太多造成的。要调整系统以优先使用 inode/dentry 缓存而牺牲数据缓存，请尝试发出echo 10 > /proc/sys/vm/vfs_cache_pressure并等待几分钟：这会改变什么吗？