На сервере MySQL, запущенном на AWS EC2 с томом EBS
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 дает следующее:
# 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.
cancelled_write_bytes: 349511680
Для меня это связано с усечением. Как поясняется ниже: если процесс записывает 1 МБ в файл, а затем удаляет файл, он фактически не выполняет записи. Но это будет считаться причиной записи 1 МБ.
Файлы mysql tmp будут созданы и обрезаны соответственно, поэтому вы видите эти отмененные байты записи.
Видеть Объяснение ввода-вывода proc: cancelled_write_bytes
Большая неточность здесь - усечение. Если процесс записывает 1 МБ в файл, а затем удаляет файл, он фактически не выполняет записи. Но это будет считаться причиной записи 1 МБ.
Другими словами: количество байтов, из-за которых этот процесс не произошел из-за усечения кеша страниц. Задача также может вызвать «отрицательный» ввод-вывод. Если эта задача усекает некоторый грязный кэш страниц, некоторый ввод-вывод, который был учтен другой задачей (в ее write_bytes), не будет происходить. Мы мог просто вычтите это из write_bytes задачи усечения, но при этом происходит потеря информации.