Параметр "% Disk Write Time" и скорость выполнения в сети операций записи
Признайтесь, как часто, оценивая степень загрузки сервера, вы анализируете значения счетчика "% Disk Write Time". Напомним, что значения данного счетчика можно получить с помощью программы MS Performance Monitor. Если не очень, то возможно знакомство с данной публикации побудит вас делать это более часто.
В данной публикации мы не приводим полное описание архитектуры диагностируемой сети, поскольку в данном случае она не важна. Отметим только, что это была коммутируемая сеть со сложной архитектурой, что затрудняло локализацию узкого места, и что основные сервера сети работали под управлением MS Windows NT4. В сети наблюдалось периодическое замедление работы пользовательских приложений, и нужно было установить причину.
Если какие-то пользовательские приложения работают медленно или сбоят, и кабельная система сети уже проверена, то логика дальнейших действий может быть следующей. Нужно установить, а не является ли причиной плохой работы приложения дефекты самого приложения. Для этого нужно запустить в сети тестовое приложение, о котором априорно известно, с какой скоростью оно должно выполняться в исправной сети. Примером такого приложения является программа SelFTrend. Если выяснится, что SelFTrend работает нормально, то причину следует искать в дефектах пользовательского приложения. Если нет - то в сети.
После того, как в тестируемой сети было запущено несколько Агентов, выполняющих программу SelFTrend, один из них показал результаты, представленные на рисунке 1.
Из рисунка 1 видно, что скорость чтения ведет себя адекватно (зеленая линия), в то время как скорость записи (синяя линия) периодически "проваливается".
На рисунке 2 приведена схема тракта между Агентом, где выполнялась программа SelFTrend и тестовым сервером (с которым программа SelFTrend работала). Как видно из рисунка, между Агентом и тестовым сервером расположено несколько активных устройств, поэтому на скорость работы Агента могут оказывать влияния узкие места или дефекты каждого из этих устройств. В общем случае, чтобы выяснить причину "провалов", надо импортировать в базу данных пакета Trend Analyst и проанализировать SNMP статистику со всех устройств тракта. Однако из рисунка 1 видно, что "проваливается" только скорость записи. Из этого можно сделать вывод, что весь тракт исправен, и причину следует искать только на сервере.
Для выяснения причины "провалов" в базу данных был импортирован лог файл, полученный программой MS Performance monitor. Лог файл имел размер более 60 МВ, т.к. в нем содержалась информация по значениям ~100 счетчиков, собранных за неделю. Только импорт в базу данных файла такого размера занимает несколько часов компьютерного времени. Провести же анализ такого файла "вручную" вообще не представляется возможным. Поэтому, чтобы выяснить причину "провалов", мы запустили на ночь процедуру корреляционного анализа всех счетчиков Performance monitor с интегральными характеристиками "скорость чтения" и "скорость записи". Корреляционный анализ является встроенной функцией программы Trend Analyst (FTrend).
Результатом корреляционного анализа является таблица размерностью "2 х 100". Две интересующие нас функции ("скорость чтения" и "скорость записи") и ~ 100 аргументов (все счетчики Performance monitor). При анализе полученной таблицы стало ясно, что наибольшая корреляция характеристики "скорость записи" наблюдается со счетчиком "% Disk Write Time". На рисунке 3 представлены результаты корреляционного анализа характеристик "скорость чтения" и "скорость записи" со счетчиком "% Disk Write Time". (Показать всю таблицу корреляции размерностью 2 х 100 мы не можем.)
Из рисунка 3 видно, что корреляционное отношение скорости записи Агента "PC1" и счетчика "% Disk Write Time" составляет 0.99. Компания Microsoft описывает счетчик "% Disk Write Time" следующим образом: "% Disk Write Time is the percentage of elapsed time that the selected disk drive is busy servicing write requests."
На основании полученных данных мы сделали вывод, что "узким местом" системы является недостаточная производительность дисковой системы сервера. В дальнейшем это подтвердилось. Как и следовало ожидать, недостаточная производительность дисковой системы сервера приводила к замедлению всех пользовательских приложений, работающих с данным сервером. Задача была решена.
Некоторые могут возразить, что для решения задачи достаточно было проанализировать значение счетчика "% Disk Write Time" и все стало бы сразу ясно. С этим трудно не согласиться. Однако вернемся к тому, с чего мы начали -как часто, оценивая степень загрузки сервера, вы анализируете значения счетчика % Disk Write Time. Программа MS Performance monitor поддерживает ~ 100 счетчиков. Если бы заранее знать, какой в данном случае нам нужен ... !
|
к выбору публикации
