Interpretando leitura, escrita e tempo total de IO em / proc / diskstats

Question

Tenho notado que, quando vejo a saída de /proc/diskstats , há uma discrepância entre o tempo total gasto na leitura, o tempo total gasto com a gravação e o tempo total de execução do pedido de veiculação. Por exemplo, vi uma entrada em /proc/diskstats que era:

$ cat /proc/diskstats
...
8       0 sda 944150584 590524 235547588959 780672196 833280352 534699043 322507689696 3472000824 1 812190100 4246357772
...

De acordo com a documentação no link ,

Field 4 -- # of milliseconds spent reading This is the total number of milliseconds spent by all reads (as measured from __make_request() to end_that_request_last()).

Field 8 -- # of milliseconds spent writing This is the total number of milliseconds spent by all writes (as measured from __make_request() to end_that_request_last()).

Field 10 -- # of milliseconds spent doing I/Os This field increases so long as field 9 is nonzero.

Consequentemente, eu esperaria que o décimo campo fosse a soma do quarto e oito campos, como eu esperaria que o tempo total de IO fosse a soma do tempo gasto lendo e o tempo gasto escrevendo. No entanto, eu nunca notei que este é o caso, e o que é mais eu sempre observei a soma do quarto e oitavo campos para ser maior que o décimo (por exemplo, na linha acima (780672196 + 3472000824 - 812190100 = Eu estava me perguntando se alguém poderia explicar por que esses números são diferentes, parece que o décimo campo está tentando capturar algo diferente da soma do quarto e do oitavo campos.

    

Answer 1

Eu não olhei para o código-fonte, mas parece que a diferença decorre de dois modos de contabilidade diferentes.

Os campos # 4 e # 8 somam o tempo que cada um solicita para concluir. Isso significa que as solicitações emitidas paralelamente ainda contribuem para aumentar a contagem.

O campo nº 10 conta apenas o tempo real em que a fila e os discos estavam ocupados, por isso eles contam solicitações feitas em paralelo como uma única.

Deixe-me fazer um exemplo prático. Em /boot partition, eu dd a ~ 4 MB. Dê uma olhada nas estatísticas:

[root@localhost boot]# cat /proc/diskstats | grep sda1
   8       1 sda1 46256 0 255703 19332 2063 0 4162 538 0 11207 19862
[root@localhost boot]# dd if=initramfs-0-rescue-7dc32e3935ba4ce1ae50a0a8170e4480.img of=/dev/null
84099+1 records in
84099+1 records out
43058701 bytes (43 MB) copied, 0.347783 s, 124 MB/s
[root@localhost boot]# cat /proc/diskstats | grep sda1
   8       1 sda1 46342 0 339807 23011 2063 0 4162 538 0 11551 23540
[root@localhost boot]#

A leitura do arquivo exigiu ~ 0.35s ou ~ 350ms. No entanto, o contador # 4 e # 10 reagem de maneira muito diferente: o primeiro aumento em cerca de 4000, enquanto o segundo apenas em cerca de 350. É fácil ver qual tem o valor "correto": é o campo # 10, como sabemos dd que toda a operação demorou cerca de 350ms e o campo # 10 aumentou este mesmo valor.

Então, por que o campo nº 4 aumentou tanto e o que ele realmente mede?

Primeiro, vamos entender o que está acontecendo no nível da solicitação. dd usa, por padrão, 512B solicitações, mas o pagecache linux funciona com uma granularidade de 4KB, portanto, devemos esperar cerca de 1000 x 4KB solicitações. Esses 1000 pedidos são colocados em uma fila e emitidos, um por um (para simplificar, vamos fingir que o NCQ não existe) e enviados para o disco. Como os discos mecânicos são muito bons em leituras seqüenciais, eles geralmente usam uma política de leitura antecipada - isto é, lêem mais dados do que o necessário. Isso significa que, após a conclusão da primeira solicitação 4K, todas as outras solicitações subsequentes serão atendidas em um tempo muito curto.

Vamos fazer algumas contas, com a semplificação selvagem:

• número de solicitações: 1000 (todas as solicitações entram na fila ao mesmo tempo)
• tempo para a primeira solicitação ser concluída: 4ms
• tempo para que todas solicitações subsequentes sejam concluídas: 0ms (sim, eu disse a você que essa é uma semplificação selvagem )

Total de solicitações de tempo como medida por campo # 4: 1000 solicitações na fila * 4 ms cada == 4000 ms. E isso é aproximadamente o valor pelo qual o campo # 4 aumentou ...

Resumindo:

• os campos # 4 e # 8 medem o tempo gasto para atender às solicitações de E / S do ponto de vista de uma única solicitação, multiplicando isso pelo número de solicitações
• campo # 10 informa o tempo real decorrido ("relógio de parede") usado no caminho de E / S

Para desenhar um paralelismo apro- vativo: pense no CPU multi-core. Dois processos podem martelar simultaneamente a CPU, executando por 60s cada. O tempo total de CPU usado é de 120s (60s * 2), mas o tempo decorrido real permanece no total de 60s, já que os dois processos são executados simultaneamente.