Помогите! Моя система почти остановилась!
Категория: Анализ производительности | Автор: admin | 21-06-2010, 00:16 | Просмотров: 2956

В предыдущих параграфах мы говорили в основном о том, что касается средней производительности системы. Для ее повышения требуется корректировать конфигурационные параметры или модернизировать систему.

Но даже правильно сконфигурированные системы иногда работают медленнее обычного. К счастью, нерегулярные проблемы в большинстве своем легко поддаются диагностированию. В 90% случаев они создаются алчным процессом, который потребляет так много ресурсов процессора или жесткого диска, что остальные процессы буквально останавливаются.

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

Первый шаг в установлении диагноза — запуск команд ps и top для выявления заведомо неуправляемых процессов. Любой процесс, потребляющий более 50% времени ЦП, можно с большой долей вероятности считать ненормальным. Если столь непомерную долю ресурсов ЦП не получает ни один процесс, посмотрите, сколько процессов получают минимум по 10%. Когда их больше двух-трех (не считая самой команды ps), то средняя нагрузка, скорее всего, будет очень высокой. Такая ситуация сама по себе является причиной низкой производительности. Проверьте среднюю загруженность системы с помощью команды uptime, а затем вызовите команду vmstat или sar -u, чтобы узнать, простаивает ли когда-нибудь процессор.

Если конкуренции за право использования центрального процессора не наблюдается, посмотрите путем вызова команды vmstat или sar -g, каков объем операций подкачки. Следует обращать внимание на все операции обмена с диском: множество операций выгрузки может означать соперничество за память, а наличие дискового трафика при отсутствии подкачки говорит о том, что какой-то процесс монополизировал диск, непрерывно читая и записывая файлы.

Способа непосредственного сопоставления дисковых операций и процессов не существует, но с помощью команды ps можно сузить круг подозреваемых. Любой процесс, вызывающий дисковый трафик, скорее всего, использует некоторую часть времени ЦП. Обычно всегда можно сделать обоснованное предположение о том, какой конкретно из активных процессов является истинным виновником интенсивной загрузки процессора. Для проверки своей теории на практике выполните команду kill -STOP.

Предположим, процесс-виновник найден. Что же делать с ним дальше? Как правило, ничего. Некоторые операции действительно требуют много ресурсов и неизбежно замедляют работу системы, но это вовсе не означает, что они незаконны. С помощью команды renice можно изменить приоритет процесса, для которого ограничивающим фактором является скорость ЦП, но не забудьте попросить владельца этого процесса впоследствии выполнить команду nice.

Процессы-пожиратели дисков и памяти нелегко поддаются воздействию. Команда renice обычно не помогает. Можно уничтожить или остановить процесс, но, на наш взгляд, такая мера оправдана только в экстренных ситуациях. Как и в случае с пожирателями времени ЦП, можно прибегнуть к непопулярной мере: попросить владельца запустить процесс позже.

Некоторые системы позволяют ограничивать потребление процессами физической памяти. Для этого служит системный вызов setrlimit. Обращение к нему возможно через встроенную команду limit интерпретатора С shell. Например, команда

% limit memoryuse 32m

 

ограничивает использование физической памяти для всех последующих пользовательских команд величиной в 32 Мбайт. Ее действие подобно действию команды renice в отношении процессов, ограничивающим фактором для которых является объем памяти. Можете тактично предложить "проблемным" пользователям вставить такую строку в свои файлы .cshrc.

Если источником снижения производительности не является неуправляемый процесс, нужно исследовать две другие вероятные причины. Первая — перегрузка сети. Многие программы настолько тесно связаны с сетью, что иногда трудно различить, где кончается производительность системы и начинается производительность сети. Подробная информация о средствах контроля над работой сети приведена в главе 20.

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

Еще одна причина кризисов производительности — задержки, связанные с серверами. UNIX-системы постоянно обращаются к удаленным серверам для вызова служб NFS, NIS, DNS и т.п. Если сервер не функционирует или какая-то иная проблема привела к тому, что связь с ним стала ненадежной, это ощущают на себе все системы-клиенты. Предположим, к примеру, что в интенсивно работающей системе какой-то процесс каждые несколько секунд вызывает библиотечную функцию gethostent(). Если сбой в работе службы DNS заставляет эту функцию тратить на свое выполнение две секунды, будет заметно общее снижение производительности.



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page