在atop的DSK标签中“写/读发布”指的是什么？

Question

上下文:我正在编写一个脚本，在最后2分钟内从顶层历史记录中计算服务的I/O使用情况(在这里，atop的采样被配置为每1分钟)。我使用以下命令生成历史文件：

atop -P DSK,PRD -b [time] -e [time] -r > somefile_to_read_from

我使用的是atop的S可解析输出选项(-P)和标签DSK和PRD。

从atop的S手册页面上，可以看到关于DSK的如下内容：

对于每个逻辑卷/多个设备/硬盘，显示一行。后续字段:名称、用于I/O的毫秒数、已发出的读取数、为读取传递的扇区数、已发出的写入数和为写入而传输的扇区数。

而对于PRD，它说：

对于每一个进程，都显示一行。后续字段: PID、名称(括号内)、状态、已过时的已安装内核修补程序('n')、使用的标准io统计信息('y‘或'n')、磁盘上读取的次数、读取扇区的累积数、写入的扇区的累积数、写入扇区的累加数、取消的写入扇区数、TGID (相关任务/线程的组号)和is_process (y/n)。

我以为他们也是一样的。但是，对于I/O的使用，我几乎总是得到100%以上的值(例如，在为apache运行ab时)。我认为这将是一个来自我的编程逻辑和算法的问题，然而，我把头撞了好几个小时，想不出我可能犯的一个错误，尝试了很多不同的方法来计算它，仍然得到了相同的结果。

于是，我打开并开始读取我逐行生成的历史文件，对其进行过滤，只向我展示了我所监视的进程，以实现这样的I/O使用(在本例中，apache，因为我在它上运行了基准测试)。我注意到了一个事实，那就是，DSK's发出的写的数字比磁盘上所有apache的PRD行数之和要低得多。

我不确定我是否理解错了什么或者我做错了什么。历史文件太大，无法显示，但是，如果需要的话，我可以将它上传到类似pastebin的地方。

我的问题是，DSK发布的S写/读数字指的是什么，是不是与PRD's在磁盘上的读写次数相同?如果不是，使用atop的历史来计算单个进程的I/O使用量的方法是什么？

Answer 1

首先，我的man atop说：

计数器“磁盘上的读取数”和“磁盘上的写入数”无论如何都过时了。

版本:2.3.0-2017/03/25 09:59:59

来自man iostat：

传输是对设备的I/O请求。多个逻辑请求可以组合成对设备的I/O请求。

我认为这解释了为什么进程I/O的总和超过了来自DSK的值。

因此，准确地使用单个进程的I/O将是process_io / sum_of_all_process_io。这并不是100%的精确性，因为没有办法(据我所知)确定逻辑请求是如何准确地组合在一起的。

Answer 2

我可能完全错了，但这可能与文件系统IO缓冲以及驱动器扇区大小和IO大小有关。例如，如果磁盘块大小为512字节，而应用程序正在写入1024字节，那么驱动器上的1个应用程序IO等于2个IOs。现在想象一下，在应用程序和驱动器之间，至少有一个文件系统和一个卷管理器，它们可能都有自己的块大小。

Answer 3

我认为您的结果是正确的，并且是高效磁盘IO的结果。在回写(堆叠溢出)系统中，发出的写入数应该小于对磁盘的实际写入数，而在写入系统中，由于没有写作组合(维基百科)，发出的写入量的总和应该等于对磁盘的写入数。

来自网络百科：

写回缓存产生的性能要比直接缓存要好一些，因为它减少了对主内存的写操作。随着性能的提高，如果系统崩溃，数据可能丢失的风险很小。

正因为如此，atop的DSK标签对于在写回系统中发生的实际磁盘IO来说是一个更有代表性的值。

对于每一个进程，io 这个服务器故障问题可能会有所帮助。

这条华为论坛的帖子很好地描述了写通对的回写.，假设这是影响您的输出的因素。