При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Вся введенная информация защищена.

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Вся введенная информация защищена.

My developerWorks:

Сообщения:

Выйти

Выбрать язык:

System Administration Toolkit: Мониторинг низкой производительности системы

Мартин Браун (Martin C. Brown), Внештатный автор и консультант компании MCslp

Мартин Браун – бывший руководитель IT подразделения с опытом работы в области межплатформенной интеграции. Обладая большим опытом разработчика, он создал динамические сайты для множества крупных клиентов, включая HP и Oracle, и на данный момент является техническим директором ресурса Foodware.net. В настоящее время Мартин в качестве внештатного автора и консультанта сотрудничает с корпорацией Microsoft, работает редактором (LAMP Technologies Editor) журнала LinuxWorld, является видным членом группы AnswerSquad.com. Его перу принадлежат книги на совершенно разные темы: от сертификации Microsoft, компьютеры iMac до программирования открытого исходного кода. При всем этом он продолжает плодотворно работать в области программирования для разных платформ и сред. Связаться с Мартином можно посредством его персонального веб-сайта по адресу http://www.mcslp.com.

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

Больше статей из этой серии

Пометить это!

Дата: 27.12.2007
Уровень сложности: средний
Активность: 1537 просмотров
Комментарии:

О данной серии

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

В начало

Причины падения производительности

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

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

Для диагностирования проблемы надо протестировать UNIX-систему с помощью нескольких доступных инструментов.

В начало

Выбор метода подключения

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

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

Консоль с большей степенью вероятности позволит войти в систему, потому что уже будет выполняться процесс login, который впоследствии и будет заменен shell. Если после загрузки окажется невозможно запустить какие-либо процессы через shell, то означает, что система исчерпала память, доступную под процессы; тогда одним из вариантов восстановления нормальной производительности будет перезагрузка.

Для перезагрузки системы используйте команды init или telinit для настройки уровня выполнения; 6-й уровень выполнения обычно является синонимом перезагрузки. Использование команд init/telinit наиболее предпочтительно для перезагрузки, поскольку они запускают только один процесс, который приводит к перезагрузке.

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

В начало

Использование uptime

Если похоже, что у системы упала производительность, то первая команда, которой следует воспользоваться, - это uptime. uptime сообщает текущее время и общее количество времени, в течение которого компьютер работает (время, которое прошло после последней перезагрузки), а также текущее число пользователей компьютера. Затем эта команда предоставляет три числа, которые показывают среднюю степень нагрузки за последнюю минуту, пять минут и 15 минут. Например

$ uptime
 18:28:54 up 10 days,  8:38,  2 users,  load average: 2.24, 5.34, 3.42

В этом примере, компьютер имел степень загруженности больше чем 2 за последнюю минуту, больше чем 5 за последние 5 минут и больше чем 3 за последние 15 минут.

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

В однопроцессной системе всю нагрузку на центральный процессор создает один процесс. Но из-за многозадачности UNIX средняя загрузка до двух пунктов в течение длительного времени (пятнадцати минут) считается нормальной.

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

Альтернативный способ оценки чисел состоит в том, чтобы смотреть на них, как на проценты; другими словами, если приведенные выше числа были из примера с одним центральным процессором, тогда компьютер был бы в состоянии справиться с загрузкой, если бы был на 224 процента быстрее.

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

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

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

В начало

Использование ruptime

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

Например, в листинге 1 выводится информация о компьютерах в небольшой сети:

Листинг 1. Информация о компьютерах небольшой сети

                
$ ruptime
bear          up 10+09:13,     2 users,  load 0.66, 0.68, 0.50
ultra3        up  6+01:16,     1 user,   load 0.00, 0.00, 0.00
atuin       down  4+00:52

Последний компьютер не вернул данные за 11 минут, поэтому он считается отключенным.

Для создания таких данных необходим демон rwhod (иначе in.rwhod), который должен быть запущен на каждом компьютере в локальной сети. Этот демон передает данные о локальном компьютере и получает данные от других компьютеров.

Механизм работы rwho/ruptime может тормозить сеть, особенно если в ней много компьютеров, из-за дополнительного трафика. Кроме того, сильно загруженный компьютер может быть ошибочно идентифицирован как выключенный, потому что у него не хватает ресурсов для передачи данных или данные, которые он передавал, уже успели устареть.

В начало

Отслеживание больших процессов

Если возникло подозрение, что проблема в чрезмерно большом или интенсивно используемом процессе, тогда нужно проанализировать результаты работы инструментом ps, ознакомиться с размером процесса, процентным соотношением использования памяти и загруженностью центрального процессора. На системах SVR4 (Solaris и AIX®) можно использовать следующую команду для получения списков процессов (см. листинг 2).

Листинг 2. Команда для вывода списков процессов

                
$ ps -A -o pcpu,pmem,rss,vsz,comm
%CPU %MEM  RSS  VSZ COMMAND
 0.2  0.0    0    0 fsflush
 0.1  0.2 1464 8288 /usr/lib/ssh/sshd
 0.1  0.1 1032 1320 ps
 0.0  1.0 9536 47608 /usr/openwin/bin/Xsun
 0.0  0.7 6312 10720 dtgreet
 0.0  0.6 6136 9352 /usr/sfw/sbin/snmpd
 0.0  0.4 3208 5720 /usr/lib/fm/fmd/fmd
 0.0  0.3 2808 8512 /usr/lib/ssh/sshd
 0.0  0.3 2800 8504 /usr/lib/ssh/sshd
 0.0  0.3 2768 8512 /usr/lib/ssh/sshd
 0.0  0.3 2368 4056 /usr/sbin/nscd
 0.0  0.2 2096 9176 /usr/dt/bin/dtlogin
...

Листинг 3 показывает, как выглядят результаты работы команды из предыдущего примера в системе BSD.

Листинг 3. Получение списка процессов в системе BSD

                
$ ps -A -o pcpu,pmem,rss,vsz,command|sort -n +3
%CPU %MEM    RSS      VSZ COMMAND
  0.0  0.0    152    27236 nfsd-server
  0.0  0.0    152    27236 nfsd-server
  0.0  0.0    152    27236 nfsd-server
  0.0  0.0    152    27236 nfsd-server
  0.0  0.0    152    27236 nfsd-server
  0.0  0.0    152    27236 nfsd-server
  0.0  0.0    152    27236 nfsd-server
  0.0  0.0    152    27236 nfsd-server
  0.0  0.0    164    27236 nfsd-master
  0.0  0.0    224    27240 /usr/sbin/update
  0.0  0.3   4364    29196 /usr/sbin/securityd
  0.0  0.2   2760    29288 jabberd -c /etc/jabber/jabber.xml -H
 /private/var/jabber/ -U jabber
  0.0  0.0    184    29300 nfsiod -n 4
0.0  0.2   3544    29712 /usr/sbin/configd
  0.0  0.0    500    30628 /usr/sbin/sshd -i
  0.0  0.0    260    30648 /usr/sbin/smbd -D
  0.0  0.0    736    30648 /usr/sbin/smbd -D
  0.0  0.1   1216    30700 /usr/sbin/sshd -i
...
  0.0  0.1   2180    50664 imapd: narcissus.mcslp.pri [192.168.0.110]
mc user.mc
  0.0  0.1   2184    50664 imapd: sulaco.mcslp.pri [192.168.0.101]
mc user.mc
  0.0  0.1   2204    50720 imapd: narcissus.mcslp.pri [192.168.0.110]
 buy user.buy
  0.0  0.1   2264    50720 imapd: sulaco.mcslp.pri [192.168.0.101] buy
 user.buy
  0.0  0.1   2272    50984 imapd: kernel.mcslp.pri [192.168.0.106] slp
 user.slp
  0.0  1.2  18348    54368 servermgrd -x
  0.0  0.2   3200    85920 /usr/sbin/named -f
  0.0  1.1  16820   122240 /usr/libexec/mysqld --basedir=/usr
 --datadir=/var/mysql --user=mysql --pid-file=/var/mysq
  0.0  0.5   8572   158164 /usr/libexec/slapd -d 0 -h ldap:///
 ldapi://%2Fvar%2Frun%2Fldapi
  0.0  0.0    204   289396 rpc.statd

В обоих случаях были отображены использование в процентах центрального процессора и памяти, что очень удобно для анализа производительности системы. Колонки 's' и 'stat'(для SVR4 и BSD, соответственно) показывают текущий статус процесса.

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

В начало

Использование iostat

Утилита iostat предоставляет информацию о терминале, дисковой активности и использовании центрального процессора. Ее первый параметр определяет интервал поступления отчетов, а второй - число отчетов. Например, листинг 4 показывает, как выдавать статистику каждые пять секунд.

Листинг 4. Получение статистических данных каждые пять секунд

                
$ iostat 5
   tty        dad1          sd1           nfs1           cpu
 tin tout kps tps serv  kps tps serv  kps tps serv   us sy wt id
   0    7 440  39   14    0   0    3    0   0    0    5 18  0 77
   0   39   2   0    0    0   0    0    0   0    0    0  0  0 100
   0   13   4   3    0    0   0    0    0   0    0    0  0  0 100
   0   13   0   0    0    0   0    0    0   0    0    0  0  0 100

Точная информация, которая показывается по умолчанию, варьируется от системы к системе; листинг 4 был из операционной системы Solaris. Листинг 5 был выполнен в системе BSD.

Листинг 5. Использование iostat в системе BSD

                
          disk1           disk0       cpu
  KB/t tps  MB/s   KB/t tps  MB/s  us sy id
 167.67   0  0.02  20.70   5  0.09   6  3 90
  0.00   0  0.00   0.00   0  0.00  15  3 82
  0.00   0  0.00   0.00   0  0.00  16  2 82
  0.00   0  0.00  14.33  24  0.33  18  4 79
  0.00   0  0.00   2.83   1  0.00  23  4 73

Разберемся сначала со статистикой центрального процессора. Колонки показывают, сколько времени в процентах использует пользователь (us), система (sy) в работе с центральным процессором и сколько времени он простаивает (id). Пользовательское время показывает, сколько времени процессор был занят выполнением задач пользователя. Время системы - это время, в течение которого процессор выполнял системные задачи (пока ожидал ввода/вывода). Время простоя показывает, сколько времени центральный процессор простаивал.

Информация о диске показывает насколько были загружены физические жесткие диски, обычно в транзакциях в секунду или по количеству переданных килобайт (мегабайт) в секунду. Большие цифры в этом разделе, особенно в сочетании с длительным ожиданием системы могут означать, что жесткий диск слишком медленный. Если оптимизировать приложение так, чтобы оно работало с двумя жесткими дисками, то это может поднять производительность.

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

В начало

Использование vmstat

Статистику, относящуюся к виртуальной памяти, можно получить с помощью утилиты vmstat. Как и iostat, она использует числовые параметры (см. листинг 6).

Листинг 6. Мониторинг использования памяти при помощи vmstat

                
$ vmstat 5
kthr      memory            page            disk     faults      cpu
 r b w   swap  free  re  mf pi po fr de sr dd s1 -- in   sy
cs us sy id
 0 0 0 2820888 809552 94 525 121 69 50 0 26 16 0  0 297 1342
272  9  4 87
 0 0 0 2824752 778872 2   7  0  0  0  0  0  0  0  0 229   34
109  0  1 99
 0 0 0 2824752 778872 0   0  0  0  0  0  0  2  0  0 233   28
116  0  0 100
 0 0 0 2824752 778872 0   0  0  0  0  0  0  0  0  0 228   26
110  0  0 100
 0 0 0 2824752 778872 0   0  0  0  0  0  0  0  0  0 229   28
111  0  0 100

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

Блок CPU/thread показывает процессы/потоки в столбце (r), блокированные процессы, которые ожидают ввода/вывода ресурсов (b) и те процессы, что были выгружены. Большие числа в колонке блокированных процессов являются признаком медленных жестких дисков. Большие числа в колонке свопинга показывает, что есть много процессов, использующих много памяти, которая должна выгружаться и подгружаться. Свопинг - это ресурсоёмкий процесс, который сильно нагружает систему.

Блок memory показывает число страниц, которые можно было бы выгрузить, если понадобится RAM (колонка free). Низкие значения в столбце swap показывают, что заканчивается пространство для свопинга. Само по себе это не является проблемой, если имеется достаточно физической памяти для нормальной работы приложений. Низкие величины в столбце free - это признак активного использования памяти, поэтому если запустить еще пару процессов, то система начнет использовать свопинг.

Блок page показывает страницы памяти, подкачанные на диск и выгруженные с него. Колонки key отображают pi/po (страниц подгружено/страниц выгружено), что отражает интенсивность обмена страницами. Высокая степень страничной подкачки файлов означает недостаток RAM; высокая частота развертки (колонка sr) указывает на потенциальное узкое место в памяти.

В начало

Использование top

Утилита top предоставяет полезную информацию о состоянии системы, активных процессах, нагрузке и статистике памяти. Существует много различных версий top, некоторые из них являются стандратными для ряда систем, а последняя версия этой утилиты поставляется с открытым исходным кодом. Информацию, которую она выводит, можно представить как комбинацию результатов работы утилит uptime, swap space и ps. Например, ниже представлен результат работы top версии 3.5.1 на операционной системе Solaris (см. листинг 7).

Листинг 7. Использование top

                
last pid:  9385;  load averages:  7.14,  2.98,  1.21
61 processes:  55 sleeping, 4 running, 1 zombie, 1 on cpu
CPU states:  0.0% idle, 93.8% user,  6.2% kernel,  0.0% iowait,
0.0% swap
Memory: 1024M real, 712M free, 125M swap in use, 2705M swap free

   PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
  9313 root       1  22    0   35M   34M run      0:03  8.87% cc1
  9349 root       1  22    0   21M   20M run      0:01  5.47% cc1
  9385 root       1  39    0 4320K 3904K run      0:00  0.38% as
  9384 root       1  29    0 3888K 3424K run      0:00  0.30% as
  9145 root       1  59    0 3736K 2144K cpu      0:00  0.11% top
  9180 root       1  59    0 1808K 1472K sleep    0:00  0.10% make
   486 root       1  59    0   46M 9536K sleep    0:00  0.03% Xsun
   548 root       1  59    0   10M 6360K sleep    0:00  0.03% dtgreet
   553 mc         1  49    0 8288K 1472K sleep    0:01  0.02% sshd
  9345 root       1  49    0 1328K  928K sleep    0:00  0.01% gcc
  9348 root       1  59    0 1328K  928K sleep    0:00  0.01% gcc
  9325 root       1  49    0 1328K  928K sleep    0:00  0.01% gcc
   599 mc         1  59    0 8288K 1488K sleep    0:00  0.00% sshd
  9312 root       1  59    0 1328K  928K sleep    0:00  0.00% gcc
     9 root      16  59    0 9464K 2016K sleep    0:06  0.00%
 svc.configd

Утилита показывает нагрузку на центральный процессор от отдельных процессов; например, в предыдущем примере видно, что производится компиляция нескольких файлов и нагрузку на центральный процессор, которую эти компиляции создают.

Нужно следить за состоянием процесса: высокое число выполняемых процессов может означать, что система перегружена (сравните выполняемые процессы с состоянием центрального процессора и средней нагрузкой на систему). Утилита top сама по себе создает дополнительную нагрузку на процессор, поэтому не следует ее часто вызывать. Можно задать интервал между вызовом top в секундах используя либо -s либо -d - опции к команде (в зависимости от конкретной операционной системы).

В начало

Использование SAR

В ситуациях, где нет возможности вести мониторинг сервера в реальном времени, но требуется мониторинг в случае, если сервер стал тормозить, можно использовать утилиту SAR (system activity reporter). Она записывает информацию в глобальный файл через определенные интервалы времени и затем эту информацию можно анализировать для определения причины низкой производительности.

Поскольку процесс, записывающий информацию, выполняется в фоновом режиме, он может использоваться для составления графика работы системы за длительный промежуток времени, который в свою очередь поможет идентифицировать причину проблемы. Информация записывается день за днем, месяц за месяцем через промежутки времени, которые задает пользователь. Эти данные записываются в /var/log/sa/saDD или /usr/adm/sa/saDD, где DD день месяца. Запуск SAR зависит от системы, и, обычно, нужно настроить cron, который будет автоматически запускать скрипт (sa1), который выполняет сбор данных. Другой скрипт sa2, может создавать ежедневный отчет, который пригодится для анализа работы системы. Например, ниже показан результат команды crontab, используемой для получения статистики производительности системы Solaris:

0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A

Как только информация была собрана, ее можно извлечь командой sar. Объем собранной информации может быть большим, а ее детализация очень высокой. Однако можно оценить количество и качество информации, применив параметр -A в команде SAR для получения текущей информации.

Листинг 8. Выводимая информация, генерируемая командой sar с параметром -A

                
11:49:38    %usr    %sys    %wio   %idle
13:20:00       1       1       0      99
13:40:01      19       5       0      76
14:00:00       0       0       0     100
14:20:00       0       0       0     100
14:40:01       0       0       0     100
15:00:00       0       0       0     100
15:20:00       0       0       0     100

Average        3       1       0      96

11:49:38   device        %busy   avque   r+w/s  blks/s  avwait  avserv

...
Average    dad1              1     0.3       5     365    47.3     4.5
           dad1,a            0     0.0       0       4    15.4     8.6
           dad1,b            0     0.0       0       0     0.0    13.8
           dad1,c            0     0.0       0       0     0.0     0.0
           dad1,d            1     0.2       3     143    53.0     3.9
           dad1,e            0     0.0       0      39   117.3     5.9
           dad1,h            0     0.0       1     178    29.0     4.6
           nfs1              0     0.0       0       0     0.0     0.0
           nfs2              0     0.0       0      31     0.5    14.5
           sd1               0     0.0       0       0     0.0     3.3

11:49:38 runq-sz %runocc swpq-sz %swpocc
13:20:00     2.0       2     0.0       0
13:40:01     5.3      15     0.0       0
14:00:00     0.0       0     0.0       0
14:20:00     0.0       0     0.0       0
14:40:01     1.5       0     0.0       0
15:00:00     0.0       0     0.0       0
15:20:00     0.0       0     0.0       0

Average      5.0       2     0.0       0

11:49:38 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s
13:20:00       0      11      97       0       1      89       0       0
13:40:01       0     803     100       4     381      99       0       0
14:00:00       0       0     100       0       0      39       0       0
14:20:00       0       0     100       0       0      56       0       0
14:40:01       0       0     100       0       0      61       0       0
15:00:00       0       0     100       0       0      48       0       0
15:20:00       0       0     100       0       0      32       0       0

Average        0     120     100       1      56      99       0       0


11:49:38 swpin/s bswin/s swpot/s bswot/s pswch/s
13:20:00    0.00     0.0    0.00     0.0     305
13:40:01    0.00     0.0    0.00     0.0     223
14:00:00    0.00     0.0    0.00     0.0     111
14:20:00    0.00     0.0    0.00     0.0     112
14:40:01    0.00     0.0    0.00     0.0     112
15:00:00    0.00     0.0    0.00     0.0     114
15:20:00    0.00     0.0    0.00     0.0     114

Average     0.00     0.0    0.00     0.0     152

11:49:38 scall/s sread/s swrit/s  fork/s  exec/s rchar/s wchar/s
13:20:00     526      39      26    0.64    0.59   38118   25779
13:40:01    2288     803     320    9.31    6.53  773352 1558934
14:00:00      22       2       2    0.01    0.01     342     186
14:20:00      20       2       2    0.00    0.00     150     128
14:40:01      20       2       2    0.01    0.00     153     128
15:00:00      26       3       3    0.01    0.02     326     167
15:20:00      29       3       3    0.02    0.03     641     272

Average      416     125      52    1.46    1.04  118615  232791

11:49:38  iget/s namei/s dirbk/s
13:20:00       2      31       3
13:40:01      29     385      25
14:00:00       0       1       0
14:20:00       0       0       0
14:40:01       0       0       0
15:00:00       0       1       0
15:20:00       0       2       0

Average        5      61       4

11:49:38 rawch/s canch/s outch/s rcvin/s xmtin/s mdmin/s
13:20:00       0       0      39       0       0       0
13:40:01       1       0     397       0       0       0
14:00:00       0       0       9       0       0       0
14:20:00       0       0       0       0       0       0
14:40:01       0       0       0       0       0       0
15:00:00       0       0      16       0       0       0
15:20:00       0       0      38       0       0       0

Average        0       0      72       0       0       0

11:49:38  proc-sz    ov  inod-sz    ov  file-sz    ov   lock-sz
13:20:00   53/16154    0 1732/69661    0  358/358     0    0/0
13:40:01   54/16154    0 15118/69661    0  358/358     0    0/0
14:00:00   57/16154    0 15120/69661    0  359/359     0    0/0
14:20:00   57/16154    0 15120/69661    0  359/359     0    0/0
14:40:01   57/16154    0 15120/69661    0  359/359     0    0/0
15:00:00   57/16154    0 15121/69661    0  359/359     0    0/0
15:20:00   57/16154    0 15127/69661    0  359/359     0    0/0


11:49:38   msg/s  sema/s
13:20:00    0.00    0.00
13:40:01    0.00    0.00
14:00:00    0.00    0.00
14:20:00    0.00    0.00
14:40:01    0.00    0.00
15:00:00    0.00    0.00
15:20:00    0.00    0.00

Average     0.00    0.00

11:49:38  atch/s  pgin/s ppgin/s  pflt/s  vflt/s slock/s
13:20:00   13.39    3.67    5.05   41.14   77.09    0.00
13:40:01  188.44    9.91   25.61  373.73 1086.42    0.00
14:00:00    0.30    0.05    0.06    0.61    1.59    0.00
14:20:00    0.16    0.00    0.00    0.34    0.76    0.00
14:40:01    0.20    0.00    0.00    0.48    1.01    0.00
15:00:00    0.72    0.01    0.01    0.98    2.37    0.00
15:20:00    0.89    0.02    0.02    1.43    3.47    0.00

Average    29.66    1.90    4.38   60.43  170.40    0.00

11:49:38  pgout/s ppgout/s pgfree/s pgscan/s %ufs_ipf
13:20:00     0.03     0.06     0.06     0.00     0.00
13:40:01     6.41    19.18    13.84     0.00     0.00
14:00:00     0.00     0.00     0.00     0.00     0.00
14:20:00     0.00     0.00     0.00     0.00     0.00
14:40:01     0.00     0.00     0.00     0.00     0.00
15:00:00     0.00     0.00     0.00     0.00     0.00
15:20:00     0.00     0.00     0.00     0.00     0.00

Average      0.95     2.83     2.05     0.00     0.00

11:49:38 freemem freeswap
13:20:00  109186  5736615
13:40:01   95816  5614822
14:00:00   97408  5649849
14:20:00   97311  5647409
14:40:01   97418  5653711
15:00:00   97338  5648982
15:20:00   97333  5648993

Average    98516  5654784

11:49:38 sml_mem   alloc  fail  lg_mem   alloc  fail  ovsz_alloc  fail
13:20:00 4178176 3572465     0 38477824 32137880     0    14663680     0
13:40:01 16572672 10204085     0 99106816 80782488     0    15310848
    0
14:00:00 16589056 10261693     0 99106816 80797968     0    15343616
  0
14:20:00 16589056 10259613     0 99106816 80736600     0    15343616
    0
14:40:01 16589056 10260061     0 99106816 80820088     0    15343616
 0
15:00:00 16589056 10267477     0 99106816 80902432     0    15343616
    0
15:20:00 16589056 10274757     0 99106816 80864920     0    15343616
   0

Average  14813733 9300022     0 90445528 73863192     0    15241801
  0

Результат работы этого примера был сокращен для большей наглядности. Подробное описание SAR см. в разделе ресурсы и справке man операционной системы.

В начало

Резюме

Хотя не всегда можно выяснить причину медленной работы UNIX-системы, пользуясь только статистическими данными, администратору сразу после обнаружения падения производительности надо собрать как можно больше данных. В зависимости от ситуации это можно сделать активно (с помощью ps, uptime и других утилит) или пассивно (используя SAR или top). Информация, предоставляемая этими утилитами, помогает выяснить, тормозит ли UNIX-система из-за перегрузки центрального процессора, недостатка физической памяти (при интенсивной подкачке) или же корень проблемы в вышедшем из под контроля процессе, который не освободил центральный процессор.

Ресурсы

Научиться

"System Administration Toolkit: Monitoring a slow system (EN)" (developerWorks, июнь 2006): оригинал статьи.
"System Administration Toolkit: Process administration tricks (EN)" (developerWorks, февраль 2006): информация о команде ps, а также о мониторинге и контроле процессов.
System Administration Toolkit : другие статьи этого цикла.
alphaWorks technologies:сайт alphaWorks с различной информацией по AIX и UNIX.(EN)
"Easy system monitoring with SAR (EN)" (developerWorks, февраль 2006): в статье подробно описана утилита SAR.
"Performance tuning UNIX systems (EN)" (developerWorks, апрель 2006): механизмы управления процессами.
AIX® and UNIX articles (EN): другие статьи, написанные Мартином Брауном (Martin Brown)
Разделы библиотеки информации по AIX и UNIX(EN):
AIX и UNIX: в данном разделе сайта developerWorks можно найти разнообразную информацию, относящуюся ко всем аспектам системного администрирования AIX и помогающую усовершенствовать квалификацию работы с UNIX.(EN)
Новичок в AIX и UNIX?: страница AIX и UNIX для новичков.
AIX 5L Wiki: совместная разработка документации AIX.(EN)
developerWorks technical events and webcasts: новости о последних событиях и web-конференциях сообщества developerWorks.(EN)
Podcasts: аудиозаписи презентаций технических экспертов IBM.(EN)