Sergei Obrastsovпри последовательном чтении массива кэш обновляется постоянноТопикстартер упомянул "100% CPU", а это как раз и говорит о [почти полном] отсутствии Disk I/O у данного процесса. В Cache, как известно, "много читателей - один писатель (демон записи)", поэтому дисковый I/O каждого процесса попадает именно в его статистику.
То, что процесс, активно что-то обрабатывающий и берущий почти все данные из кэша, может стать настоящей бедой для интерактивных польз-лей Каше, в общем-то, давно известно. Происходит это потому, что при конкуренции за LRU-кэш у такого процесса всегда есть преимущество. Панацеи от этого нет, но можно:
- не иметь таких процессов больше, чем (Nядер - m), где m определяется экспериментально :)
- переходить в Linux, где весь File Disk I/O кэшируется еще и Linux'ом; в сложных случаях наличие такого "вторичного кэша" может оказаться благом;
- кстати, в Linux'е хорошо видно, что у batch-процесса Cache nice value всего-навсего 2. Т.е. приоритет normal = 19, а low = 17. Можно попробовать запускать фоновые процессы внешним вызовом nice с бОльшими значениями nice value.