该集群目前包括：
> 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系统饱和.
