Вход |  Регистрация

Все Тэги

Счетчики UNIX

30.05.20131209 просм.

Итак, переходим к мониторингу процессов и сводной информации об основных счетчиках UNIX.

Мониторинг процессов

UNIX – это мощная и очень гибкая операционная система. Она позволяет пользователям запускать нужные процессы на переднем плане или в фоновом режиме. Программы на первом плане имеют полный доступ по чтению и записи, в то время как фоновые не имеют доступа чтения.

Доступны счётчики производительности, измеряющие, сколько времени расходует ЦПУ на обработку отдельных потоков выполнения и других исполняемых модулей. Эти метрики утилизации процессора позволяют определить, какие приложения используют ресурс ЦПУ.

Хотя не существует единой опции для всех вариантов UNIX, использование HP SiteScope Process object даёт статистическую информацию по выбранному процессу/потоку выполнения, если такие данные доступны (не все счётчики работают для всех вариантов UNIX).

  • CPU. Утилизация ЦПУ по выбранному процессу в процентных пунктах от общего использования ЦПУ.
  • MEMSIZE. Количество памяти, потребляемое данным процессом.
  • PID. Идентификационный номер процесса, присвоенный ему операционной системой.
  • THREADS. Количество потоков выполнения, инициированных выбранным процессом.
  • USER. Количество пользовательских сессий.

Если HP SiteScope не предоставил удовлетворительных деталей мониторинга процесса, всегда есть возможность воспользоваться встроенными командами UNIX:

  • ps. Показывает статический список запущенных процессов. Вдобавок команда ps выводит специфические детали процессов, такие как PID, используемая память и командная строка, использованная для запуска процессов. В большинстве случаев рекомендуется добавить атрибут –aux, который даёт информацию по пользовательским и нетерминальным процессам.
  • top. Показывает список текущих запущенных процессов и количество занимаемой ими памяти. Команда top автоматически обновляет список каждые несколько секунд, чтобы отображать активные процессы на компьютере.
  • инструменты proc. Дают возможность получить ещё больше информации о процессах. Их следует использовать с осторожностью, потому что во время работы они приостанавливают выполнение процессов. Инструменты proc расположены в /var/proc и включают в себя pfiles (активные процессы), pflags (информация о статусе и флагах процессов), pldd (все динамичные файлы библиотек, связанные с каждым процессом), pmap (карта адресного пространства для процессов), pslg (действия, предпринятые по разным сигналам и потокам выполнения), prun (запускает или начинает процесс), pstack (трассировка стека), pstop (приостанавливает выполнение определенного процесса).

Типы счётчиков

Каждый счётчик относится к определённому типу. Знание типа счетчика полезно, потому что он указывает, как была получена статистика производительности. Вот несколько важнейших категорий счётчиков:

  1. Моментальные. Показывают простое числовое значение самого последнего измерения.
  2. Интервальные. Отображают показатели активности за период времени.
  3. Счётчики наработки. Показания собраны на интервальной основе, суммированию не подлежат.
  4. Усреднённые счётчики. Предоставляют средние значения на временном отрезке.

Процессор – важнейшие счётчики

Во время своего выполнения каждое приложение использует ресурсы ЦПУ. Запросы на ресурсы процессора поступают в рамках пользовательского и системного режимов.

Прохождение процессов в пользовательском режиме связано с фактическим временем, которое ЦПУ затрачивает на выполнение пользовательских программ. Включает в себя время на исполнение вызовов библиотек, но не включает то, которое потрачено на процессы непосредственно ядра.

Прохождение процессов в системном режиме отражает время, которое ЦПУ затрачивает, выполняя системную часть данной программы. Все подпрограммы ввода/вывода запрашивают обслуживание ядра.

Обычно достаточно просто определить, что ЦПУ является узким местом: показатель общей утилизации ЦПУ (средний по всем подключенным процессорам) около 100 % и всегда есть процессы, ожидающие обработки. Однако не всегда так же просто определить, почему это произошло. Поэтому очень важно знать историю поведения приложения в нормальных условиях, чтобы использовать это как точку отсчёта при анализе нагрузки.

Счётчики, приведённые ниже, относятся к мониторингу на системном уровне, где учитываются общие параметры процессора, независимо от поведения отдельных процессов.

Счетчики:

Память – основные счётчики

UNIX работает с физической (резидентной) и виртуальной памятью. Операционные системы скрывают фактический объем имеющейся памяти от приложений – поэтому они, как правило, завышают показатели её наличия. UNIX использует термин «виртуальная память», который на практике включает в себя объём памяти, который приложения используют под свои данные, в том числе разделяемая и динамическая память, текст программы, разделяемые библиотеки и отображаемые в память файлы. Общее количество виртуальной памяти, выделенной всем процессам в системе, приблизительно отображает объём раздела подкачки, который будет зарезервирован (за исключением памяти под тексты программ).

Вообще-то, виртуальная память мало что имеет общего с фактическим распределением физической памяти, потому что не все данные, размещённые в виртуальной памяти, будут активны («Resident») в физической. Когда программа выдаёт ошибку «out of memory» («недостаточно памяти»), чаще всего это означает нехватку зарезервированного раздела подкачки (виртуальной памяти), а не физической (резидентной) памяти.

Нехватка оперативной памяти часто является непрямым свидетельством проблем с быстродействием диска, когда чрезмерная подкачка страниц занимает слишком большой процент пропускной способности диска. Следовательно, объёмы подкачки являются важным индикатором производительности памяти.

Принято считать, что на сегодняшний день память сравнительно недорогая – а значит покупка дополнительной памяти может решить все проблемы. Однако большой объём физической памяти не помогает предотвратить нехватку виртуальной, и может даже привести к фатальным сбоям в случае утечек памяти, когда приложение не освобождает уже ненужные участки памяти. В некоторых случаях, если UNIX система установлена для управления базой данных или аналогичным приложением, обрабатывающим транзакции большого объёма, существенное увеличение памяти может заметно улучшить производительность работы базы данных, позволяя кэшировать больше информации в оперативной памяти.

Когда наблюдается нехватка оперативной памяти, зачастую важно определить, как используется выделенная физическая память, и посчитать количество резидентных страниц проблемного процесса, которые ещё называют набор резидентной памяти (resident memory set).

Вдобавок к распространённым счётчикам (см. далее), важно отслеживать использование буфера и кэшированной памяти – снижение количества доступной памяти не обязательно указывает на утечку, просто память становится частью кэша/буфера (см. %rcache/%wcache и bread/s bwrit/s для Solaris, и HP/UX и Cached и Buffers для Linux)

Совет: Мы рекомендуем обратить внимание на использование памяти, если:

  • Постоянно увеличивается использование свопа системой за определённый период времени
  • Потребление памяти можно посчитать формуле:

Используемая память = Вся память – (кэш + буфер + подкачка)

  • Отдельный процесс вызывает постоянное увеличение резервируемого раздела подкачки – в большинстве случаев, это явно указывает на утечку памяти, вызванную этим приложением.

 Счетчики:

Основные счётчики ввода/вывода

При помощи стека Диспетчера ввода/вывода UNIX обслуживает операции физических и логических дисков. Логический диск – это единая файловая система, которой присвоена уникальная буква. Физический же является внутренним представлением отдельного запоминающего устройства, все равно какого – SCSI, RAID,SATA, и т.д.

При использовании комплексных систем хранения информации, таких как контроллеры массива или RAID, ОС не видит напрямую аппаратных характеристик физических дисков (количество дисков, их скорость, время доступа, скорость вращения шпинделя, битовая плотность, а также объём внутреннего буфера памяти). А тем временем эти параметры могут серьёзно повлиять на производительность. Продвинутые возможности, вроде очереди команд или буфера памяти, могут повысить быстродействие на 25-50%!

Очень важно проактивно относиться к производительности дисковой подсистемы, учитывая её тенденцию резко снижаться, особенно при подкачке страниц.

Примечания:

  • В целом, лучше иметь много дисков поменьше, чем несколько больших, поскольку это даёт большую гибкость в перемещении данных и устранении узких мест. Постарайтесь размещать активно используемые логические диски на нескольких физических дисках и каналах ввода/вывода.
  • Определяя путь к каталогу для приложений, старайтесь минимизировать количество уровней от корня файловой системы. Особо глубокие «деревья» каталогов могут снизить производительность, поскольку для доступа к файлу системе приходится совершать больше поисковых операций. В то же время, доступ к файлу может замедлиться и в том случае, если в указанном каталоге слишком много файлов (несколько тысяч).

Приложения, ориентированные на транзакции, с высокой активностью ввода/вывода, будут более производительными, если использовать физические устройства, а не файловую систему. Это обычная рекомендация большинства поставщиков баз данных, таких как Oracle. Однако последние улучшения в управлении логическими томами уже ставят устройства с файловой системы на один уровень с физическими. В любом случае, устанавливать независимые приложения на уникальные физические диски – хорошая идея, позволяющая снизить их возможное влияние друг на друга.

 Счетчики:

  • %Used – Показывает относительное количество используемого пространства на каждой смонтированной файловой системе
  • Free – Отражает количество свободных байт по каждой смонтированной файловой системе
  • Disk Rate – Помогает определить, является ли физический диск потенциальным узким местом

Общие советы по улучшению производительности ввода/вывода:

  • Как можно больше растянуть дисковый ввод/вывод: лучше 10 дисков, загруженных на 10%, чем 1 диск, загруженный на все 100%.
  • Избегать чрезмерного журналирования: некоторые приложения позволяют управлять уровнем детализации логов.
  • Настраивать устройства SCSI: иногда можно регулировать максимальную длину очереди к определённому устройству. Зачастую это увеличивает количество параллельных обращений, однако приходится расплачиваться возможной перегрузкой железа.

Некоторые факты относительно дисков:

  1. Чем меньше объем ввода/вывода, тем короче время обслуживания. Чем больше объем ввода/вывода, тем это время дольше.
  2. Последовательные запросы ввода/вывода выполняются быстрее, чем случайные – это связано с меньшим количеством движений головки.
  3. Большие объёмы ввода/вывода максимизируют производительность при выполнении последовательных запросов ввода/вывода.
  4. Переход разных системных границ, таких как блоки файловой системы, буферной цепочки или файлового пространства, может привести к разбиванию одного запроса ввода/вывода на несколько более мелких.
  5. Если самый загруженный диск является устройством свопа, то наиболее вероятно, что узкое место памяти замаскировалось под проблему с диском, и сначала стоит обратить внимание именно на вопрос памяти.

Основные сетевые счётчики

Мониторинг сетевой производительности становится все более важным на сегодняшний день, особенно в связи с распространением распределенных и облачных приложений. Однако операционные системы UNIX обычно уже обеспечивают ограниченные статистические данные на различных уровнях: как на самом низком, аппаратном интерфейсе, так и на высоких уровнях сетевого протокола, например TCP/IP. Статистику на сетевых интерфейсах собирает программное обеспечение, встраиваемое на уровне драйверов сетевых устройств. Данное ПО подсчитывает количество отправленных и полученных пакетов.

Сетевая статистика собирается при помощи возможностей UNIX, таких как netstat, netperf и Iozone и nfsstat (для мониторинга NFS) – по одному на каждую установленную сетевую карту или чип. Продукты HP, такие как Network Node Manager и SiteScope, могут собирать статистические данные в течении долгого времени, чтобы дать представление о реальных причинах узких мест производительности.

Узкие места сети сложно обнаружить и проанализировать. Количество пакетов, коллизий и ошибок не всегда указывают на причину проблемы:

  • Только недопустимо большое количество коллизий может указывать на узкое место сети. Если их уровень относительно низкий в течение долгого времени, то это, как правило, нормальное поведение. Коллизии, которые по сути являются ошибками, происходят в результате несоответствий в параметрах дуплекса или скорости. Если эту проблему устранить, количество коллизий снижается, а производительность повышается.
  • Резкое увеличение количества пакетов вместе с большой исходящей сетевой очередью также может быть признаком узкого места сети. Однако, чтобы принять взвешенное решение, следует наблюдать за происходящим в течении некоторого времени.
  • Если NFS активно используется, нужно следить за данными, собранными nfsstat, особенно со стороны сервера. Если статистика NFS показывает повышенную активность, вызванную одним конкретным клиентом, на клиентском хосте рекомендуется запустить инструмент для идентификации ответственного процесса.
  • Узкое место сети может иметь место быть и в случае высокой утилизации ЦПУ в системном режиме или большого количество прерываний на одном из процессоров, в то время как другие в основном простаивают. Проверка конфигурации устройства и оборудования может быть тому причиной.

 Счетчики:

Вот мы и рассмотрели основные метрики Unix. И если вы присматриваете за приложениями, работающими в Unix, не ленитесь отслеживать метрики, даже когда прямо сейчас все работает нормально – иногда проблемы обнаруживаются при сравнении данных на протяжении промежутка времени. А на сегодня все.

Метки: ,

Добавить комментарий

Для отправки комментария вам необходимо авторизоваться.

Партнеры DevOpsHub и DevOpsWiki