Почему чтение диска чаще делает каждое чтение быстрее в Linux?QPS1 против 50

Question

Я тестировал производительность синхронного чтения на Linux-коробке с диском SATA. При чтении из одного потока странно то, что более высокий QPS (50) дал среднее время чтения 12 мс после чтения 300 записей, в то время как более низкий QPS (1) дал 63 мс после чтения тех же 300 записей. Есть ли какое-то объяснение?

Код и данные следующие:

struct Request{
    unsigned long long len;
    unsigned long long offset;
    int                fd;
};

int read_request(Request* request){
    char* buf = (char*)malloc(request->len);
    off_t of = lseek(request->fd,request->offset,SEEK_SET);
    assert(of == request->offset);

    int len = read(request->fd,buf,request->len);
    assert(len == request->len);
    free(buf);
    return 0;
}




 int read_with_qps(Request* request,int request_num,Files* f,int mode,int qps){

    int interval = 1000 / qps;
    struct timeval start,end;
    for(int i  = 0 ; i < request_num ; i++){
        gettimeofday(&start,NULL);
        int ret = read_request(&request[i]);
        gettimeofday(&end,NULL);
        int time_used = (end.tv_sec - start.tv_sec) * 1000 + (end.tv_usec - start.tv_usec)/1000;
        fprintf(stderr,"%lld,offset=%lld,len=%lld, read time:%d,ret=%d,mode=%d\n",
                end.tv_sec,request[i].offset,request[i].len,time_used,ret,mode);
        if(time_used < interval){
            usleep((interval - time_used) * 1000);
        }
    }
    return 0;
}

При QPS = 50 выборка выходных данных выглядит следующим образом (игнорируется время <4 мс, которое считается попаданием в кэш страницы при расчете среднего времени): </p>

1332233329,offset=1052299215,len=13186, read time:13,ret=0,mode=1
1332233329,offset=2319646140,len=1612, read time:10,ret=0,mode=1
1332233330,offset=1319250005,len=5654, read time:12,ret=0,mode=1
1332233330,offset=2520376009,len=2676, read time:12,ret=0,mode=1
1332233330,offset=2197548522,len=17236, read time:10,ret=0,mode=1
1332233330,offset=1363242083,len=13734, read time:11,ret=0,mode=1
1332233330,offset=4242210521,len=2003, read time:17,ret=0,mode=1
1332233330,offset=1666337117,len=2207, read time:10,ret=0,mode=1
1332233330,offset=797722662,len=5480, read time:18,ret=0,mode=1
1332233330,offset=1129310678,len=2265, read time:10,ret=0,mode=1

QPS = 1, тот же экстракт smaple:

1332300410,offset=1052299215,len=13186, read time:19,ret=0,mode=1
1332300411,offset=2319646140,len=1612, read time:40,ret=0,mode=1
1332300412,offset=1319250005,len=5654, read time:141,ret=0,mode=1
1332300413,offset=2520376009,len=2676, read time:15,ret=0,mode=1
1332300414,offset=2197548522,len=17236, read time:21,ret=0,mode=1
1332300415,offset=1363242083,len=13734, read time:13,ret=0,mode=1
1332300416,offset=4242210521,len=2003, read time:43,ret=0,mode=1
1332300417,offset=1666337117,len=2207, read time:18,ret=0,mode=1
1332300418,offset=797722662,len=5480, read time:67,ret=0,mode=1
1332300419,offset=1129310678,len=2265, read time:12,ret=0,mode=1

версия ядра: 2.6.18-194.el5 SMP x86_64

$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

Спасибо за ответ

Answer 1

blktrace может сказать вам наверняка, но, возможно, это связано с подключением .Короче говоря, запросы ввода-вывода могут быть немного задержаны перед отправкой на диски, что полезно, когда поступает много запросов и их можно объединить, но не так сильно.

Answer 2

Когда вы отправляете несколько запросов, микропрограмма привода может поставить их в очередь и выполнить их в оптимизированной последовательности, основанной на положении вращения и положении головки («поиск лифта»), чтобы не пришлось ждать времени полного поиска или время вращения диска для каждого запроса ввода / вывода.

Если вы выполняете одни и те же запросы медленно, такого преимущества нет.