web-dev-qa-db-ja.com

高いcancelled_write_bytes

EBSボリュームを備えたAWSEC2で実行されているMySQLサーバー

iostatは次を返します

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

MySQLデーモンのプロセスIDを調査すると、次のようになります。

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

最初の質問は、cancelled_write_bytesが正常に見えるかどうかです。基になるEBSボリュームに問題があることを意味しますか？

私の2番目の質問は、ほとんどSELECTが重いDBでBlk_wrtn/sがBlk_read/sよりも高くなるのが正常かどうかです。

mysqlamazon-ebsiostat
2
webgr
cancelled_write_bytes: 349511680

私にとって、これは切り捨てによるものです。以下で説明するように、プロセスが1MBをファイルに書き込んでからファイルを削除した場合、実際には書き込みは実行されません。ただし、1MBの書き込みが発生したと見なされます。

mysql tmpファイルが作成され、それに応じて切り捨てられます。これが、キャンセルされた書き込みバイトが表示される理由です。

proc I/O Explained：cancelled_write_bytes を参照してください。

ここでの大きな不正確さは切り捨てられます。プロセスが1MBをファイルに書き込んでからファイルを削除した場合、実際には書き込みは実行されません。ただし、1MBの書き込みが発生したと見なされます。

言い換えると、ページキャッシュを切り捨てることによって、このプロセスが発生しなかったバイト数。タスクは「ネガティブ」を引き起こす可能性がありますIOも。このタスクがダーティなページキャッシュを切り捨てる場合、別のタスクが（write_bytesで）説明されているIO couldは、切り捨てタスクのwrite_bytesからそれを差し引くだけですが、それを行うと情報が失われます。

2
tike