Ext4的用法和性能

我有一堆运行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]（一些perf工具的集合）中找到了该实用程序，该实用程序让我了解了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带宽，并且一切都会开始运转。

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

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

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

您可能还能够逃脱使用你的硬盘现在一些时间，如果你挥手喜欢的事，fstrim在他们告诉驱动“你一定可以消灭所有这些块权，现在 ”，但这样做的系统上您需要同时执行其他操作可能无法正常运行（您需要在fstrim联机帮助页中很好地注意性能警告）。

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

从性能的角度来看，Ext3 / 4的利用率超过80-85％是众所周知的。这是由于增加了碎片并降低了回写性能。

您能否提供两种iostat -k -x 60 3输出，一种是容量不足80％时输出，另一种是容量超过80％时输出？

编辑：从您e2freefrag看来，它/dev/vda3有足够的可用空间。您可以添加的输出df和df -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并等待几分钟：它会更改任何内容吗？