服务器 Gind.cn
  1. 服务器 Gind.cn
  3. Ext4的使用和性能
Intereting Posts
为什么我的CUPS调度程序重复重新启动？ 确定集线器上的端口是否正常工作的合理testing Windows Server 2008的索引服务的新属性 – 在哪里放置registry项 便携式脚本语言为多服务器pipe理员？ / etc / fstab文件系统标记为“错误”的位置在哪里？继续设置？ 性能：Nginx的SSL缓慢或只是在一般的SSL缓慢？ UWSGI –cheap和–idle模式 – 预期的行为 最好的服务器监控客户端与Raid监控 光纤通道SAN RAID速度较慢（DS4100） 通配符子域支持的Apache vhostconfiguration 什么是有条件的货运代理 cisco 2911 / k9 pptp服务器限制客户端 哪个是跨Windows SMB共享使用二进制增量复制档案的最可靠手段？ 木偶升级微软在Windows上 Windows 2012R2，Ubuntu 14.04 LTS，需要20分钟才能完成“停止”状态

Ext4的使用和性能

我有一堆运行Carbon和Graphite的机器，我需要扩展以获得更多存储空间，但是我不确定是否需要扩展或扩展。

该集群目前包括：

  • 1中继节点：接收所有指标并转发到相关的存储节点
  • 6个存储节点：包含所有的Whisper DB文件

问题是，当磁盘在80％的使用率附近时，性能从悬崖上掉下来。 集群写入IOPS从接近常数13k下降到更为混乱的7k左右，IOwait时间平均达到54％。

我已经看了我们的configuration回购，并且从四月初以来没有变化，所以这不是configuration更改的结果。

问题：增加磁盘大小是否会使IO性能得到控制，还是需要添加更多的存储节点？

注意：这里没有固态硬盘，只有很多很多的主轴。

相关图表：

磁盘使用情况 IOPS 中央处理器 碳缓存 指标每秒

统计和东西：

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/sr/sw/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/sr/sw/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/sr/sw/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] （一个perf工具的集合）中find了cachestat工具，让我看看VFScaching里面的内容。 在这一点上，看起来我已经达到了我的存储可以提供的IO吞吐量的限制。

在这一点上，我认为我不得不继续扩展到更多的集群成员，或者看看如何find一个更具写入效率的时间序列存储解决scheme。

cachestat输出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

听起来就像你正在运行固态硬盘，当它们满载时，可能会有一些时髦的性能特点。 当用量下降到6/1左右时，performance并没有恢复正常，这就强化了这一理论。

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

不同型号的驱动器有不同的控制器，不同数量的“备用”闪存块使用，而更大的驱动器明显有更多的块写入之前，他们用完新鲜的比特，所以几乎可以肯定，升级到较大的驱动器将“解决”这个问题对你来说，至less是暂时的。 在这方面，“企业级”驱动器往往做得更好，但闪存控制器的更新型号也是如此，因此，在缺less可靠的第三方testing的特定驱动器模型的情况下，你自己。

你也可以放弃使用现在的驱动器多一些时间，如果你挥动fstrim来告诉驱动器“你现在可以清除所有这些块”，尽pipe在你需要同时做其他事情的系统可能不会那么好（你会想要在fstrim页中注意性能警告）。

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

从性能的angular度来看，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）。

当主机用完inodecaching时，我看到了类似的行为，可能是由于存储的小文件数量太多。 要调整你的系统，以牺牲数据caching为代价来echo 10 > /proc/sys/vm/vfs_cache_pressure使用inode / dentrycaching，请尝试发出echo 10 > /proc/sys/vm/vfs_cache_pressure并等待几分钟：它是否改变了什么？