Включает ли RCHAR READ_BYTES (proc/<pid>/io)?

Question

Я читал proc/<pid>/io для измерения IO-активности SQL-запросов, где <pid> является PID сервера базы данных. Я читал значения до и после каждого запроса, чтобы вычислить разницу и получить количество байтов, которые запрос получил, чтобы читать и/или записывать.

Насколько я знаю, поле READ_BYTES рассчитывает фактические дискового ввода-вывода, в то время как RCHAR включает в себя больше, как говорится, что может быть удовлетворен кэшем линукс страницы (см Understanding the counters in /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| 

Но я совершенно не понимаю IO-счетчик для MonetDB (значения 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? Что здесь происходит?

Я могу добавить, что я очищаю кэш страницы и перезапускаю сервер базы данных перед каждым запросом. Я на Ubuntu 11.10, запущен ядро ​​3.0.0-15-generic.

Answer 1

я могу думать только о двух вещах:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/proc.txt;hb=HEAD#l1305

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 по своей природе.

Answer 2

Вы также можете прочитать 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 */ 
};