在具有EBS卷的AWS EC2上运行的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 deamon的进程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的基础上有一个问题？
我的第二个问题是Blk_wrtn/s是否高于Blk_read/s对于主要是SELECT重的DB是正常的。
cancelled_write_bytes: 349511680
对我来说，这是由于截断。 如下所述：如果一个进程写入1MB到一个文件，然后删除该文件，它实际上将执行没有写出。 但它会被认为是造成了1MB的写入。
MySQL的tmp文件将被创build和相应的截断这就是为什么你看到这些取消写入字节的原因。
请参阅proc I / O说明：cancelled_write_bytes
这里的大错误是截断的。 如果一个进程写1MB到一个文件然后删除该文件，它实际上将不执行写操作。 但它会被认为是造成了1MB的写入。
换句话说：通过截断pagecache，这个过程导致的字节数不会发生。 一项任务也会导致“负面”的IO。 如果这个任务截断了一些脏的页面caching，那么其他任务已经占用的一些IO（在其write_bytes中）将不会发生。 我们可以从截断任务的write_bytes中减去它，但是这样做会造成信息丢失。