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

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

Насколько я знаю, поле READ_BYTES подсчитывает фактический дисковый ввод-вывод, а RCHAR включает в себя больше, например чтение, которое может быть выполнено кешем страниц linux (см. Понимание счетчиков в /proc/[pid]/io для уточнения). Это приводит к предположению, что RCHAR должно иметь значение, равное или большее, чем READ_BYTES, но мои результаты противоречат этому предположению.

Я мог бы представить себе некоторые незначительные накладные расходы на блок или страницу для результатов, которые я получаю для Infobright ICE (значения указаны в МБ):

        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 (значения МБ):

        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.


linux linux-kernel io monetdb procfs
person lupz    schedule 17.05.2012    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

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.

Я прочитал «Вызвано получением из уровня хранилища», чтобы включить опережающее чтение, что угодно.

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 из-за ее природы.

person zebediah49    schedule 20.05.2012
comment
Спасибо. Действительно, в документах по архитектуре MonetDB говорится, что они используют файлы с отображением памяти. - person lupz; 21.05.2012

arrow_upward
0
arrow_downward

Вы также можете прочитать исходный код ядра 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 */
};
person Duke    schedule 23.05.2014