Ext4 使用和性能

Question

我有一组运行 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 带宽，并且一切都开始变坏。

Answer 1

听起来您正在运行 SSD，当它们变满时，它可能具有一些时髦的性能特征。当使用率下降到 6/1 左右时，性能没有恢复正常，这一事实强化了这一理论。

其背后的原因相当复杂，但基本上归结为需要在再次写入之前清除已写入但当前未使用的闪存块。看起来你写得很辛苦，所以一旦它们全部写入一次，驱动器中运行的消隐过程就没有机会保持足够的消隐块供应。

不同型号的驱动器有不同的控制器，使用不同数量的“备用”闪存块，更大的驱动器在用完新位之前显然有更多的块要写入，所以几乎可以肯定升级到更大的驱动器会“解决”你的问题，至少是暂时的。“企业”级驱动器在这方面往往做得更好，但较新型号的闪存控制器也是如此，因此在缺乏对特定驱动器型号的可靠第三方测试的情况下，这有点像废话你自己。

您可能还能够逃脱使用你的硬盘现在一些时间，如果你挥手喜欢的事，fstrim在他们告诉驱动“你一定可以消灭所有这些块权，现在”，但这样做的系统上您需要同时做其他事情可能不会那么顺利（您需要注意fstrim联机帮助页中的性能警告）。

至于是否需要更多节点，我不能肯定，但我不这么认为。CPU 看起来并没有失控，我怀疑您是否会使其他地方的 I/O 系统饱和。