linux下ext4代码,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

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带宽并且所有内容都会开启.