Czy RCHAR obejmuje READ_BYTES (proc/<pid>/io)?

Question

Czytam proc/<pid>/io, aby zmierzyć aktywność IO zapytań SQL, gdzie <pid> jest identyfikatorem PID serwera bazy danych. Odczytuję wartości przed i po każdym zapytaniu, aby obliczyć różnicę i uzyskać liczbę bajtów, przez które żądanie zostało przeczytane i/lub zapisane.

O ile wiem dziedzinie READ_BYTES liczby rzeczywiste disk-IO, podczas RCHAR zawiera więcej, jak czytamy, które mogą być zaspokojone przez cache widoku Linux (patrz Understanding the counters in /proc/[pid]/io dla wyjaśnienia). To prowadzi do założenia, że ​​RCHAR powinien wymyślić wartość równą lub większą niż READ_BYTES, ale moje wyniki są sprzeczne z tym założeniem.

mogę sobie wyobrazić jakiś niewielki blok lub strona obciążenie dla wyników dostaję za Infobright WKP (wartości 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| 

Ale zupełnie nie rozumiem IO-liczniki dla MonetDB (wartości 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| 

mylę przy założeniu, że RCHAR obejmuje READ_BYTES? Czy istnieje sposób na oszukanie liczników jądra, z których może korzystać MonetDB? Co tu się dzieje?

Mogę dodać, że wyczyszczę pamięć podręczną strony i zrestartuj serwer bazy danych przed każdym zapytaniem. Jestem na Ubuntu 11.10, z jądrem 3.0.0-15-generic.

Answer 1

mogę myśleć tylko o dwóch rzeczach:

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. 

czytam "wyrządzone zostać pobrane z warstwy pamięci" obejmuje readahead, cokolwiek.

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) 

Zauważ, że to nic nie mówi o "dostęp do dysku poprzez Zmapowane plików". Myślę, że jest to bardziej prawdopodobny powód, i że Twój MonetDB prawdopodobnie pomija pliki bazy danych, a następnie robi wszystko na nich.

Nie jestem pewien, jak można sprawdzić używaną przepustowość na mmap, ze względu na jej charakter.

Answer 2

Można również czytać plik Linux kod źródłowy jądra: /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 */ 
};