STU.Part 3
"wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle"
Так вот дядька и сказал, что не нулевой Wait for IO не говорит о проблемах с I/O, а также нулевой I/O не гарантирует, что их нет. Что за колонка такая по которой ничего сказать нельзя -) ? Для начала, что нам хотел сказать man: на самом деле процессор не тратит реального времени на ожидания ввода-вывода, и если ему есть что делать то он занимается реальной работой, отвлекаясь по прерываниям чтобы посмотреть не пришли ли ему данные с устройства. Поясню еще - если процесс блокируется в ожидании ввода-вывода, то дальше идти он не может. Но возможно в системе есть и другие процессы которым нужно процессорное время. Поэтому, если у нас загруженная система, то Wait for IO может быть близким к 0, независимо от от объема ввода-вывода. С другой стороны, если системе делать нечего, то время которое процессор провел в ожидании реального ввода-вывода будет зафиксировано не в idle а в wa.
Даже это (как мне кажется разумное) объяснение не отвечает на вопрос - куда смотреть то чтобы понять есть проблемы с вводом - выводом или нет ? Похоже что для начала нужно смотреть в колонку b - blocked for IO (это я так думаю), а вот что думает man Linux:
"b: The number of processes in uninterruptible sleep."
а документация AIX: "This includes threads that are waiting on filesystem I/O or threads that have been suspended due to memory load control." Что же смотреть в колонке b ? если там постоянно больше процессов чем у вас устройств ввода-вывода (дисков или путей) - это знак. Скорее всего, да - все такие проблемы найдутся.
По моим воспоминаниям, на Solaris был магический барьер - если wait for IO больше 40%, то ищи проблем с вводом выводом, если меньше - то скорее их не найдешь. Число магическое, объяснить я его никак не могу. Конечно же окончательный диагноз дает iostat с service time (<10 ms отлично, больше 100ms все уже умерли) и средней длиной очереди на устройство.
Ну и напоследок, когда я подешел к дядьке и спросил в чем по его мнению разница между swapping и paging, он стал кричать на меня что такого слова swapping нет вообще -) Наверно поэтому она не встречается в описании команды vmstat на AIX, а на Linux (и Solaris) есть цельные колонки -)). На дальше всех пошли пижоны из Apple и я не нашел vmstat на Mac, а vm_stat вообще не содержит колонок, а которых я писал -))
Сообщения
Нашлось в архиве в ту же тему:
ОтветитьУдалитьНекоторое время назад озадачился вопросом: "А как считается статистика I/O wait, которую возвращают top, vmstat и им подобные в Unix-like операционках? И как ее интерпретировать?". Смущало то, что I/O wait возвращается в разделе процессорной статистики и в сумме с us% + sy% + id% всегда (почти :)) дает 100%. При том, что ожидание ввода-вывода по определению процессорных ресурсов не потребляет.
Механизм расчета всех четырех процессорных статистик выглядит следующим образом: один раз в 10 ms в ОС генерируется прерывание и опрашивается состояние всех имеющихся процессоров. Далее,
- если процессор в момент опроса занят выполнением пользовательского кода, на 10 ms увеличивается статистика us%
- кода ядра и прочих системных полезностей - увеличивается sy%
- ничего не выполняет и при этом в системе есть хотя бы один процесс, ожидающий ввода-вывода - увеличивается wa%
- ничего не выполняет и никто не ждет ввода-вывода - увеличивается id%
Т.е. I/O wait % буквально означает процент процессорного времени, которое процессор проистаивал при наличии хотя бы одного процесса, ожидающего ввода-вывода. Механизм расчета может существенно отличаться в разных операционках и версиях. Например, вот тут утверждается, что до версии 4.3.3 AIX регистрировал I/O wait на всех простаивающих процессорах, если в системы был хотя бы 1 ожидающий процесс. Т.е. вполне можно было получить 100% I/O wait при одном ожидающем процессе на 4-процессорной системе. Начиная с версии 4.3.3 I/O wait регистрируется только на том процессоре, который инициировал ожидающий ввод-вывод. Т.е. для одного потока на 4 CPU получим только 25% I/O wait.
Отсюда можно сделать несколько полезных выводов:
1. При оценке нагрузки на процессор по данным vmstat wa% нужно считать бездействием и прибавлять к id%, а не наоборот, как мы это иногда делаем :)
2. Низкое значение wa% в комбинации с высоким значением id% позволяет предположить, что в системе нет проблем с вводом-выводом.
3. Низкое значение wa% в комбинации с низким значением id% не позволяет предположить ничего. Т.к. процессор занят почти на 100%, I/O wait не будет регистрироваться, будь у нас хоть сколько пользователей в очереди к дискам. Т.е. в такой системе может быть проблема только с нагрузкой на CPU, а может - и с CPU, и с дисками. Пока мы не разгрузим CPU, узнать точнее по данной статистике не получится.
4. Высокое значение wa% не позволяет предположить ничего. Можно только сказать, что в системе не нагруженны процессоры и что кто-то (м.б 1 процесс из 1000) часто ожидает ввода-вывода. Не слишком полезная информация.
Т.к. несмотря на написанное выше часто хочется представить себе, как распределено время отклика системы между работой CPU и работой ввода-вывода, предлагается следующий способ:
1. Запускаем vmstat на более-менее продолжительное время. Например, 1 минуту. Получаем статистики us% и sy%, суммируем. Умножаем на кол-во ядер в системе, делим на 100 - получаем секунды процессорного времени, потребляемые за 1 секунду времени реального.
2. Параллельно с vmstat запускаем iostat на тот же период. Получаем кол-во операций ввода-вывода в секунду, среднее время их обслуживания и среднее время ожидания в очереди на ввод-вывод. Из этого получаем общее кол-во времени, потраченного на ожидание ввода-вывода за 1 секунду.
3. Сравнивая (1) и (2), делаем вывод о распределении времени отклика системы по CPU и дискам.
Родион, спасибо, весьма развернуто написано !
ОтветитьУдалитьДяденьке помимо заколачивания баблосов на чтении мастер классов надо бы еще мануалы читать.
ОтветитьУдалить"Solaris uses both common types of paging in its virtual memory system. These types are swapping (swaps out all memory associated with a user process) and demand paging (swaps out the not recently used pages)."
Solaris & Linux - да, похоже что AIX - использует понятие paging для обоих типов активности
ОтветитьУдалить> похоже что AIX - использует понятие paging для обоих типов активности
ОтветитьУдалитьOptimizing AIX 5L performance: Tuning your memory settings, Part 3
"Though often used interchangeably, there is a subtle difference between paging and swapping. As discussed, only parts of the process are moved back and forth between disk and RAM with paging. When swapping occurs, you are moving entire processes back and forth. For this to happen, AIX suspends the entire process prior to moving it to paging space."
Касательно I/O wait.
ОтветитьУдалитьВ Solaris 10 вообще это поле всегда возвращается равным нулю, т.к. наконец-то признали бесполезность этого показателя при анализе общей производительности.
При анализе производительности IO, как правило, ставится цель понять справляется ли текущая подсистема IO?
Для этого нужно заранее знать показатели её производительности в идеальный условиях. Т.е. service time (asvc_t) при нагрузке в 1 поток, но именно под вашим паттерном нагрузки (размер блока, процент записи\чтения, процент случайности), назовем его Х. 4-8мсек для современных FC массивов это базовая точка при блоках в 4-8КБ.
В момент замедления работы приложения анализируется поле asvc_t. Если оно по прежнему Х, то дисковая не перегружена. Если оно 2*Х, или вообще есть ожидания (wsvc_t) то на лицо проблемы перенагруженности подсистемы IO. Имеет смысл оглядываться на текущий средний размер операции IO (kr/s+ kw/s)/(r/s+w/s). Понятно что для операций ввода\вывод по 1МБ asvc_t будет заметно больше чем для 8кБ
Сделать подсистему ввода\вывода быстрее указанных 4-8мсек на текущий момент можно только непробиваемым кэшем массива или применяя SSD. EMC FAST Cache, например, мне очень понравился, до сих пор не привык к таким цифрам :)
Как-то так. Я не претендую на истину, но указанная методика пока работает.
> При анализе производительности IO,
ОтветитьУдалитьСначала ставится задача - а нужно ли нам анализировать эту производительность. Поэтому я с сделал попытку разобраться а дает ли нам Wait for IO что-нибудь. Анализ вводы вывода это с сожалению не только iostat но и также анализ дискового массива- а это требует уже других знаний/софта
>4-8мсек
Скорее всего если цифры такие, то тут и анализировать нечего - все и так летает -)
> по 1МБ
тут вы правы - нужно смотреть на кол-во операций и на их размер. Я встречал ситуации когда большое кол-во операций по 8K убивало массив хотя при этом общий объем считываемых данных был относительно мал
=========8<=========
ОтветитьУдалить3. Низкое значение wa% в комбинации с низким значением id% не позволяет предположить ничего. Т.к. процессор занят почти на 100%, I/O wait не будет регистрироваться, будь у нас хоть сколько пользователей в очереди к дискам. Т.е. в такой системе может быть проблема только с нагрузкой на CPU, а может - и с CPU, и с дисками. Пока мы не разгрузим CPU, узнать точнее по данной статистике не получится.
=========>8=========
Не совсем так, нужно дополнительно учитывать метрику %sytem - в нее также попадает IO (Вы уже сказали, что %wait регистрируется только если в системе есть процессы ожидающие IO (b в vmstat > 0), но при этом само ядро может генерировать IO: paging, отложенная запись, работа с журналом ФС), всю путаницу вызывает именно %system, как метрика в которую попадает весь мусор, не подходящий под %usr, %idle и %wait