 |
Кто важней: "%Processor Time" или "Interrupts/sec"
Большинство администраторов сетей полагают, что основным критерием высокой загрузки сервера является высокое значение утилизации процессора сервера (параметр % Processor Time). В данной публикации приводится пример того, когда критерием высокой загрузки сервера является параметр "Interrupts/sec".
Как Вы думаете, если значение счетчика "Interrupts/sec" равно 600, это хорошо или плохо? Напомним, "Interrupts/sec" - это счетчик, который измеряется программой MS Performance monitor, и про который известно следующее:
"Interrupts/sec is the average number of hardware interrupts the processor is receiving and servicing in each second. It does not include DPCs, which are counted separately. This value is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network interface cards and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention. Normal thread execution is suspended during interrupts. Most system clocks interrupt the processor every 10 milliseconds, creating a background of interrupt activity. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval."
Легко анализировать параметры, если они измеряются в процентах. Очевидно, что если ресурс загружен на 99% - то это плохо, а если на 1%, то это хорошо. Если же какой-то параметр измеряется не в процентах, а в абсолютных значениях, то анализировать его не просто. Традиционные методики предлагают наблюдать за таким параметром в течение длительного времени, на основе наблюдений построить базовую линию, на основе базовой настроить триггеры и сигнализацию (triggers and alarms) и т.д. Даже работу относительно небольшой системы характеризует более 500 параметров, которые измеряются в абсолютных значениях (а не в %). Так что же, - строить 500 базовых линий, настраивать 500 триггеров … , или такие параметры вообще не анализировать?
Решение есть. Оно заключается в том, чтобы строить базовую линию не по всем параметрам (далее параметры-аргументы), а только по нескольким, интегральным параметрам. Одним из таких интегральных параметров может быть скорость выполнения операций чтения/записи, которая измеряется программой SelFTrend (FTrend). Если интегральный параметр не свидетельствует о наличии проблемы, тогда параметры-аргументы не анализируются. И только если выяснится, что интегральный параметр "проваливается", тогда следует анализировать все параметры-аргументы. Цель анализа - выяснить, от какого из параметров-аргументов в наибольшей степени зависит интегральный параметр. Это и будет наиболее значимый параметр (параметры), который оказывает наибольшее влияние на быстродействие работы информационной системы. При этом не важно, измеряется данный параметр в процентах или попугаях.
В процессе анализа работы одной из сетей на базе сервера MS Windows NT4 мы выяснили, что таким параметром, который в наибольшей степени влияет на работу информационной системы, может быть параметр "Interrupts/sec". Как следует из описания данного параметра, он, также как и параметр "% Processor Time", характеризует степень загрузки процессора сервера. Однако, поскольку данный параметр измеряется в абсолютных значениях, а не в процентах, на него редко обращают внимание. Оказывается зря.
На рисунке 1 приведены графики интегральных параметров (скорость чтения и скорость записи) и параметров-аргументов: "% Processor Time", "Interrupts/sec". Эти графики получены в результате импорта результатов работы программ SelFTrend (FTrend) и лог файла программы MS Performance monitor в базу данных программы Trend Analyst.
Из рисунка 1 видно, что, несмотря на то, что утилизация процессора сервера в среднем не превышает 2.5% (параметр "% Processor Time" * 50), информационная система периодически работает с перегрузкой. Наиболее значимым параметром, в данном случае, является параметр "Interrupts/sec". Он "важней", чем параметр "% Processor Time". Таким образом, отвечая на поставленный в начале публикации вопрос, можно утверждать, если значение счетчика "Interrupts/sec" равно 600, то это плохо, а если равно 400, то это хорошо. Вот так, не больше и не меньше.
Важно отметить, что мы смогли сделать такие выводы только после того, как импортировали все данные из лог файла программы MS Performance monitor в базу данных Trend Analyst, и проанализировали их с помощью встроенной функции корреляционного анализа. (Сделать это "вручную" было бы не реально, т.к. лог файл программы MS Performance содержит более 100 параметров.)
Чтобы получить более точную информацию о том, как скорость работы информационной системы зависит от параметра "Interrupts/sec", полученные данные были обработаны с помощью встроенной функции регрессионного анализа. Результаты представлены на рисунке 2.
В заключение, хотелось бы несколько слов сказать об интегральных параметрах (критериях) качества работы информационной системы. В рассмотренном примере, в качестве интегрального критерия была взята скорость выполнения операций записи, измеряемая программой SelFTrend (FTrend). Это достаточно "грубый" критерий. Мы выбрали его, так как, в данном случае нас, прежде всего, интересовала исправность работы информационной системы (наличие в ней дефектов).
Если бы нас интересовала не исправность системы, а, например, производительность работы конкретного приложения, и мы хотели бы оптимизировать систему под этот критерий, то интегральный параметр должен был быть другим. (Например, таким параметром могло быть время выполнения транзакций, измеренное приложением SLa-ON Agent.) Возможно и значимость параметра "Interrupts/sec" могла бы быть немного выше или ниже. Однако качественно картина бы не изменилось. Подробнее о критериях качества работы информационных систем и методике их оценки можно прочесть в разделе SLa-ON APM нашего сайта.
|
к выбору публикации
