linux – 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

编辑：我已经调整了一个存储节点的大小,但它没有效果.我还在[https://github.com/brendangregg/perf-tools](a perf工具集合]中找到了cachestat实用程序,它让我看一下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

超级晚编辑：我们已经迁移到另一个可以使用固态硬盘的平台,虽然事情好好一段时间,但我们最终看到了同样的性能急剧下降,因为我们添加了越来越多的指标.虽然我没有任何明确的证据,但我认为这是Carbon / Whisper存储如何工作以及我们存储的指标数量之间的一个极端情况.

基本上,只要系统有足够的RAM来舒适地缓存Whisper文件以进行读取,IO几乎是纯粹的写入,一切都很愉快.但是,一旦FS缓存饥饿设置进入,并且需要在磁盘上连续读取Whisper文件,这些磁盘会占用您的IO带宽并且所有内容都会开启.

解决方法

它背后的原因是相当复杂,但基本上归结为需要在再次写入之前删除写入但当前未使用的闪存块.看起来你写的非常难,所以驱动器中运行的消隐过程没有机会在它们全部写入一次后保持足够的空白块供应.

不同型号的驱动器具有不同的控制器,并且使用不同数量的“备用”闪存块,而较大的驱动器在用完新位之前显然有更多的块要写入,因此几乎可以肯定升级到更大的驱动器会“解决”给你的问题,至少是暂时的. “企业级”驱动器在这方面往往做得更好,但闪存控制器的新型号也是如此,所以这是一个小问题,因为在类似于使用模式的特定驱动器模型中缺乏可靠的第三方测试你自己.

你可能也可以使用你现在拥有的驱动器多一段时间,如果你挥动像fstrim这样的东西告诉驱动器“你现在肯定可以擦除所有这些块”,尽管在你需要在同一时间做其他事情的系统可能不会那么顺利(你需要注意fstrim联机帮助页中的性能警告).

至于你是否需要更多节点,我不能肯定地说,但我不这么认为. CPU看起来不会失控,我怀疑你是否会在其他地方使I / O系统饱和.

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!