Как оценить критическую нагрузку на дисковую подсистему?
Работаю с сервисом, который постоянно пишет-читает диск. Это система построенная на базе Elasticsearch, работает в тестовом режиме, пока нагрузок близких к боевым не было.
Встал вопрос мониторинга нагрузки на дисковую подсистему.
Снять нагрузку несложно, сложно интерпретировать результаты. Я мало сталкивалась с дисками, raid и схд, поэтому немного не понимаю, в какую сторону двигаться.
Собран RAID 10, контроллер PERC 6/i Integrated, диски SEAGATE, Centos7, xfs
=== START OF INFORMATION SECTION ===
Vendor: SEAGATE
Product: ST3600057SS
Revision: ES66
User Capacity: 600,127,266,816 bytes [600 GB]
Logical block size: 512 bytes
Rotation Rate: 15000 rpm
Form Factor: 3.5 inches
Logical Unit id: 0x5000c5007ece257f
Serial number: 6SL9L37D
Device type: disk
Transport protocol: SAS
Local Time is: Thu Sep 3 15:39:39 2015 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Disabled or Not Supported
Среднее время доступа одного диска 3.4 мс при чтении, 3.9 мс при записи
Среднее время ожидания 2 мс
Возьмем данные за последние 10 минут, например.
summary: 19 io/s, read 640 sectors (0kB/s), write 284120 sectors (236kB/s) in 600 seconds
Performance Data: tps=19io/s; read=546b/s; write=242449b/s;
Информация берется отсюда: /sys/block//stat
Выходит, что так как у меня raid, то один iops на чтение является реальным одним iops. На запись же выходит, что один iops на запись превращается в 2 iops по факту.
Когда начинать паниковать, что нагрузка на диск растет? По факту, если смотреть на графики, больше 40 iops вообще еще не бывало. Сколько секторов в секунду нормально, а сколько - уже плохо?
Не хотелось бы спохватиться по факту, когда диски заткнулись и все висит и ждет завершения ввода-вывода.
Какие значения iowait должны пугать?
Я проверяю диски на наличие ошибок в смарт, этого достаточно для понимания, когда диск начинает выходить из строя и его пора менять?
Хотелось бы разобраться с мониторингом и тюнингом дисковой подсистемы, буду благодарна любым ссылкам, объяснениям и литературе.
С iowait не все так просто вот здесь неплохое объяснение как оно работает.
Если у Вас есть мониторинг, я бы ориентировался на значения await/svctm из iostat. Посмотреть какое время random read заявляют производители дисков (обычно это 3-5мс) и считать эти показатели допустимыми.
Касательно объема читаемых данных вцелом нельзя сказать какое кол-во является нормальным, особенно имея смешанную нагрузку. Тут наверно стоит обращать внимание на utilization но также стоит соблюдать осторожность
Закономерности нет, есть как бы взаимосвязь, но прямой зависимости нет, потому что все зависит от того куда на диске пишутся данные.
Чуть ниже ответ amarao и его пояснения на мои вопросы, это тоже неплохой объективный способ оценки общей загрузки диска.
В линуксе самым очевидным индикатором утилизации дисков является flight_time. Если делать замеры каждую секунду, то разница между начальным и конечным значением покажет, сколько секунд в течение секунды диск был занят (значение обычно от нуля до 1).
Находится оно в /sys/block/sdX/device/stat (значение всех этих цифр - в Documentation исходников ядра).
На бытовом уровне - если блочных устройств мало, то просто atop (и дать секунд 11-12 отстояться) - и там будет показана утилизация диска.
Если блочных устройств много и они не влазят в вывод атопа, то я написал отдельно для себя простенький top по блочным устройствам https://github.com/amarao/blktop
Если нужно собирать эти метрики в автоматическом режиме, то обычно у соответствующих приложений (например, munin или ganglia) есть модули, которые эту информацию собирают.
Поясните пожалуйста.
К примеру у нас диск имеет random read 3ms. Мы снимаем значение flight_time и в определенный момент времени наблюдаем это значение высоким, поскольку данный параметры описывает фактически кол-во незавершенных операций. В свою очередь, эти операции могут укладывать во временные рамки 3ms и завершаться пропадая из очереди, а их появление вызвано "микросатурейшеном"
Тоесть мы можем наблюдать ситуацию когда у нас и await и svctm не превышает 3ms но в свою очередь значение flight_time высокое ?
Дэн Иванов: latency дисковых операций к этому не имеет отношения. flight time показывает, сколько времени (а после перенормирования дельты к секунде - какую часть времени) диск был занят. То есть если утрировать, то это показать "busy". Если диск всё время выполняет какие-то операции, то он занят и дополнительные операции выполнять не сможет или будет выполнять их с большим latency из-за очереди. Так что в atop'е принцип простой - близко к 90+%, диск не справляется с нагрузкой. Ниже 30-40% - ок, меньше 10% - диск простаивает.
Смотреть величину лучше не на секундном интервале, а на интервале в секунд 10-20-30.
Всякие пики по латенси и прочие "мгновенные странности" так не увидеть, но принцип такой: если диск уже занят и приходит ещё одна операция, то она уходит в очередь (что плохо). Чем больше таких ситуаций в течение интервала времени (чем ближе к 100%), тем более занят диск.
Не существует метода (я не знаю такого) различить bus saturation (PCI, SCSI) и тормоза дисков. Точнее, различить их можно, если дисков много и есть простаивающие. Если тупят нагруженные диски, а простаивающие выдают нормальную производительность - это диски, если производительность распределяется между всеми одинаково и проседает - это шина. Различить PCI и SCSI вообще никак нельзя (ИМХО).
Если вас интересует совсем низкий уровень (то есть отладка конкретных затыков, вместо "общее состояние сервера"), то надо смотреть в сторону blktrace. Там можно видеть каждый запрос IO со всеми деталями (кто послал, сколько времени запрос обрабатывался и кем). Очевидно, что и latency там тоже видно будет. Но он не бесплатный в смысле производительности (по процессору и latency для операций), то есть держать на продакшене включенным я бы не стал.
Средний
