diskstats的数字突然变得难以置信？

我有一个带有两个Intel DC S3610 SSD的Debian jessie服务器，采用RAID-10。对于IO来说这是相当繁忙的，在过去的几个星期里，我一直在描绘IOPS：

sda的磁盘IO交易图

正如你所看到的那样，大部分时间，大约5K的平均读取操作高达5.5K左右，直到星期五午夜UTC突然停止，读取操作几乎没有任何变化。

我其实只是追溯注意到这一点，因为事情是，服务器仍然是应该的。也就是说，我相信这是破坏的监控，而不是安装程序可以执行的IOPS数量。如果实际的IOPS已经下降到所显示的水平，我会知道，因为一切都会非常明显地中断。

在进一步的调查中，千字节读/写图也在同一点上被打破。请求延迟图是好的，但。

为了排除这里使用的特定graphics解决scheme（cacti和SNMP），我看了一下iostat 。其输出与图表上显示的内容相匹配。

据我所知， iostat从/ proc / diskstats获取信息。根据https://www.kernel.org/doc/Documentation/iostats.txt ，将会有主要的，次要的设备名称，然后是一组字段，其中第一个是已完成的读取次数。所以：

$ for i in {1..10}; do awk '/sda / { print $4 }' /proc/diskstats; sleep 1; done 3752035479 3752035484 3752035484 3752035486 3752035486 3752035519 3752035594 3752035631 3752036016 3752036374

如此less的读取在10秒的时间内完成是不可信的。

但如果/ proc / diskstats对我说谎，那么问题是什么，我希望如何解决它？

另外值得注意的是，无论什么改变，恰恰在午夜时改变，这是一个巧合。

服务器有相当多的块设备。其中有187个是LVM LV，另外18个是通常的分区和MD设备。

我经常增加更多的LV，所以有可能在星期四我达到了一些限制，虽然在午夜附近我没有添加任何东西，所以在午夜出了什么问题还是很奇怪的。

我知道/ proc / diskstats可以溢出，但是当数字通常是错误的巨大的。

看看这张图有点难，我们可以看到，星期四看起来比之前的一周（和几周）更尖锐。放大那个时期的结果我们看到：

IOPS图，sda，重点在周四

那些零或接近于零的差距是不正常的，我不相信它们反映了现实。也许请求的数量已经超过了一些门槛，因为我增加了更多的负载，使得它在星期四开始出现，到了星期五大部分的读数现在为零。

有没有人对这里发生了什么有什么想法？

内核版本3.16.7-ckt11-1 + deb8u3。