Продолжение углубленного анализа Мониторинг процессов

Оценить
(0 голоса)

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

процессы, потребляющие большую часть ресурсов ЦП, следует воспользоваться командой /usr/ucb/ps -aux или, начиная с Solaris 8, утилитой prstat. Обратите внимание на то, что процесс ps сам по себе является достаточно серьезным потребителем ресурсов ЦП, особенно в системах, где выполняется большое количество процессов. Утилита sdtprocess, поставляемая как составная часть пакета CDE в составе операционной системы Solaris, предлагает полезное представление тех же самых данных на основе XI1.

Столбец TIME также показывает, что каждый процесс-пожиратель использовал по 5 минут времени ЦП. Насколько сильно это повлияет на производительность, будет зависеть от количества активных центральных процессоров и от количества других, одновременно выполняемых процессов. Столбец %СРО показывает процентную долю использования ресурсов всех доступных центральных процессоров, а не отдельно взятого центрального процессора. В приведенном примере каждый из двух таких процессов использует один полный процессор из имеющихся восьми (следовательно, 12.5 % ресурсов центральных процессоров). Чтобы выяснить, чем занимаются эти процессы, потребляющие большую часть ресурсов ЦП, можно воспользоваться утилитами pstack и truss.

Рисунок 21.11 иллюстрирует метод обнаружения процесса, потребляющего большую часть ресурсов ЦП (с помощью команды ps), а затем формирование списка системных вызовов, запущенных этим процессом (с помощью утилиты truss).

Преобладают системные вызовы read, а непосредственно за ними следуют системные вызовы lseek. Использование системного вызова lseek указывает на то, что данное приложение не использует системный вызов pread(2), который экономит количество системных вызовов за счет устранения необходимости в системных вызовах lseek(2).

Мониторинг прерываний
Пятый этап. Мониторинг и настройка СУБД
Буферный кэш
Пристальный взгляд на удачные попадания в кэш
Приемлемая частота успешных обращений к кэшу

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


Защитный код
Обновить