这是我的来自不同的应用程序机器的avgqu-sz的图表 :
应用程序在内存中caching数据,每隔n分钟将数据刷新到文件系统+每隔m分钟从内存中的文件系统加载数据(重新加载)。 这是尖峰的原因。 在这些峰值期间阻止设备使用率为80-95%。
问:我需要担心我的磁盘性能吗? 如何解释这个图 – 是好还是不好? 我需要优化一些东西吗?
是的,我知道avggu-sz是什么意思意味着你知道一般的数据stream这样
app --> bio layer --> I/O Scheduler --> Driver --> Disks nr_requests queue_depth
这只是一个概括性的概述,并不包含所有内容。只要nr_requests仍然是queue_Depth,I / O就会很快通过。当这些请求超过队列深度并且I / O开始在调度器层保存时,就会出现问题。
看看你的图表,我会强烈build议1:检查高峰的磁盘2:尝试改变nr_requests和queue_depth的值,看看是否有帮助3:改变testing环境中的调度器(因为你的数据不包含合并请求(读/写)..所以我不能评论)
/sys/block/<your disk drive sda,sdb...>/queue/nr_requests (io scheduler) /sys/block/<your disk drive sda,sdb...>/device/queue_depth (driver)
平均队列大小超过1,000个请求是麻烦的,除非您正在运行数百个磁盘作为单个设备公开的arrays。
然而,从图表来看,我认为大部分的峰值都是测量或者是图表 – 你的数据看起来像是以5分钟的时间间隔收集的,然而尖峰的宽度基本上都是零 – 非常不寻常。 你应该看看由sar收集的原始数据或由iostat近实时显示的原始数据来排除。 如果仍然看到队列大小超过每个主轴使用30个请求,请在这里查看数据。