Por que os cgroups (bytes servidos em blkio) e iotop produzem resultados divergentes?

Question

Eu trabalho com ferramentas de espaço do usuário lxc no Ubuntu 14.04 e quero realizar alguns testes de estresse e benchmarking dentro de um contêiner. Eu sei que o free e o htop não estão funcionando corretamente em um container.

Estou usando dd e bonnie ++ dentro de um contêiner para enfatizar o disco rígido que é um SSD.

Agora, no lado do host, com o iotop, posso ver a largura de banda de leitura e gravação usada, mas nos cgroups eu tenho resultados divergentes. Os cgroups capturam apenas uma pequena parte dos bytes servidos, enquanto o iotop mostra o uso de largura de banda de várias centenas de mega bytes.

Nos cgroups, estou capturando esta entrada: /sys/fs/cgroup/lxc/disk_stress/blkio.throttle.io_service_bytes

Alguma idéia de por que os valores não são iguais? Quais são os corretos?

    

Answer 1

A parte inferior da documentação do kernel no controlador blkio inclui a nota :

What works

• Currently only sync IO queues are support. All the buffered writes are still system wide and not per group. Hence we will not see service differentiation between buffered writes between groups.

Praticamente, isso significa que as operações de gravação aparecerão no blkio.throttle.io_service_bytes somente se elas ignorarem o buffer do kernel.

A ferramenta fio pode ilustrar isso com muita facilidade. As gravações diretas e sem buffer devem ser relatadas em blkio.throttle.io_service_bytes:

fio --name wxyz --direct=1 --buffered=0 --size=1g --time_based --runtime=120s --bs=4k --rw=write --ioengine=sync --numjobs=1 

Considerando que o contrário & direto & opções de buffer, não há nada relatado em blkio.throttle.io_service_bytes, porque as gravações passam pelo cache de buffer do kernel e são agendadas mais tarde.

fio --name wxyz --direct=0 --buffered=1 --size=1g --time_based --runtime=120s --bs=4k --rw=write --ioengine=sync --numjobs=1

Além disso, este tópico com um engenheiro da RedHat que trabalha com O cgroups reitera o fato de que, uma vez passada a gravação para o cache de gravação dentro do kernel, "devido a essa camada extra de cache, perdemos as informações de contexto quando o IO chega ao dispositivo". E, portanto, nenhuma contabilidade pode ocorrer por blkio.