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

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

На рисунке 21.12 представлена трасса утилиты mpstat, полученная на сервере с 8-ю центральными процессорами.

Обратите внимание на то, что прерывания (intr) неравномерно распределены между всемн центральными процессорами. Центральные процессоры с номерами П, 14 и 18 обрабатывают большее количество прерываний, чем другие центральные процессоры. Они демонстрируют самую высокую системную (sys) активность, но при этом не самую высокую пользовательскую (usr) активность.

Во время загрузки операционной системы Solaris драйверы дисковых массивов и сетевых интерфейсов привязываются к определенным центральным процессорам. Эти центральные процессоры обрабатывают прерывания, связанные с этими устройствами, от имени всех остальных центральных процессоров. Обратите внимание также на то, что операционная система Solaris запланировала запущенные процессы на те центральные процессоры, которые не заняты обслуживанием прерываний (центральные процессоры 10, 15 и 19 показывают значительно более высокую пользовательскую активность).

Что можно сделать для того, чтобы оптимизировать использование ЦП

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

•             Необычно высокий уровень системных вызовов. Если отношение показателя user% к показателю system невелико, попытайтесь с помощью команды truss -с выявить основные системные вызовы тех процессов, которые наиболее интенсивно используют ресурсы ЦП. Если основной причиной являются операции чтения, то увеличение размера буферного кэша БД могло бы уменьшить количество таких операций.

•             Низкое отношение значений показателей context switches и involuntary context switches. На платформах, не относящихся к семейству Starfire, загрузите TimeShare Dispatch Table (диспетчерскую таблицу разделения времени) от Starfire (подробнее эти вопросы рассматриваются в главе 15).

•             Наличие одного или нескольких неэффективных приложений. Проконтролируйте процессы с помощью команды ps, чтобы выявить приложения, поглощающие "львиную долю" ресурсов ЦП. Плохо написанные приложения особенно преуспевают в этом, и именно с них следует начинать, когда вы пытаетесь освобождать ресурсы ЦП.

•             Неудачная настройка СУБД. Следующие главы могут помочь выявить ее неэффективное поведение. Высокий уровень конкуренции за защелку, например, может привести к неэффективному расходованию ресурсов ЦП. Но если конкуренция такого рода стала причиной интенсивного использования ЦП, то добавление центральных процессоров не всегда может помочь.

•             Недостаточность ресурсов ЦП, Если ваши центральные процессоры используются полностью или весьма интенсивно, и в очереди на запуск стоит намного больше процессов, чем имеется центральных процессоров, то скорее всего необходимо просто увеличить количество центральных процессоров. К счастью, операционная система Solaris масштабируется достаточно хорошо, поэтому добавление центральных процессоров вероятно поможет в ситуации нехватки ресурсов ЦП.

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

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

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


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