我读取proc/<pid>/io来度量SQL查询的IO活动，其中<pid>是数据库服务器的PID。 我读取每个查询之前和之后的值来计算差异，并获取请求导致读取和/或写入的字节数。
据我所知，字段READ_BYTES计算实际的磁盘IO，而RCHAR包含更多，如linux页面caching可以满足的读取（请参阅理解/ proc / [pid] / io中的计数器以进行说明）。 这导致了一个假设， RCHAR应该得出一个等于或大于READ_BYTES的值，但是我的结果与这个假设相矛盾。
我可以想象一些小块或页面开销为Infobright ICE（值是MB）的结果：
Query RCHAR READ_BYTES tpch_q01.sql| 34.44180| 34.89453| tpch_q02.sql| 2.89191| 3.64453| tpch_q03.sql| 32.58994| 33.19531| tpch_q04.sql| 17.78325| 18.27344|
但是我完全无法理解MonetDB的IO计数器（值是MB）：
Query RCHAR READ_BYTES tpch_q01.sql| 0.07501| 220.58203| tpch_q02.sql| 1.37840| 18.16016| tpch_q03.sql| 0.08272| 162.38281| tpch_q04.sql| 0.06604| 83.25391|
我错误的假设， RCHAR包括READ_BYTES ？ 有没有办法欺骗内核计数器，MonetDB可以使用？ 这里发生了什么？
我可能会添加，我清除页面caching，并在每个查询之前重新启动数据库服务器。 我在Ubuntu 11.10上运行内核3.0.0-15-generic。
我只能想到两件事情：
1：
1446 read_bytes 1447 ---------- 1448 1449 I/O counter: bytes read 1450 Attempt to count the number of bytes which this process really did cause to 1451 be fetched from the storage layer.
我读了“引起从存储层中提取”，包括readahead，不管。
2：
1411 rchar 1412 ----- 1413 1414 I/O counter: chars read 1415 The number of bytes which this task has caused to be read from storage. This 1416 is simply the sum of bytes which this process passed to read() and pread(). 1417 It includes things like tty IO and it is unaffected by whether or not actual 1418 physical disk IO was required (the read might have been satisfied from 1419 pagecache)
请注意，这没有说“通过内存映射文件访问磁盘”。 我认为这是更有可能的原因，你的MonetDB可能映射出它的数据库文件，然后完成所有的事情。
我真的不知道如何检查mmap上使用的带宽，因为它的性质。
您还可以阅读Linux内核源代码文件： /include/linux/task_io_accounting.h
struct task_io_accounting { #ifdef CONFIG_TASK_XACCT /* bytes read */ u64 rchar; /* bytes written */ u64 wchar; /* # of read syscalls */ u64 syscr; /* # of write syscalls */ u64 syscw; #endif /* CONFIG_TASK_XACCT */ #ifdef CONFIG_TASK_IO_ACCOUNTING /* * The number of bytes which this task has caused to be read from * storage. */ u64 read_bytes; /* * The number of bytes which this task has caused, or shall cause to be * written to disk. */ u64 write_bytes; /* * A task can cause "negative" IO too. If this task truncates some * dirty pagecache, some IO which another task has been accounted for * (in its write_bytes) will not be happening. We _could_ just * subtract that from the truncating task's write_bytes, but there is * information loss in doing that. */ u64 cancelled_write_bytes; #endif /* CONFIG_TASK_IO_ACCOUNTING */ };