lup*_*upz 5 linux io monetdb linux-kernel procfs
我读过proc/<pid>/io
来测量SQL查询的IO活动,其中<pid>
是数据库服务器的PID.我读取每个查询之前和之后的值以计算差异并获得请求被读取和/或写入的字节数.
据我所知,该字段READ_BYTES
计算实际的磁盘IO,同时RCHAR
包含更多内容,例如linux页面缓存可以满足的读取(请参阅了解/ 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|
Run Code Online (Sandbox Code Playgroud)
但我完全不理解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|
Run Code Online (Sandbox Code Playgroud)
我错误的假设RCHAR
包括READ_BYTES
?有没有办法欺骗内核计数器,MonetDB可以使用?这里发生了什么?
我可能会补充一点,我清除页面缓存并在每次查询之前重新启动数据库服务器.我在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.
Run Code Online (Sandbox Code Playgroud)
我读到“导致从存储层获取”以包括预读,等等。
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)
Run Code Online (Sandbox Code Playgroud)
请注意,这没有提到“通过内存映射文件进行磁盘访问”。我认为这是更可能的原因,您的 MonetDB 可能会映射出其数据库文件,然后对它们执行所有操作。
由于其性质,我不太确定如何检查 mmap 上使用的带宽。
归档时间: |
|
查看次数: |
2061 次 |
最近记录: |