 |
|
|
|
Проводим мониторинг нагрузки операционной системы Solaris
Проводим мониторинг нагрузки операционной системы Solaris Вы установили своё новое приложение (например, СУБД) на сервере с операционной системой Solaris. Сначала всё шло хорошо, пользователи были довольны, но со временем появились жалобы, производительность работы значительно снизилась, и вы задумались о модернизации оборудования. Не стоит этого делать наугад. Прежде чем принимать решение о замене сервера, определите, каких именно ресурсов не хватает. Сразу после развёртывания приложения, как правило, проводятся измерения исходной рабочей нагрузки. Впоследствии необходимо вести периодические измерения использования ресурсов системы: оперативной памяти, подсистемы дискового ввода-вывода, сети и центрального процессора, чтобы выявлять «узкие места», препятствующие производительной работе системы. Предлагаемая методика известна давно (её подробное описание приведено, например, в [1]) и в целом применима к любому компьютеру, под управлением любой универсальной операционной системы. Тут мы рассмотрим её упрощённый вариант для предварительной оценки загрузки серверов под управлением операционной системы Solaris, с использованием команд и скриптов, которые пришлись мне по душе больше, чем стандартные команды UNIX. Будем рассматривать по порядку сначала загрузку оперативной памяти, потом дисков, сети и, наконец, процессоров. Такой порядок объясняется тем, что нехватка памяти может внести погрешность в определение нагрузки на диски, а загрузка дисков или сети – в определение загрузки процессора. В качестве тестового сервера используются SUN Fire v440 (4X1593МГцX8Гб) и операционная система Solaris 8. Мониторинг памяти При настройке оперативной памяти главная цель – избежать её дефицита. Если запросы приложений к памяти превышают имеющиеся ресурсы, «рабочие наборы» (working sets) выполняющихся процессов станут существенно меньше, чем необходимо для комфортной работы, возникнет избыточная подкачка страниц оперативной памяти. По интенсивности подкачки страниц судят о потребности в памяти. Традиционно наличие подкачки страниц определяют с помощью команды vmstat. Например, вывод команды vmstat при малой загрузке ОЗУ: # vmstat 3
Анализируя колонки sr (scan rate) и po (page out), пытаются оценить интенсивность подкачки. Если значения в этих колонках не сильно отклоняются от среднестатистических, взятых за эталон благополучия значений (допустим, пускай эталоном будет полное отсутствие подкачки: sr=0 и po=0), можно считать, что проблемы подкачки нет. Еще одна команда – sar. Вывод команды sar при малой загрузке ОЗУ: # sar -g 5 5
Сплошные нули в колонках не являются самоцелью, это скорее показатель избытка оперативной памяти. В нормально работающей системе всегда кто-то запрашивает дополнительную память, кто-то её освобождает, пишет или читает, но если обычная нагрузка была 100, а стало 100 000, это плохой знак. В операционной системе Solaris система виртуальной памяти, кеш файловой системы и каталог /tmp используют общий пул свободной оперативной памяти, распределяемый динамически, вследствие чего колонка free в выводе команды vmstat малоинформативна. Проверим, что происходит с файлом подкачки:
Вывод команды iostat при низких объёмах подкачки: # iostat -zxnp 1
Мы видим, что подкачки практически нет. И на последок, в ОС Solaris (начиная с версии 8) есть чудесная команда «vmstat -p». Для версии 7 можно скачать команду «memstat» [2]. Вывод команды vmstat с опцией -p: # vmstat -p 2 5
Её достоинство в том, что кроме scan rate, мы можем видеть показатели page-in/page-out/page-frees по отдельности для executable/anonymous/filesystem страниц памяти. Рассмотрим пример:
Вывод команды vmstat, демонстрирующий активность кеша файловой системы: $ vmstat -p 1
До версии 7 операционной системы Solaris страницы файлового кеша и страницы памяти, отображаемые на swap, имели одинаковый приоритет, вследствие чего активность дискового кеша вносила путаницу в потребности в памяти. В версии 8 и выше эта проблема устранена. Если в последних трёх колонках мы видим большие цифры, то, возможно, пора переходить к проверке дисков (в данном случае работает команда find). А вот если присутствуют большие значения в колонке api, apo, apf, то необходимо проверить запросы процессов к памяти системы. Выполним команду prstat с сортировкой по объёму виртуальной памяти: $ prstat -a -s size
Вывод этой команды показывает процессы, отсортированные по размеру используемой виртуальной памяти (а с ключем -s rss резидентной памяти), и суммарные показатели по имени пользователя. Это даёт возможность определиться с дальнейшими поисками «виновного». Мониторинг дискового ввода-вывода Следить за загрузкой дисков существенно проще. Проведём несколько тестов. Например, с помощью пакета iozone [3]. Откроем несколько терминальных сессий и запустим команды. В первой сессии:
Как видно, большая часть времени в приложении расходуется на ожидание, а время, затраченное процессором, тратится большей частью в режиме sys, а не user. Во второй сессии выполним следующую команду – iostat, получим вывод команды при большой нагрузке на файловую систему: $ iostat -zxnp 1
Команда показывает ввод-вывод по разделам дисков. Если добавить к этой команде ключ -C – «iostat -zxnpC 1», к показанной статистике прибавятся агрегированные показатели по контроллерам. Конкретные цифры, конечно же, строго индивидуальны, но если объёмы (kr/s, kw/s) или время операции ввода-вывода (asvc_t/actv) значительно выше обычного, это говорит о повышенной нагрузке на систему дискового ввода-вывода. Ещё один важный параметр %b – степень загруженности диска (в процентах от времени интервала измерения). Часто он даже важнее, чем значения объёмов передаваемых данных kr/s и kw/s, поскольку дисковые операции могут отличаться по размеру фрагмента (большие и маленькие), кратности (кратные размеру блока и произвольной величины) и способу доступа (с последовательным и произвольным доступом). В отдельной сессии рассмотрим, как работает во время теста процессор системы. Запустим команду «sar -u 1 5». Мы можем наблюдать повышенное значение в колонках %sys и %wio, которое служит одним из признаков присутствия нагрузки ввода-вывода и иллюстрирует возможную погрешность, которая может возникнуть, если мы начнём анализ нагрузки с наблюдения за процессором. Вывод команды sar во время операций ввода-вывода: $ sar -u 1 5
Проведём аналогичный тест для накопителей на гибких магнитных лентах. Получаются аналогичные результаты. $ dd if=/dev/zero of=/dev/rmt/0 bs=1024k count=200000 … Вывод команды iostat во время записи на магнитную ленту: $ iostat -zxnp 1
Вывод команды sar во время записи на магнитную ленту: $ sar -u 1 5
Если с точки зрения памяти или процессоров у нас всё в порядке, тогда нам осталось рассмотреть сеть и процессор. Мониторинг сети Начнём, как всегда, с теста. Снова создадим несколько сессий: в одной запускаем тест сети. В другой – команду «sar -u 1 5», в третьей – команду «netstat». $ /usr/sbin/spray datatarget -c 100000000 … Вывод команды sar при работе приложения, нагружающего сеть: $ sar -u 1 5
Вывод команды netstat – количество пакетов, передаваемых по сети: $ netstat -I ce0 1
Команда netstat показывает количество пакетов, принимаемых и передаваемых сетевым интерфейсом. По результатам вывода команды «sar -u» мы видим, что при данном тесте создаётся нагрузка на процессор (колонки %usr и %sys). Современные Ethernet-адаптеры подключаются к коммутаторам в режиме full-duplex, по этой причине возникновение ошибок и коллизий маловероятно и является не столько индикатором избыточной нагрузки на сеть, сколько показателем аппаратных проблем. Поэтому более интересен объём трафика в килобайтах в секунду. Можно воспользоваться утилитой ifstat [4]. Вывод команды ifstat – количество килобайт, передаваемых по сети: $ ifstat -t 1
Если сетевая подсистема не является «бутылочным горлышком», перейдём к проверке загрузки процессора. Мониторинг загрузки процессора Мониторинг центрального процессора является последним этапом. Запустим какое-нибудь «CPU-bound»-приложение и команду «sar -u 1 5». Вывод команды sar при работе приложения, нагружающего процессор: $ sar -u 1 5
Колонки %usr и %sys показывают в сумме процент времени, в течение которого процессор был занят. Колонки %wio и %idle показывают в сумме процент времени, в течение которого процессор простаивал. Часто ошибочно к суммарной загрузке процессора прибавляют %wio, это неправильно. В случае большого процента %wio при запуске ресурсоёмкого приложения с точки зрения процессора эти такты будут отдаваться ему. Рассмотрим случай, когда присутствуют два вида нагрузки: на диск и на процессор. Воспользуемся командой vmstat, приложение использует диск и процессор: $ vmstat 1
Последние три колонки показывают нагрузку на процессор usr, sys, idl (%wio + %idle). Вот что показывает одновременно запущенная команда «sar -u», нагрузка на диск и процессор: $ sar –u 1 5
Еще одним интересным показателем в листинге вывода команды vmstat является первая колонка – r под заголовком procs, которая показывает количество процессов, готовых к выполнению и ожидающих, когда для них освободится процессор. Если при значении idl=0 это число значительно больше, чем число процессоров, то это говорит о нехватке ресурсов процессора, особенно если очередь ещё и растёт. Если в системе несколько процесоров, посмотреть нагрузку по процессорам поможет команда mpstat, посмотрим некоторую произвольную нагрузку: $ mpstat 1
Значение %ildle во всех приведенных листингах говорит только о том, что процессоры системы простаивают. А вот значение этого параметра близкое к нулю – не обязательно катастрофа. Возможно, ваш сервер – это файловый сервер, и, несмотря на то что значение %wio большое, вы довольны скоростью файловых операций, или ваше приложение, послав запрос по сети, находится в состоянии бесконечного цикла ожидания ответа удалённой системы, и вас это устраивает. Желательно иметь некоторый запас (но и не слишком избыточный), например 20%, на случай пиковых нагрузок. Теперь найдём самые затратные с точки зрения процессора приложения. Сделать это можно командой prstat, посмотрим сортировку по времени CPU: $ prstat
В команде prstat существуют также опции «-v» или «-m» для более подробного вывода (см. рис. 1).
Рисунок 1. Команда prstat, детальный вывод Можно, конечно, воспользоваться и стандартной командой ps (SunOS/BSD compatibility command): $ /usr/ucb/ps -aux|head -5
Сделаем работу удобнее Чтобы не набирать слишком большое количество команд, воспользуемся некоторыми свободно распространяемыми утилитами. Вместо команды prstat можно запустить команду top [5]. Использование top позволяет на одном экране видеть как общую загрузку процессора %usr, %sys, %wio, %idle, так и периодически обновляющийся список процессов, отсортированных по различным критериям, например, по нагрузке на процессор. Если имеется Х-сервер, можно воспользоваться утилитой xcpustate [6], которая отображает информацию по загрузке процессора и дисковых накопителей. # !/bin/sh if [ -z "$DISPLAY" ] then who_host=`who am i |awk ' { print $6 }' | sed 's/[(|)]//g'` DISPLAY=$who_host:0.0 ;export DISPLAY fi /usr/local/bin/xcpustate -wait -disk -display $DISPLAY -geometry 200x760 Вывод этих команд приведен на рис. 2. Дополнительные сведения о системе Solaris вы можете найти на сайте [2], кроме того, в разделе сайта «Download» вы найдёте много полезных программ, которые помогут получить более подробную информацию о процессах, которые происходят в системе, и позволят детальнее определить источник проблем.
Рисунок 2. Рабочий стол CDE, команды top и xcpustate Автоматизируем процесс Наконец, чтобы осуществлять постоянный мониторинг, воспользуемся помощью скриптов sa1 и sa2 из пакета «system activity report package», которые предназначены для запуска в качестве заданий для демона cron. Внесём сбор статистики в таблицу crontab. $ su – sys $ EDITOR=vi;export EDITOR $ crontab –e #ident "@(#)sys 1.5 92/07/14 SMI" /* SVr4.0 1.2 */ # # The sys crontab should be used to do performance # collection. See cron and performance manual pages # for details on startup. # # 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 Раскомментируйте и при необходимости отредактируйте две последние строки. Например: «Собирать статистику круглосуточно с интервалом в 20 минут и формировать текстовый отчёт перед полуночью». 0,20,40 * * * * /usr/lib/sa/sa1 55 23 * * * /usr/lib/sa/sa2 -s 00:00 -e 23:59 -i 1200 –A Эти скрипты создают двоичные файлы статистики и текстовые файлы отчётов, которые хранятся в каталоге /var/adm/sa в течение недели (по умолчанию). В дальнейшем их можно будет использовать для поиска периодов максимальной и минимальной загрузки и как отправную точку для более подробного анализа.
|
Сергей Косько
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
