语境:我正在编写一个脚本,用于根据过去 2 分钟的 atop 历史记录计算服务的 I/O 使用情况(其中 atop 的采样配置为每 1 分钟一次)。我使用以下命令生成历史文件:
atop -P DSK,PRD -b [time] -e [time] -r > somefile_to_read_from
我正在使用 的atop
可解析输出选项 ( -P
) 以及标签DSK
和PRD
。
从atop
的手册页来看,它是这样说的DSK
:
对于每个逻辑卷/多个设备/硬盘,显示一行。后续字段:名称、I/O 花费的毫秒数、发出的读取数,为读取而传输的扇区数,发出的写入次数,以及传输写入的扇区数。
虽然PRD
它说:
对于每个进程显示一行。后续字段:PID、名称(括号之间)、状态、已安装的过时内核补丁('n')、使用的标准 io 统计信息('y' 或 'n')、磁盘读取次数, 累计读取扇区数,磁盘写入次数、累计写入扇区数、取消写入扇区数、TGID(相关任务/线程组数)和 is_process (y/n)。
我以为它们是同一件事。然而,我几乎总是得到高于 100% 的 I/O 使用率值(例如,在运行ab
apache 时)。我认为这将是我的编程逻辑和算法的问题,但是,我把头撞在墙上好几个小时,无法想到我可能犯的错误,尝试了很多不同的方法来计算它,仍然得到相同的结果。
然后我打开并开始读取我在过滤后逐行生成的历史文件,以仅向我显示我所监控的具有此类 I/O 使用情况的进程(在本例中为 apache,因为我对其运行了基准测试)。我注意到一些事情,那就是事实,那DSK
就是发出的写入次数远低于所有 apachePRD
线路的总和'磁盘写入次数。
我不确定我是否理解错误或者我做错了什么。历史文件太大而无法显示,但是,如果需要,我可以将其上传到诸如pastebin之类的东西。
我的问题是,什么DSK
是发出的写入/读取数量参考一下,不是和PRD
's一样吗磁盘上的读/写次数?如果不是,那么使用 atop 的历史记录来计算单个进程的 I/O 使用情况的方法是什么?
答案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% 准确,因为(据我所知)无法确定逻辑请求的组合方式。
答案2
我可能是绝对错误的,但这可能与文件系统 IO 缓冲以及驱动器扇区大小和 IO 大小有关。例如,如果磁盘块大小为 512 字节并且应用程序正在写入 1024 字节,则 1 个应用程序 IO 等于驱动器上的 2 个 IO。现在想象一下,在应用程序和驱动器之间至少有一个文件系统和一个卷管理器,并且它们都可能有自己的块大小。
答案3
我认为你的结果是正确的,并且是高效磁盘 IO 的结果。在一个回写(堆栈溢出)在直写系统中,发出的写入次数应小于对磁盘的实际写入次数,而在直写系统中,发出的写入次数之和应等于对磁盘的写入次数,因为没有写组合(维基百科)。
从网络百科全书:
回写式缓存比直写式缓存具有更好的性能,因为它减少了对主内存的写入操作数量。随着性能的提高,系统崩溃时可能会带来数据丢失的轻微风险。
因此,atop 的 DSK 标签对于回写系统中发生的实际磁盘 IO 更具代表性。
对于每个进程 io这个服务器故障问题可能有帮助。
这个华为论坛帖子很好地描述了直写与回写,假设这就是影响您输出的因素。