Enthält RCHAR READ_BYTES (proc/<pid>/io)?

Question

Ich lese proc/<pid>/io, um die IO-Aktivität von SQL-Abfragen zu messen, wobei <pid> die PID des Datenbankservers ist. Ich lese die Werte vor und nach jeder Abfrage, um die Differenz zu berechnen und die Anzahl der Bytes zu ermitteln, die die Anforderung zum Lesen und/oder Schreiben veranlaßt hat.

Soweit ich das Feld READ_BYTES zählt tatsächlicher Disk-IO wissen, während RCHAR mehr enthält, wie liest, dass die Linux-Seiten-Cache befriedigt werden kann (siehe Understanding the counters in /proc/[pid]/io zur Klärung). Dies führt zu der Annahme, dass RCHAR sollte mit einem Wert gleich oder größer als READ_BYTES kommen, aber meine Ergebnisse widersprechen dieser Annahme.

Ich konnte einige kleinere Block oder Seite Aufwand für Ergebnisse, die ich für Infobright ICE (Werte MB) erhalten vorstellen:

 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| 

Aber ich völlig versagen die IO-Zähler für MonetDB (Werte MB) zu verstehen, :

 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| 

Bin ich mit der Annahme falsch, dass RCHARREAD_BYTES enthält? Gibt es eine Möglichkeit, die Kernel-Zähler auszutricksen, die MonetDB benutzen könnte? Was geht hier vor sich?

Ich könnte hinzufügen, dass ich den Seitencache löschen und den Datenbankserver vor jeder Abfrage neu starten. Ich bin auf Ubuntu 11.10, mit Kernel 3.0.0-15-generic.

Answer 1

Ich kann nur an zwei Dinge:

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. 

I "verursacht werden, geholt von der Speicherschicht" schließen readahead lesen, was auch immer.

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) 

Beachten Sie, dass dies sagt nichts über "Plattenzugriff über Speicherdateien abgebildet". Ich denke, das ist der wahrscheinlichere Grund, und dass Ihre MonetDB wahrscheinlich ihre Datenbankdateien ausgibt und dann alles auf ihnen macht.

Ich bin nicht wirklich sicher, wie Sie die verwendete Bandbreite auf mmap überprüfen konnten, wegen seiner Natur.

Answer 2

Sie können auch Linux-Kernel-Quellcode-Datei lesen: /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 */ 
};