RCHAR include READ_BYTES (proc/<pid>/io)?

Question

Ho letto proc/<pid>/io per misurare l'attività di I/O delle query SQL, dove <pid> è il PID del server del database. Ho letto i valori prima e dopo ogni query per calcolare la differenza e ottenere il numero di byte che la richiesta ha causato di essere letta e/o scritta.

Per quanto ne so il campo READ_BYTES conta effettiva del disco-IO, mentre RCHAR comprende più, come si legge che potrebbe essere soddisfatta dalla cache della pagina Linux (vedi Understanding the counters in /proc/[pid]/io per chiarimenti). Ciò porta a supporre che RCHAR debba avere un valore uguale o maggiore di READ_BYTES, ma i miei risultati contraddicono questa ipotesi.

potevo immaginare qualche blocco di minore o di una pagina in alto per i risultati che ottengo per Infobright ICE (i valori sono 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| 

Ma ho completamente non riescono a capire le IO-contatori per MonetDB (i valori sono 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| 

mi sbaglio con il presupposto che RCHAR include READ_BYTES? C'è un modo per ingannare i contatori dei kernel, che MonetDB potrebbe usare? Che cosa sta succedendo qui?

Potrei aggiungere che svuoto la cache della pagina e riavvio il server di database prima di ogni query. Sono su Ubuntu 11.10, con il kernel 3.0.0-15-generico.

Answer 1

posso solo pensare a due cose:

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. 

ho letto "ha causato essere prelevati dallo strato di archiviazione" per includere readahead, qualunque sia.

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) 

Si noti che questo non dice nulla circa "l'accesso al disco tramite file mappati in memoria". Penso che questa sia la ragione più probabile, e che il tuo MonetDB probabilmente estrae i suoi file di database e poi fa tutto su di essi.

Non sono sicuro di come sia possibile controllare la larghezza di banda utilizzata su mmap, a causa della sua natura.

Answer 2

Si può anche leggere file di codice sorgente del kernel di 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 */ 
};