RCHAR READ_BYTES (proc/<pid>/io) içerir mi?

Question

<pid> veritabanı sunucusunun PID'si olan SQL sorgularının IO etkinliğini ölçmek için proc/<pid>/io okunuyorum. Farkı hesaplamak için her sorgudan önceki ve sonraki değerleri okurum ve okunan ve/veya yazılan sebeplerden dolayı bayt sayısını alırım. Bu linux sayfa cache suretiyle yerine getirilebileceğini okur gibi RCHAR, daha fazlasını içerir iken

Ben sahadan READ_BYTES sayımları gerçek disk IO bildiği gibi kadarıyla, (açıklama için Understanding the counters in /proc/[pid]/io bakınız). Bu, RCHAR'un READ_BYTES değerine eşit veya daha büyük bir değerle gelmesi gerektiği varsayımına yol açar, ancak sonuçlarım bu varsayımla çelişir.

Ben (değerler MB vardır) Ben Infobright ICE olsun sonuçlar için bazı küçük blok veya sayfa yükünü düşünebiliriz

:

 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| 

Ama ben tamamen (değerler MB vardır) MonetDB için IO-sayaçlarını anlamak için başarısız :

 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| 

Am RCHARREAD_BYTES içerir varsayımıyla yanlış? MonetDB'nin kullanabileceği çekirdek sayaçlarını kandırmanın bir yolu var mı? Burada neler oluyor?

Sayfa önbelleğini temizlediğimi ve her sorgudan önce veritabanı sunucusunu yeniden başlattığımı ekleyebilirim. Ubuntu 11.10'dayım, kernel 3.0.0-15-jenerik çalıştırıyorum.

Answer 1

Sadece iki şey düşünebilirsiniz:

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

1:

Okuduğum

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. 

, her neyse readAhead içerecek şekilde "depolama katmanından getirilecek neden oldu".

2: Bu "bellek dosyalarını eşlenen aracılığıyla disk erişim" hakkında hiçbir şey söylüyor

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) 

Not. Bunun daha olası bir neden olduğunu düşünüyorum ve MonetDB'niz muhtemelen veritabanı dosyalarını elden geçiriyor ve sonra her şeyi yapıyor.

Doğası gereği, kullanılan bant genişliğini mmap'te nasıl kontrol edebileceğinizden emin değilim.

Answer 2

Ayrıca Linux çekirdek kaynak kodu dosyası okuyabilir: /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 */ 
};