Мониторинг аппаратных серверов

Времена выполнения операций в тесте желательно рассматривать вместе с анализом загрузки ресурсов аппаратных серверов, на которых развернуто и работает приложение. Если, например, операции выполняются медленно и при этом время отклика дискового массива, который использует СУБД намного хуже критериев, то с большой долей вероятности можно утверждать, что "узкое место" в системе создается низкопроизводительной работой дисковой стойки. Как правило избавившись от одной "узкости", тут же можно столкуться со следующей. Часто "узким местом" является само приложение, которое спроектировано и разработано так, что требует больших мощностей, для того чтобы обеспечивать удовлетворительную производительность.

Итак, какие метрики являются самыми распространенными и какие значения они могут принимать.

ЦПУ
1. Счетчики для загрузки ЦПУ
MS Performance : Processor\% Processor Time, Processor\% User Time, Processor\% Idle Time
Unix (Solaris) : sar -u : %usr, %sys, %wio, %idle
2. Значение очереди
MS Performance : System\Processor Queue Length
Unix (Solaris) : sar -q : размер средней очереди

В качестве примеров используются утилиты мониторинга MS Performance для MS Windows и sar (system activity reporter), который есть во многих unix-ах. Для Microsoft %Processor Time является метрикой используемости ЦПУ в течение контролируемого интервала. В это значение, насколько я понимаю, входит вся активность и справедливо следующее утверждение : %Processor Time + %Idle Time = 100%. Счетчик %User Time включает в себя активность прикладных программ. Для sar полная активность по использованию ЦПУ определяется суммой %usr + %sys. При этом %usr это активность прикладных программ а %sys обслуживание различных системных вызовов. Счетчик %wio показывает сколько времени (в %) было потрачено на ожидания ввода вывода. Идеально это %wio не должно постоянно быть большим и вобщем-то стремиться к нулю. Замеренные значения загрузки ЦПУ целесообразно рассматривать совместно со значениями счетчиков очереди. Очередь показывает, какое количество задач (тредов) ожидает своего выполнения. Как правило очередь появляется при увеличении загрузки ЦПУ до значений 60 и более процентов. Желательно чтобы значение очереди не превышало количество процессоров на сервере, так как в этом случае задания будут ждать и не выполняться. При этом высокая загрузка до 90% и наличие очередей допустимо, если времена выполнения операций удовлетворяют примлемым для бизнеса критериям. Надо только понимать, что этом случае у системы практически нет запаса ресурса и повышение нагрузки может привести к ухуджению (причем даже к нелинейному) производительности системы.

Память
1. Счетчики доступного объема памяти
MS Performance : Memory\Available Mbytes
Unix (Solaris) : sar -r

Если количество доступной памяти (во время теста или при эксплуатации) снизилось до 10% процентов от общего объема, то это уже повод для нахождения причин приводящих к такой ситуации. Если доступной памяти остается меньше 5%, то скорее всего нехватка памяти уже приобретает статус "узкого места". Также тенденция уменьшения размера доступной памяти в пределах значения 10 Мб/час может указывать на "утечку памяти".

Дисковые массивы.
MS Performance : Physical Disk\Avg. Disk sec/Write, Physical Disk\Avg. Disk sec/Read

Показателями медленной работы дисковой подсистемы являются значения счетчиков Avg. Disk sec/Read, Avg. Disk sec/Write идеально эти значения должны быть в пределах 10ms (для журналов транзакций СУБД в идеале 0 мсек), превышения значений счетчиков > 25ms в течение длительного времени (более 5 минут) является указателем на медленную работу дисков. Ранее вторым критерием было наличие очереди на диски, считалось, что значение 2 на шпиндель уже является проблемой. Сейчас в современных дисковых массивах, в связи с виртуализацией дискового пространства, измерение этого параметра стало затруднительным (для примитивных дисковых хранилищ типа Direct attach storage - DAS и внутренних дисков сервера этот параметр по-прежнему может использоваться). При этом, чтобы понять насколько производительно используется дисковый массив под управлением той или иной операционной системы (Unix), желательно проконсультироваться со специалистами по данному типу дискового массива.

Тестирование

Итак, сейчас добавим немного методологии по проведению самого нагрузочного тестирования. Допустим, что все предыдущие шаги успешно завершены, а это значит, что у нас есть:
1. Разработанная и согласованная модель нагрузки. Для модели отобраны критичные для данного вида тестирования операции, определены интенсивности их выполнения в тесте. Определены профили нагрузки, если Приложение имееет различные модели поведения. Рассчитаны нагрузочные точки.
2. Для моделируемых операций разработаны нагрузочные скрипты и созданы необходимые датапулы.
3. Разработаны сценарии, выполнения криптов, которые соответствуют профилям модели нагрузки.
4. Произведена проверка работы скриптов в сценариях. Необходимо исполнить каждый скрипт входящий в сценарий, используя хотя бы несколько виртуальных пользователей в группе, чтобы исключить ошибки взаимного влияния скриптов друг на друга. Тут же могут быть обнаружены скрипты с недостаточно хорошо сделанной корреляцией.

Если ошибок нет, то тогда можно приступать к испытаниям. Необходимо заметить, что оборудование тестового стенда должно в идеале как можно ближе соответствовать промышленной конфигурации. Особенно в случае, когда на основе полученных в результате тестирования времен выполнения операций будут приниматься какие-то бизнес решения. В случае если речь идет просто об оптимизации Приложения, то соответствие конфигураций тестового стенда и промышленного уже не так актуально. Для мониторинга тестовых серверов необходимо иметь доступ на сервера с правами для использования таких утилит как MS Windows Performance для MS Windows или sar, iostat, vmstat для unix-образных OS. При сохранении журналов мониторинга на тестовых серверах необходимо убедиться в наличии дискового простанства для хранения соответствующих объемов информации.

Первые запуски тестов являются пробными и позволяют понять поведение системы в целом, включая работу тестируемого Приложения и оборудования, на котором оно размещено. Начинать испытания надо с нагрузочных точек с меньшей нагрузкой, двигаясь по мере нарастания нагрузки от меньшей к большей. Может получиться так, что в процессе тестирования количество нагрузочных точек поменяется, а также изменятся количества виртуальных пользователей входящих в ту или иную нагрузочную точку. Хотелось бы так же заметить, что результаты испытаний в идеале должны быть логически согласованы. Это значит, что при увеличении нагрузки, результаты времен выполнения операций (и загрузки тестового оборудования) должны соответственно ухудшаться, а не наоборот. Если на нагрузочной точке с большей нагрузкой результаты лучше, то такой эксперимент надо перепровести, чтобы понять причины такого "выброса". Как вариант возможна ситуация, что нагрузочные точки были неправильно спроектированы и возможно нужно увеличть размер "шага", чтобы действительно почувствовать увеличение нагрузки. В заключение хочется добавить, что набор экспериментов (и как следствие результатов) должен быть достаточен для того, чтобы можно было провести анализ "узких" мест и сделать выводы о производительности и стабильности работы тестируемого Приложения.