alta cancelled_write_bytes

Question

Em um servidor MySQL em execução no AWS EC2 com um volume do EBS

iostat retorna o seguinte

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          37.67    0.00    5.26    0.75    0.08   56.24

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda1              2.08         2.54        48.01     430018    8121472
sdb               2.58        30.61       167.08    5177922   28261768
sdc               0.00         0.00         0.00        224          0
sdd               0.00         0.00         0.00        224          0
sde               0.00         0.00         0.00        224          0
sdf              25.27       230.56       537.18   38998842   90861888

Fazer uma investigação sobre o id do processo do deamon do MySQL fornece isso:

# cat /proc/10247/io
rchar: 8660581593
wchar: 938212302
syscr: 23487140
syscw: 557656
read_bytes: 1739915264
write_bytes: 383774720
cancelled_write_bytes: 349511680

A primeira questão é se o cancelled_write_bytes parece normal? Isso poderia implicar um problema no volume subjacente do EBS?

Minha segunda pergunta é se é normal que Blk_wrtn/s seja maior que Blk_read/s em um banco de dados que seja maioritariamente pesado em SELECT.

    

Answer 1

cancelled_write_bytes: 349511680

Para mim, isso deve ser truncado. Conforme explicado abaixo: Se um processo gravar 1 MB em um arquivo e, em seguida, excluir o arquivo, ele de fato não executará nenhuma gravação. Mas terá sido contabilizado como tendo causado 1MB de gravação.

Os arquivos mysql tmp serão criados e truncados de acordo, e é por isso que você vê esses bytes de escrita cancelados.

Veja proc Explicação de I / O: cancelled_write_bytes

The big inaccuracy here is truncate. If a process writes 1MB to a file and then deletes the file, it will in fact perform no writeout. But it will have been accounted as having caused 1MB of write.

In other words: The number of bytes which this process caused to not happen, by truncating pagecache. 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.