Следует заметить, что специалисты не рекомендуют использовать команду uptime для анализа производительности. Ею можно воспользоваться, чтобы узнать как долго система работает, но понятие load является довольно устаревшим и бесполезным в Solaris, тем более что load меняется на различных стстемах: load 10 может указывать слабую активность на одной машине, но повышенную на другой. Если вам кажется что сервер стал работать медленней, используйте команду vmstat 5 вместо uptime.
Поиск «узких» мест, влияющих на производительность сервера, рекомендуется начинать с анализа статистики использования памяти. Зачастую недостаток памяти ошибочно диагностируется как медленный доступ к диску или нехватка процессорной мощности. Для получения статистики применяйте команду vmstat c определенным временным интервалом:
# vmstat 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m0 m2 m1 m1 in sy cs us sy id
0 0 0 3808016 900600 47 144 11 1 1 0 1 2 1 2 0 598 640 503 1 0 99
0 0 0 2880440 367992 0 8 0 0 0 0 0 1 1 1 1 516 454 307 0 0 100
0 0 0 2880376 367864 0 1 0 0 0 0 0 1 0 1 0 567 431 341 0 0 100
0 0 0 2880376 367768 0 0 0 0 0 0 0 1 1 1 1 538 383 319 0 0 100
0 0 0 2880352 367680 37 180 71 0 0 0 0 5 3 3 3 572 1112 475 0 0 100
0 0 0 2880352 367592 0 0 0 0 0 0 0 1 1 1 1 557 431 333 0 0 100
0 0 0 2880352 367512 0 0 0 0 0 0 0 1 1 1 1 562 409 332 0 0 100
0 0 0 2880352 367440 0 0 0 0 0 0 0 0 0 0 0 491 365 300 0 0 100
0 0 0 2880352 367368 208 238 0 0 0 0 0 1 0 1 0 552 2159 318 1 0 98
Всегда игнорируйте первую линию любой stat-команды. Она не содержит никакой полезной информации, потому что содержит данные за все то время пока система работает. Эти данные охватывают слишком долгий промежуток времени и не говорят ничего относительно использования системы в течение этого времени.
В первую очередь следует обратить внимание на значения в колонке sr (scan rate). Они показывают число страниц памяти, которые ядро операционной системы просматривало в попытке найти свободную страницу. Когда указанная величина в колонке sr возрастает, одновременно увеличивается значение в колонке po (page-outs), показывающее число страниц физической памяти, выгружаемых на диск в область swap. Если такая ситуация наблюдается постоянно, то серверу не хватает памяти для выполнения задач, и из-за этого падает производительность.
Колонку free лучше полностью игнорировать, поскольку ее показатели ни в коем случае не соответствуют тому, что подразумевается под свободной памятью. Так как памятью управляет пограммное обеспечение Solaris, в колонке free не считаются должным образом множественные процессы, использующие одни и те же или все еще невостребованные страницы памяти. Кроме того растущий файл кэша потребляет все больше свободной памяти для улучшения производительности. Поэтому показатель free имеет тенденцию устойчиво уменьшаться по мере продолжительности работы системы, когда фактически система эффективно перераспределяет и многократно использует память. Для лучшей картины доступной виртуальной памяти можно использовать команду swap:
# swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0t1d0s0 227,6 16 4093712 4093712
# swap -s
total: 494360k bytes allocated + 35568k reserved = 529928k used,
25137440k available
Если free из первой команды и available из второй не равны нулю - система в порядке и вам не стоит беспокоиться по поводу памяти.
При поиске «узких» мест нужно обратить внимание и на статистику загрузки процессоров. Детальную информацию можно получить с помощью команды mpstat:
# mpstat 5
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 19 0 602 301 164 71 0 2 75 0 79 2 2 0 96
1 9 0 24 5 0 8 0 2 67 0 15 0 0 0 100
2 5 0 18 4 0 5 0 1 64 0 9 0 0 0 100
3 5 0 19 3 0 5 0 1 63 0 8 0 0 0 100
4 5 0 159 14 1 23 0 1 66 0 28 1 0 0 99
5 4 0 146 14 1 22 0 1 65 0 27 1 0 0 99
6 4 0 141 11 0 20 0 1 64 0 24 1 0 0 99
7 4 0 155 10 0 19 0 1 64 0 24 1 0 0 99
8 9 0 147 12 0 24 0 1 65 0 32 1 1 0 98
9 4 0 143 11 0 21 0 1 64 0 24 1 0 0 99
10 4 0 134 16 4 20 0 1 64 0 24 1 0 0 99
11 4 0 161 12 2 18 0 1 66 0 24 1 0 0 99
12 10 0 146 33 21 22 0 1 67 0 32 1 1 0 98
13 4 0 162 42 31 22 0 1 68 0 24 1 1 0 99
14 4 0 128 10 0 18 0 1 64 0 23 1 0 0 99
15 4 0 145 10 0 19 0 1 63 0 25 1 0 0 99
Важными для анализа являются следующие показатели:
- xcal - число межпроцессорных вызовов. Межпроцессорные вызовы используются, например, при отправке сигнала от одного процессора другому для проверки целостности содержимого страницы виртуальной памяти
- intr - число обрабатываемых прерываний доступа к диску
- csw - число переключений контекста. Переключение контекста обычно происходит, когда процессор переключается на выполнение другого процесса или потока (thread)
- icsw - число принудительных переключений контекста. Принудительное переключение контекста с одного процесса на другой имеет место, когда процесс не завершил работу, но планировщик определил, что отведенный для выполнения работы временной интервал исчерпан
- smtx - число ожиданий ресурсов ядра. Ресурсы ядра используются при каждом системном вызове. Если один из процессов выполняет системный вызов, то он блокирует данный ресурс ядра, и остальные процессы, которым нужно осуществить тот же системный вызов, вынуждены ждать
- usr - процент процессорного времени, затраченный на выполнение процессов в пользовательском режиме (обычный режим прикладных задач)
- sys - процент процессорного времени, затраченный на выполнение процессов в системном режиме (режим системных вызовов и процессов ядра)
- wt - процент процессорного времени, затраченный на ожидание процессором выполнения запроса на ввод/вывод (например, на завершение диском операции чтения)
- idl - процент времени нахождения процессора в бездействии
Если значения в колонке idl постоянно близки к нулю, значит, серверу не хватает процессорной мощности для выполнения задач. Обратное не всегда верно. Время, которое процессор тратит на обработку прерываний сетевого ввода/вывода (и ряда других), учитывается как idl, поскольку приоритет таких прерываний выше, чем приоритет прерываний таймера сбора статистики. В результате якобы бездействующий сервер (высокие значения idl) в действительности может быть занят обработкой сетевого трафика. Помимо описанной возможен и ряд других подобных ситуаций, когда необходимо учитывать значения приведенных показателей в комплексе:
- Высокие значения intr,idl и низкие значения usr свидетельствуют о перегруженности сервера обработкой прерываний I/O
- Высокие значения intr,sys и низкие значения usr свидетельствуют о перегруженности сервера обработкой прерываний I/O, кроме случаев когда сервер обслуживает NFS
- Высокие значения intr и wt свидетельствуют о том,что выполнение запросов на I/O занимает слишком много времени. Возможно,что причина кроется не в недостатке процессорных мощностей, а в наличии проблемы в подсистеме I/O, используйте дополнительно статистику iostat
- Высокие значения smtx и sys или idl свидетельствуют о недостатке процессорных мощностей для выполнения системных вызовов
- Высокие значения icsw свидетельствуют о недостатке процессорных мощностей
- Высокие значения sys, csw или xcal и низкие значения usr свидетельствуют о недостатке процессорных мощностей в том случае, если наблюдается падение производительности приложений, иначе эти значения можно проигнорировать
Аналогично командам vmstat и mpstat, внимания заслуживает только часть показателей, выдаваемых командой iostat:
# iostat -zxcn 5
cpu
us sy wt id
1 0 0 99
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
0.4 1.3 8.8 13.1 0.0 0.0 0.7 7.1 0 1 d0
0.2 0.3 0.7 1.7 0.0 0.0 1.5 7.3 0 0 d2
0.2 1.3 4.4 13.1 0.0 0.0 0.0 2.3 0 0 d10
0.1 0.3 0.3 1.7 0.0 0.0 0.0 3.6 0 0 d12
0.2 1.3 4.4 13.1 0.0 0.0 0.0 6.7 0 0 d20
0.1 0.3 0.4 1.7 0.0 0.0 0.0 7.3 0 0 d22
0.5 18.0 19.9 262.6 0.0 0.1 0.0 2.9 0 1 c0t0d0
0.5 17.7 19.8 262.6 0.0 0.1 0.0 7.5 0 3 c0t1d0
К ним относятся:
kr/s - число килобайт, прочитанных с диска за секунду
kw/s - число килобайт, записанных на диск за секунду
wait - число запросов ввода/вывода, ожидающих обслуживания
wsvc_t - среднее время ожидания в очереди на обслуживание (в миллисекундах)
asvc_t - среднее время обслуживания запроса на ввод/вывод (в миллисекундах)
Если последние три показателя близки к нулю, то это означает, что серверные диски достаточно быстрые, а ввод/вывод оптимально распределен между контроллерами и не создает «узких» мест, т. е. «все в норме». На практике для диска, находящегося под нагрузкой, значения показателя asvc_t будут не нулевые, поскольку любому диску требуется некоторое время на исполнение запросов ввода/вывода.
К сожалению, встроенная в Solaris команда netstat выдает очень ограниченный набор информации, на основании которой можно было бы сделать адекватные выводы о проблемах с производительностью сети:
# netstat -I bge0 5
input bge0 output input (Total) output
packets errs packets errs colls packets errs packets errs colls
5655156 0 5397453 0 0 8063090 0 7760091 0 0
208 0 152 0 0 282 0 224 0 0
212 0 165 0 0 326 0 275 0 0
252 0 165 0 0 271 0 180 0 0
Нужно обратить внимание лишь на то, чтобы число ошибок (errs) и коллизий (colls) было близко или равнялось нулю.
Остается добавить что как и когда собирается статистика также важно, как то, какими командами вы пользуетесь. Обычно, в многопользовательской системе статистику собирают в течение дня, если же на сервере работает база данных и загрузка увеличивается ночью, когда выполняется много фоновых заданий, анализ системы также необходимо проводить в ночное время. Для сбора статистики ночью можно использовать простой shell-скрипт для любой stat-команды, который пишет timestamp-лог в /var/tmp:
#!/bin/sh
# nightstats - Script for unattended stat collection
if [ $# -lt 2 ]; then
echo "Usage: $0 stat args ..." >&2
exit 1
fi
# some basic vars holding date, etc.
stat=$1
shift
date=`date +%Y%m%d`
logfile=/var/tmp/$stat.$LOGNAME.$date
# run the stat, writing output to our logfile
exec 1>$logfile
echo "Running -$stat $@- as -$LOGNAME-"
while true
do
date
$stat "$@"
done
С помощью данного скрипта получаем timestamps в каждом определенном отрезке времени. Так, если запустить:
получим timestamp-лог каждые 12 повторов. Если необходимо остановить работу скрипта, процесс придется убить вручную. Скрипт можно запускать в фоновом режиме или использовать cron. Например:
# nohup nightstats vmstat 5 300 2>/dev/null &
# nohup nightstats iostat -xcnz 5 300 2>/dev/null &
На следующий день у вас на руках будет файл системного журнала, распологающийся в /var/tmp, с timestamps каждые пять минут. Каждый файл будет иметь название, состоящее из имени stat-команды, дате и вашего логина ($LOGNAME автоматически подставляет логин в скрипт). Таким образом можно собирать статистику в течение того времени, когда сервер кажется наиболее загруженным. Для сравнения также следует иметь статистику на тот период, когда система не загружена - иначе трудно будет выяснить, какие данные меняются при изменении нагрузки.
Многие пытаются моделировать загруженность системы, однако польза от этого способа не велика. Например, общая практика использования команды dd для записи на диски - обычно непоказательная мера загрузки ввода/вывода. Так как dd читает и пишет последовательно, большинство обращений к диску случайны и представляет из себя непредсказуемую комбинацию чтений и записей. Такая модель могла бы выглядеть прекрасно в теории, но - плохо работает в реальном приложении. Лучше всего поднять полноценный испытательный сервер, с теми приложениями и нагрузкой, которые вы хотите проанализировать.
(По материалам "Sun Fire Systems Design and Configuration Guide") 
