Проверка производительности системы
Категория: Анализ производительности | Автор: admin | 21-06-2010, 00:11 | Просмотров: 11092

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

 

Анализ использования центрального процессора

 

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

В большинстве систем требуемую информацию выдает команда vmstat, а в Solaris и HP-UX этой цели служит команда sar -u. Обе они принимают два аргумента: время (в секундах), в течение которого нужно наблюдать за системой для получения каждой строки выходной информации, и необходимое число отчетов. Например:

 

% sar -u 5 5

13:33:40       %usr    %sys    %wio    %idle

13:33:45          4      58      27       11

13:33:50          7      83       9          0

13:33:55          9      77       13        0

13:34:00          2      25        3       71

13:34:05          0       0        0      100

Average           4      49     10        36

 

 

Команда sar -u выдает данные о доле времени центрального процессора, затраченного на работу пользовательских программ (%usr), на выполнение кода ядра (%sys) и на простой. При наличии процессов, заблокированных в ходе выполнения высокоскоростных операций ввода-вывода (обычно это обращения к жесткому диску), время простоя добавляется в категорию %wio, в противном случае оно записывается в колонку %idle.

Команда vmstat выдает много разной информации. Сведения, касающиеся центрального процессора, приводятся в последних колонках:

 

% vmstat 5 5

procs               page                       faults        cpu

r b w   re  mf  pi  po  fr  de  sr  in        sy  cs       us  sy  id

0 0 0   0   0   0   0   0   0   0    4        22  19        2   1  97

1 0 0   67  2   0   0   0   0   0   26       751  52       53  47   0

0 0 0   96  0   0   0   0   0   0   39      1330  42       22  71   7

0 0 0   16  0   0   0   0   0   0   84      1626  99        7  74  19

0 0 0   1   0   0   0   0   0   0   11       216  20        1  11  88

 

 

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

Пользовательское время, системное время и время простоя показаны соответственно в столбцах us, sy и id. Большие числовые значения в столбце us обычно означают вычисления, а в столбце sy говорят о том, что процессы производят очень много системных вызовов или выполняют операции ввода-вывода (команда vmstat показывает число системных вызовов в секунду в столбце sy раздела faults). Выработанное нами за многие годы эмпирическое правило, справедливое для большинства систем, гласит, что система должна тратить примерно 50% рабочего времени на обслуживание пользовательских запросов и столько же времени — на системные запросы. Общее время простоя не должно быть нулевым. В колонке cs показано число переключений контекстов за данный период, т.е. сколько раз ядро переключало процессы. Слишком большое значение в данном столбце свидетельствует о неправильно работающем аппаратном устройстве.

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

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

Центральный процессор однопользовательской рабочей станции обычно тратит на простой 99% своего времени. Когда запрашивается прокрутка содержимого одного из окон, ЦП справляется с этой операцией за несколько секунд. В такой ситуации долгосрочный средний показатель использования ЦП практически не имеет смысла.

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

 

% uptime

2:07pm up 4:02,  5 users,  load average: 0.95,  0.38,  0.31

 

 

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

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

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

 

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

Еще один способ контроля над использованием ЦП — посмотреть, какую часть его времени потребляет каждый процесс. Для этого служит команда ps с соответствующими аргументами (-aux в Red Hat и FreeBSD, -elf в HP-UX и Solaris). Чаще всего оказывается, что в перегруженной системе минимум 70% времени ЦП потребляется одним-двумя процессами (помните о том, что команда ps сама занимает немного ресурсов). Запуск процессов-пожирателей в другое время суток или снижение их приоритетов позволит высвободить ЦП для выполнения других процессов.

Прекрасная альтернатива команде ps — программа top. Она выдает примерно ту же информацию, что и ps, но в "живом" формате, позволяющем наблюдать за изменением состояния системы во времени.

 

 

Управление памятью в UNIX

 

Память обычно организована в виде модулей, называемых страницами и имеющих объем минимум 4 Кбайт. Если эта величина превышает размер страницы, поддерживаемый центральным процессором или контроллером памяти, такие модули иногда называют "кластерами страниц". Дисковые блоки обычно меньше страниц памяти (1 Кбайт или 512 байт), поэтому ядро связывает с каждой записываемой страницей несколько блоков.

Операционная система UNIX старается управлять памятью так, чтобы страницы, к которым недавно обращались, хранились в памяти, а менее активные страницы "выгружались". Этот алгоритм известен под названием LRU (least recently used — замещение наименее используемых элементов), потому что те страницы, к которым долго никто не обращался, перемещаются на диск. Отслеживание всех обращений к страницам — слишком дорогое удовольствие для ядра, поэтому в большинстве версий UNIX используется статистический метод управления памятью, известный как "алгоритм часов". Он обходится гораздо дешевле системы LRU, а результаты дает такие же.

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

Если к "неиспользуемой" странице производится обращение до ее выгрузки (так называемая нестрогая ошибка), ядро изымает ее из списка и восстанавливает соответствие адресов в контроллере памяти. После этого страница находится в безопасности до следующего прохода стрелки. Обычно страницам, к которым обращаются нечасто, спастись не удается; их содержимое в конце концов переписывается на диск, и освободившиеся страницы можно использовать для других процессов[2].

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

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

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

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

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

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

"Воровать" страницы могут даже процессы, работающие с низким приоритетом. Предположим, например, что на рабочей станции выполняется моделирующая программа с очень низким приоритетом (и, соответственно, высоким значением nice), и одновременно с этим в окне терминала пользователь читает электронную почту. Как только пользователь делает паузу, чтобы прочесть сообщение, показатель использования ЦП падает до нуля и моделирующая программа получает разрешение на работу. Она активизирует все свои страницы, вытесняя из памяти интерпретатор команд, менеджер окон, программу чтения почты и, наконец, эмулятор терминала. Когда пользователь нажимает клавишу <N> для перехода к следующему сообщению, возникает длинная пауза, потому что большой блок памяти системы перекачан на диск. Таким образом, на практике высокое значение nice не гарантирует, что процесс с низким приоритетом не вызовет ухудшения производительности.

 

Анализ использования памяти

 

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

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

Данные об объеме используемой области подкачки можно получить с помощью команды swap -l в Solaris, spawinfo в HP-UX, swapon -s в Red Hat и pstat -s во FreeBSD. В Solaris есть также команда sar -r (как обычно, с аргументами, задающими интервал наблюдения), но по каким-то причинам она дает результат, не полностью совпадающий с результатом команды swap -l.

 

% swap -l

swapfile              dev     swapl     blocks    free

/dev/dsk/c0t0d0sl     32,1       16     164400    162960

 

% ear -r 5

17:58:52     freemem      freeswap

17:58:57     361          179616

 

% pstat -s

Device        lK-blocks  Used    Avail  Capacity        Type

/dev/wd0slb       70784  0             70656       0%           Interleaved

/dev/da0b       1048920  0      1048792     0%           Interleaved

Total           1119448  0      1119448     0%

 

 

Команда pstat позволяет узнать объем области подкачки в килобайтах, тогда как команды swap -l и sar -r — в 512-байтовых блоках. В число величин, сообщаемых этими командами, не входит объем ОЗУ, поэтому общий объем виртуальной памяти приблизительно можно оценить по такой формуле:

ВП = ОЗУ + используемый_объем_области_подкачки

 

В большинстве систем статистику страничных операций получают с помощью команды vmstat:

 

% vmstat 5 5

procs  memory                page               disk             faults

r b w  swap   free   re mf pi po fr de sr   s0  s6  s4 --    in   sy   cs

0 0 0   338216 10384   0  3  1  0  0  0  0    0   0   0  0   132  101    58

0 0 0  341784 11064   0 26  1  1  1  0  0    0   0   1  0   150  215   100

0 0 0  351752 12968   1 69  0  9  9  0  0    0   0   2  0   173  358   156

0 0 0  360240 14520   0 30  6  0  0  0  0    0   0   1  0   138  176    71

1 0 0  366648 15712   0 73  0  8  4  0  0    0   0  36  0   390  474   237

 

Информация об использовании центрального процессора в этом примере опущена. Под заголовком procs показано количество процессов, готовых к немедленному выполнению, заблокированных в ожидании ввода/вывода, а также готовых к выполнению, но перекачанных на диск. Если значение в колонке w когда-нибудь станет отличным от нуля, это будет означать, что объем системной памяти не соответствует текущей нагрузке.

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

В следующих семи колонках содержатся сведения о страничных операциях. Приведены средние значения (количество в секунду).

  • re — число возвращенных (восстановленных из списка неиспользуемых) страниц;
  • mf — число незначительных ошибок (связанных с небольшим числом страниц);
  • pi — объем подкачанных данных в килобайтах;
  • ро — объем выгруженных данных в килобайтах;
  • fr — объем списка неиспользуемых страниц в килобайтах;
  • de — объем "ожидаемого краткосрочного дефицита памяти" в килобайтах;
  • sr — число страниц, обработанных по алгоритму часов.

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

Команда vmstat -S выдает статистические данные не по страничным операциям, а по перекачке процессов.

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

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

Когда в системе имеет место непрерывный поток операций выгрузки, ей явно не хватает памяти. Если же выгрузка происходит лишь время от времени и не создает никаких проблем, на нее можно не обращать внимания. Если состояние системы — где-то посередине, дальнейший анализ будет зависеть от того, что нужно сделать: оптимизировать систему для интерактивного режима (например, как рабочую станцию) или сконфигурировать ее для одновременной работы пользователей (например, как сервер приложений).

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

 

Анализ операций обмена с диском

 

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

 

% iostat 5 5

   tty          sd0              sdl         nfsl                 cpu

tin  tout  kps  tps  serv   kps tps serv   kps  tps  serv    us sy wt  id

0      1    5    1   18     14   2    20    0     0     0    0  0  0   99

0     39    0    0    0       2   0    14    0     0     0    0  0  0   100

2     26     3    0   13      8   1    21    0     0     0    0  0  0   100

3    119    0    0    0     19   2    13    0     0     0    0  1  1   98

1     16    5    1   19     0    0     0    0     0     0    0  0  0   100

 

 

Колонки разделены по темам (в данном случае их пять: tty, sd0, sdl, nfsl и cpu). В разных системах выходная информация команды iostat выглядит по-разному (данный пример взят из Solaris).

В разделе tty содержатся данные о терминалах и псевдотерминалах. В общем-то, это неинтересная информация, хотя она и может оказаться полезной для оценки пропускной способности модема. В колонках tin и tout дается среднее суммарное число символов, введенных и выведенных всеми терминалами системы за секунду.

Информация о каждом жестком диске размещается в колонках kps, tps и serv: объем данных, пересланных за секунду (в килобайтах), общее количество пересылок за секунду и среднее время позиционирования головки в миллисекундах. Одно обращение к диску может затронуть сразу несколько его секторов, поэтому соотношение между числами, приведенными в столбцах kps и tps, говорит о структуре пересылок: то ли это несколько крупных пересылок, то ли множество мелких. Крупные пересылки более эффективны. Механизм вычисления времени позиционирования, похоже, работает только на некоторых дисковых накопителях и иногда дает странные результаты (к значениям, приведенным в данном примере, это не относится).

В некоторых системах поддерживается команда iostat -D, которая выдает данные об интенсивности использования каждого диска в процентах:

 

% iostat -D 5 5

sdl            sd2            sd3            sd5

rps wps util   rps wps util   rps wps util   rps wps util

0     0  1.3   0   0    0.3   0   0    0.5   1   1    4.2

9     8 41.1   1   0    1.8   1   0    2.4   6   8   34.8

11    4 48.4   0   1    2.0   0   0    0.0   3  11   32.6

8     0 15.6   0   0    0.0   0   0    0.0   3   0    9.2

0     0  0.0   0   0    0.0   0   0    0.0   0   0    0.0

 

 

Здесь интенсивность использования определяется в виде количества операций чтения и записи в секунду.

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

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

Для достижения максимальной производительности нужно помешать файловые системы, которые используются одновременно, на разные диски. Большинство компьютеров может работать с несколькими дисками параллельно, что значительно повышает пропускную способность дисковой подсистемы (это, однако, зависит от архитектуры шины и драйверов устройств). Например, данные и журнальные файлы Web-сервера имеет смысл размещать на разных дисках.

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

Особенно важно по возможности распределять между несколькими дисками область подкачки, поскольку подкачка обычно замедляет работу системы в целом. Это можно сделать в любой из систем, воспользовавшись либо командой swapon, либо командой swap, либо файлами конфигурации ядра (см. главу 8). Многие системы позволяют организовывать как выделенные разделы подкачки, так и файлы подкачки, записываемые в обычную файловую систему. Выделенные разделы более эффективны; если есть возможность выбора, файлами подкачки лучше не пользоваться.

В некоторых системах можно настроить каталог /tmp как "резидентную" файловую систему — это фактически то же самое, что и виртуальный диск ПК. Специальный драйвер выдает себя за драйвер диска, но на самом деле записывает данные в память. Этот прием приводит к уменьшению объема памяти, доступной для общего пользования, но значительно ускоряет чтение и запись временных файлов. Как правило, такой подход оказывается весьма эффективным. Более подробную информацию можно получить на man-страницах, посвященных команде tmpfs (Solaris), ram (Red Hat) или mfs (FreeBSD).

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

 

Виртуальный помощник Адриан

 

Администраторы операционной системы Solaris могут обращаться за помощью к Адриану, т.е. Адриану Коккрофту (Adrian Cockcroft). Он является экспертом компании Sun по вопросам производительности и занимается распространением собственных утилит анализа и настройки системы. Его пакет SymbEL (известный как SE) представляет собой интерпретатор языка, предназначенного для построения такого рода утилит. В пакет включен набор правил "Виртуальный Адриан", в котором обобщен многолетний опыт Адриана по настройке производительности операционной системы Solaris. Компания Sun официально не поддерживает этот пакет, но его можно загрузить с Web-узла Sun по следующему адресу

http://www.sun.com/sun-on-net/performance/se3

 

Команда procinfo: отображение данных о производительности в Red Hat

 

В Red Hat есть команда procinfo, которая выдает удобную сводку производительности системы. Примерно то же самое делает команда vmstat, но в менее понятной форме. Особенно полезна информация о прерываниях, отображаемая на персональных компьютерах. Если система не слишком загружена, запустите в отдельном окне команду procinfo -f, которая будет обновлять результаты каждые 5 секунд.

 

% procinfo

Linux 2.2.5-15 (root@porky.devel.redhat.com)  (gcc egcs-2.91.66) #1 [redhat]

Memory:  Total    Used     Free    Shared    Buffers    Cached

Mem:     30756   23908     6848      9084      12496      3968

Swap:   133016     224   132792

 

Bootup:  Tue May 2 12:26:13 2000    Load average: 0.08 0.02 0.01 1/26 16173

 

user  :      0:08:15.35   0.0%  page in :     774301 disk 1: 229922r 109442w

nice  :      0:00:00.00    0.0%  page out:     177675

system:      0:10:46.41    0.0%  swap in :        183

idle  : 30d 2:06:40.89 100.0%  swap out:         60

uptime: 30d 2:25:42.64          context :    7221865

 

irq 0 :    260074265  timer         irq 10 : 3032801    eth0

irq 1 :    8          keyboard      irq 13 : 1          fpu

irq 2 :    0          cascade [4]   irq 14 : 1905415    ide0

irq 6 :    3                        irq 15 : 5          idel

irq 8 :    2          rtc

 

 

Команда pstat: вывод статистических данных во FreeBSD

 

Еще одно полезное средство, имеющееся во FreeBSD, — команда pstat. Она отображает содержимое различных таблиц ядра в форме, почти понятной для пользователя. В выдаваемой информации нет никакой объединяющей темы. Команда просто извлекает из ядра все интересные данные. Возможны следующие виды отчетов:

  • дамп таблицы индексных дескрипторов (-i);
  • дамп таблицы процессов, более подробный, чем у команды ps ();
  • дамп таблицы открытых файлов (-f);
  • информация о состоянии всех терминалов (-t);
  • информация о заданном процессе (-u);
  • информация об использовании области подкачки (-s);
  • информация о степени заполненности таблиц ядра ().

 

Команда pstat -Т используется при конфигурировании ядра, так как она позволяет определить оптимальное значение параметра maxusers. К сожалению, эта команда показывает лишь малую толику того, на что влияет параметр maxusers, поэтому следует предусматривать значительный запас по этому параметру. Подробнее об этом рассказывалось в главе 12.



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


 
Логин
Пароль
 

 
Locations of visitors to this page