Продолжая серию заметок о мониторинге рассмотрим архитектуру UNIX. Как и в случае с Windows, детальные описания наиболее важных счетчиков UNIX мы разместили на DevOps Wiki, а в наших заметках предоставим сводную информацию со всеми необходимыми ссылками.
Доминирование систем и приложений на базе Windows неоспоримо, однако существует великое множество приложений на платформе UNIX – как старых, так и современных. И вопросы по мониторингу подобных приложений возникают повсеместно.
Развитие известных и уважаемых клонов семейства UNIX, таких как HP/UX, Sun Solaris, and IBM AIX, а также быстрое распространение Linux, вызвало создание и портирование популярных приложений под UNIX, известный своей стабильностью и расширяемостью. UNIX/Linux также стали приоритетными платформами для систем на базе J2EE, начиная с Web-серверов Apache и серверов приложений WebSphere до серверов баз данных Oracle.
Хотя варианты UNIX могут отличаться в специфических командах и их опциях, все они предоставляют различные встроенные средства для сбора, отображения и повторного использования информации, связанной с производительностью. Эти средства используют различные методики замеров, чтобы генерировать интервальные данные мониторинга быстродействия, что очень полезно при диагностировании проблем с производительностью. Они разработаны так, чтобы быть достаточно эффективными, и их можно было использовать продолжительное время с минимальным влиянием.
Архитектура операционной системы UNIX состоит из трёх уровней – Пользователь, Ядро и Аппаратные средства, как показано на картинке ниже:
Уровень Ядра – это самая суть UNIX, он служит интерфейсом между Пользовательским и Аппаратным уровнями. Ядро состоит из ряда программ для различных целей. Среди них:
1. Интерфейс системных вызовов. Обрабатывает и выполняет системные вызовы. Они являются функциями, при помощи которых программа делает запрос к операционной системе.
2. Файловая система. Взаимодействует с уровнем управления процессами и интерфейсом системных вызовов, управляет вводом и выводом символьных и блочных данных. Драйвер устройств отвечает за ввод/вывод.
3. Управление процессами. Координирует и контролирует различные процессы в UNIX. Процесс – это программа, в настоящее время выполняемая в операционной системе, как пользовательская, так и системная.
4. Управление аппаратной частью. Координирует работу аппаратных устройств, таких как клавиатура, монитор, жёсткий диск и ОЗУ.
5. Драйвера устройств. Работают с системными устройствами, такими как жёсткий диск, ОЗУ и принтер для ввода/вывода.
Управление памятью – интегральная часть архитектуры UNIX. Распределяет ресурсы памяти между процессами, выполняемыми на UNIX. Отвечает за построение иерархии памяти, которая состоит из:
1. Буфер или кэш памяти: быстрая и дорогая память объёмом в несколько килобайт или мегабайт, данные постоянно меняются.
2. Основная память, или ОЗУ: средняя по скорости, цене и изменениям данных основная память объёмом в несколько мегабайт или гигабайт.
3. Вторичная, или дисковая память: медленное и дешёвое хранение редко меняющейся информации, измеряемой в гигабайтах и более, на дисках или плёнках.
Как пользовательские, так и системные программы называются процессами. Их главная задача – выполнять задания. Каждому процессу система присваивает уникальный номер – Идентификатор Процесса (PID), и затем использует эти идентификаторы для того, чтобы определять процессы и управлять ими. Используя эти номера, система назначает приоритет каждому процессу. После создания, процесс может выполняться на переднем плане или в фоновом режиме. Выполнение в фоновом режиме позволяет системе одновременно выполнять несколько процессов.
Ресурсы производительности
В UNIX-системах есть 7 основных типов ресурсов, которые можно мониторить и настраивать:
1. ЦПУ
2. Память
3. Дисковое пространство и архитектура
4. Коммуникации
5. Время ввода/вывода
6. Сетевое время
7. Приложения
Общее время выполнения (Total Execution Time)
С точки зрения пользователя, общее время выполнения представляет собой «время на настенных часах» – реальное время. На уровне процессов оно измеряется запуском команды time. Она показывает время, затраченное на выполнение как пользовательских, так и системных процессов. Если суммарно оно составляет более 80% ЦПУ, то высока вероятность того, что система ограничена в ресурсах центрального процессора.
Компоненты общего времени выполнения:
1. ЦПУ пользовательского режима. Фактическое время, которое ЦПУ затрачивает на выполнение программ в этом режиме. Включает в себя время на исполнение вызовов библиотек, но не включает то, которое потрачено на процессы непосредственно ядра. На это числовое значение может сильно повлиять использование оптимизации при компиляции, а также написание эффективного кода.
2. ЦПУ системного режима. Время, которое ЦПУ тратит на системную сторону выполнения заданной программы. Все подпрограммы ввода/вывода запрашивают обслуживание ядра. Программист может повлиять на это значение, используя блокировку трансферов ввода/вывода.
3. Время ввода/вывода. Время, затраченное на обслуживание запросов ввода/вывода.
4. Сетевое время. Время, затраченное на перемещение данных.
5. Производительность виртуальной памяти. Включает в себя контекстное переключение и страничный обмен.
6. Время выполнения других программ. Когда система не обслуживает данное приложение, потому что ЦПН занято другой программой.
Инструменты
Большинство вариантов UNIX включают в себя встроенную статистическую информацию, которую собирает операционная система во время выполнения процесса. Различные аспекты этой статистики доступны, если использовать следующие инструменты UNIX:
- rstat. Сервер/демон, возвращающий статистику производительности, полученную от ядра.
- netstat. Сетевая статистика.
- nfsstat. Статистика NFS (сетевой файловой системы).
- time/timex. Утилизация процессов ЦПУ.
- uptime. Средняя загрузка системы.
- ps. Статистика процессов.
- iostat. Инструмент для ввода/вывода.
- sar. Общая системная активность.
- vmstat. Инструмент для виртуальной памяти.
- prof. Профилирование процессов.
- trace. Используется для более глубокого анализа.
Одной из самых полезных команд является uptime, которая показывает среднюю загрузку системы. Отметим, что она может быть использована только как грубый индикатор, поскольку не берёт в расчет приоритеты планировщика. При запуске команды uptime выводятся 3 значения среднего числа процессов, стоящих в очереди на исполнение – за последние 1, 5 и 15 минут.
Команда sar – хорошая альтернатива команде uptime, при условии использования опции ‘-q’. Она выдаёт статистику по средней длине очереди на запуск, проценту времени занятости этой очереди, а также по средней длине swap-очереди (на выгрузку) и проценту времени её занятости. Очередь на запуск отражает задачи, которые находятся в памяти и готовы к старту, но не включает в себя спящие и те, которые ждут ввода/вывода. Эта очередь должна быть меньше 2.
Примечание: Разные варианты UNIX могут обладать специфическими возможностями, которые упрощают мониторинг производительности. Например, Sun Solaris обладает командами rup и perfmeter, которые широко используются вместо основных инструментов BSD.
Мониторинг UNIX при помощи инструментов HP
В отличие от Windows, данные о производительности в UNIX разбросаны по разным процессам, которые собирают всевозможную статистическую информацию. Некоторые из этих процессов (демоны) работают постоянно, а некоторые нужно запустить для получения информации.
Поэтому неудивительно, что многие вендоры продуктов мониторинга и нагрузочного тестирования уделили отдельное внимание данной платформе. Например, HP LoadRunner и HP Performance Center, о которых мы уже рассказывали, включают в себя инструментарий, при помощи которого можно добраться до счётчиков производительности операционной системы UNIX, чтобы отслеживать поведение тестируемого приложения.
Встроенные в продукты HP LoadRunner и HP Performance Center решения для мониторинга среды UNIX используют демон rstatd, который обычно уже сконфигурирован и запущен в большинстве версий. Чтобы убедиться, что демон rstatd уже настроен, следует выполнить команду rup, которая показывает различные статистические данные по машине, включая rstatd. С учётом информации, собранной этим демоном, из хоста UNIX можно получить показания самых важных счётчиков, таких как утилизация ЦПУ, скорость контекстных переключений, скорость диска и т.п. Если нужно посмотреть на метрики производительности более детально, мы рекомендуем использовать инструменты UNIX, которые описывали ранее.
Вместо того, чтобы задавать отдельные команды с аргументами, разнящимися для каждого клона, имеет смысл развернуть инструмент HP SiteScope. Он работает вместе с LoadRunner и/или Performance Center.
HP Sitescope предоставляет адаптивную инфраструктуру, которая может мониторить разные варианты UNIX, выделяя особенности каждого из них и группируя счётчики исходя из их целевого назначения. Это возможно благодаря настройке файла-адаптера для поддержания каждого отдельного варианта UNIX по части мониторинга. SiteScope использует файлы-адаптеры, чтобы описывать команды, необходимые для импорта различной системной информации с серверов на разных операционных системах UNIX.
Эти команды носят общий характер, распространяющийся на все основные средства того или иного клона семейства UNIX. Команды покрывают широкий спектр различных сторон UNIX и, среди прочего, содержат следующие:
- disk. Аргументом выступает диск, возвращает значения общего и свободного пространства на нём, а также процент использования.
- disks. Возвращает список файловых систем в данной системе.
- memory. Количество занятого и доступного свопового пространства.
- pageFault. Количество сбоев страниц за секунду. Если сбои происходят на нескольких линиях, они суммируются.
- cpu. Возвращает числовые значения процента времени ожидания и времени простоя ЦПУ.
- process. Выводит список процессов с длинными названиями.
SiteScope группирует счётчики, исходя из их целевого назначения (ЦПУ, память, ввод/вывод), и автоматически собирает данные производительности по экземплярам в группе. Например, общий показатель утилизации ЦПУ отображается вместе с теми же данными по каждому установленному процессору, а индексы сетевой статистики по каждой сетевой карте – с общей пропускной способностью сети. Такой подход упрощает работу тестировщика нагрузки, поскольку логически объединяет миры Windows и UNIX, и больше не приходится жонглировать данными между средами в рамках одного нагрузочного тестирования.
Наверное, данной информации должно хватить для получения представления об архитектуре и инструментарии, а в следующей заметке расскажем собственно об основных счетчиках UNIX и особенностях мониторинга.
