В поисках производительности: Часть 1. Диагностирование проблем

Узнайте, как описание проблем с производительностью может помочь в ходе их диагностики.

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

Энтони Инглиш, ведущий специалист по AIX, Levitar Pty Ltd

фото Энтони ИнглишаЭнтони Инглиш (Anthony English) – независимый консультант, живущий в Сиднее, Австралия. Он работает с AIX-системами с 1991 года и публикует статьи в своем блоге на портале IBM developerWorks и на сайте AIX Down Under. Он также является обладателем звания IBM Champion for Power Systems. С Энтони можно связаться через его почтовый ящик anthonyenglish@levitar.com.au.



05.04.2013

"Хьюстон! У нас проблема"

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


Задавайте правильные вопросы

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

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


Изолируйте проблему

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

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

Набор инструментов AIX Performance PMR

Если производительность системы ниже ожидаемой, вам может пригодиться набор инструментов для сбора данных AIX Performance PMR (см. раздел "Ресурсы"). В дополнение к сценариям, способным помочь в поиске "узких мест" при использовании ресурсов, эти инструменты (perfpmr) содержат список вопросов, которые помогут вам и службе поддержки IBM точно локализовать местоположение проблемы. Пройдя по этим вопросам, вы сможете получить лучшее понимание существующих "узких мест".

Начните с простейших вопросов. Что именно в системе стало работать медленнее? Снижение производительности затронуло только одного пользователя или сразу несколько? Произошло ли снижение производительности только одного процесса, например, создания отчёта, выполнения резервного копирования или обновления базы данных? Все ли системы, подключенные к определённому сетевому хранилищу данных, состоящему из RAID-массива, стали работать хуже? Какие системы были затронуты? Какие приложения были запущены? Проблема затронула весь сервер IBM Power Systems™ или только один логический раздел (LPAR) на нём? Если проблема касается одного логического раздела, то не находится ли "узкое место" в определённой файловой системе или даже в отдельном файле?

Другие инструменты

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

Рисунок 1. Главный экран команды topas
Рисунок 1. Главный экран команды topas

Команда vmstat будет очень полезна в процессе поиска "узких мест" в системе. Эта команда выводит информацию об использовании памяти, процессора и системы ввода/вывода, как показано в листинге 1.

Листинг 1. Пример отчёта команды vmstat
vmstat 1 4

System configuration: lcpu=12 mem=7168MB ent=2.80

kthr    memory              page              faults              cpu
----- ----------- ------------------------ ------------ -----------------------
 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa    pc    ec
 5  0 793201 942484   0   0   0   0    0   0 15550 32034 25717  4 37 50  8  1.32  47.1
 1  0 793201 942484   0   0   0   0    0   0 17369 36882 29660  6 40 48  6  1.45  51.6
 0  0 793201 942484   0   0   0   0    0   0 18309 39566 33628  8 39 47  7  1.45  51.9
 4  0 793203 942482   0   0   0   0    0   0 16068 34022 27586  5 39 49  6  1.40  49.8

О том, как vmstat может помочь быстро определить области системы, в которых происходят конфликты из-за ресурсов, подробно рассказывается в серии статей "Optimizing AIX 7 memory performance". В разделе "Ресурсы" можно найти ссылку на данную серию и другие статьи, посвященные вопросам, связанным с производительностью системы.

Можете ли вы воспроизвести проблему?

Если при обращении в службу поддержки IBM выполнить сбор информации о проблеме с помощью инструментов perfpmr, то вы сможете предоставить более подробное описание проблемы. Например, вы сможете предоставить больше сведений о варианте возникновения проблемы, который легче всего воспроизвести. Когда вы будете пытаться воспроизвести проблему, постарайтесь заметить, не существует ли команды или последовательности событий, которые всегда приводят к замедленному получению результатов. Проверьте, не замедлилось ли выполнение команд самой ОС AIX.

Проверяйте журнальные файлы

Важным источником информации являются журнальные файлы. Большинство приложений, систем управления базами данных и аппаратных устройств в том или ином виде предоставляют информацию об ошибках. Если процесс резервного копирования занимает необычно много времени, то, возможно, это связано просто с засорившимся ленточным механизмом. Если ленточный накопитель подключен к LPAR AIX, то для него можно запустить команду errpt. Используйте флаг –a, чтобы получить подробное описание ошибки, как показано в листинге 2.

Листинг 2. Подробный отчёт об ошибке (вывод команды errpt -a)
# errpt -a | more
LABEL:          TAPE_ERR1
IDENTIFIER:     4865FA9B

Date/Time:       Sat Oct  1 12:56:00 AEST 2011
Sequence Number: 136509
Machine Id:      00C5A47E4C00
Node Id:         tsm1
Class:           H
Type:            PERM
WPAR:            Global
Resource Name:   rmt1
Resource Class:
Resource Type:
Location:
VPD:
        Manufacturer................IBM
        Machine Type and Model......ULT3580-TD3
        Serial Number...............1210002439
        Device Specific.(FW)........93G6

Description
TAPE OPERATION ERROR

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

Менялось ли что-нибудь в системе?

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

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

Атрибуты устройства можно проверить с помощью команды lsattr. В листинге 3 приведен пример, показывающий значение глубины очереди для физического тома.

Листинг 3. Просмотр атрибутов устройства
# lsattr -El hdisk7 -a queue_depth
queue_depth 3  Queue DEPTH True

Для изменения атрибута устройства воспользуйтесь командой chdev, как показано в листинге 4.

Листинг 4. Изменение значения атрибута устройства
# chdev -l hdisk7 -a queue_depth=20
hdisk7 changed

Если устройство в данный момент используется кем-либо, то вы можете освободить ресурсы, использующие данное устройство, или запланировать изменение атрибута после перезагрузки. Это можно сделать, добавив флаг –P к команде chdev, как показано в листинге 5.

Листинг 5. Изменение атрибута устройства на постоянной основе
# chdev -l hdisk7 -a queue_depth=20 -P   # Make permanent change

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

Какова ожидаемая производительность системы?

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

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

В листинге 6 показывается, как запустить сценарий perfpmr на 10 минут (600 секунд), и приведены первые несколько строк информации, выводимой сценарием.

Листинг 6. Сбор статистики по производительности в течение 10 минут
#./perfpmr.sh 600

(C) COPYRIGHT International Business Machines Corp., 2000,2001,2002,2003,2004-2008

23:12:26-10/05/11 :     perfpmr.sh begin
    PERFPMR: hostname: slowhost
    PERFPMR: perfpmr.sh Version 610 2010/12/01

Является проблема временной или постоянной?

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

В чём выражается снижение производительности?

Может оказаться полезным найти, что именно заставляет пользователей говорить о снижении скорости работы системы. Увеличилось количество времени, необходимого для входа в систему, или больше времени стало требоваться для отклика системы на нажатие клавиши на клавиатуре? Возможно, выполнение транзакции или генерация отчёта стали занимать слишком много времени.

Помогает ли перезагрузка системы в качестве временного решения?

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

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

Листинг 7. Команда ps выводит отчёт с информацией о работающих процессах
		# ps -ef | more
			     UID      PID     PPID   C    STIME    TTY  TIME CMD
    root        1        0   0   Oct 04      -  0:01 /etc/init
    root   655466  3866772   0   Oct 04      -  0:00 /usr/sbin/snmpd
    root  2097342        1   0   Oct 04      -  0:00 /bin/ksh /usr/tivoli/tsm/server/bin/
rc.adsmserv
    root  2424972  3866772   0   Oct 04      -  0:00 /usr/sbin/inetd
    root  2883806        1   0   Oct 04      -  0:00 /usr/lib/errdemon
    root  2949246        1   0   Oct 04      -  0:00 /usr/ccs/bin/shlap64
    root  3276878  3866772   0   Oct 04      -  0:00 /usr/sbin/syslogd
    root  3604516        1   0   Oct 04      -  1:24 /usr/sbin/syncd 60
    root  3670082  3866772   0   Oct 04      -  0:05 /usr/sbin/xntpd
    root  3735676  3866772   0   Oct 04      -  0:00 /usr/sbin/muxatmd
    root  3801210  3866772   0   Oct 04      -  0:00 /usr/sbin/hostmibd
    root  3866772        1   0   Oct 04      -  0:00 /usr/sbin/srcmstr
    root  3932286  3866772   0   Oct 04      -  0:00 /usr/sbin/portmap
    root  3997832  3866772   0   Oct 04      -  0:00 /usr/sbin/aixmibd
    root  4063420        1   0   Oct 04      -  0:44 /usr/sbin/getty /dev/consol
e
    root  4128936  3866772   0   Oct 04      -  0:03 sendmail: accepting connect
ions
    root  4259980  3866772   0   Oct 04      -  0:00 /usr/sbin/snmpmibd
    root  4325556        1   0   Oct 04      -  0:02 /usr/sbin/cron
    root  4391124  3866772   0   Oct 04      -  0:03 /usr/sbin/rsct/bin/vac8/IBM.
	CSMAgentRMd
    root  4522176        1   0   Oct 04      -  0:00 /usr/bin/dsmcad
    root  4718774  3866772   0   Oct 04      -  0:00 /usr/sbin/rpc.lockd -d 0
    root  4784284  2424972   0   Oct 04      -  1:10 xmtopas -p3
    root  4980888  3866772   0   Oct 04      -  0:00 /usr/sbin/biod 6
    root  5177506  3866772   0   Oct 04      -  0:00 /usr/sbin/nfsd 3891
    root  5243046  3866772   0   Oct 04      -  0:00 /usr/sbin/rpc.mountd
    root  5439672  3866772   0   Oct 04      -  0:04 /usr/sbin/rsct/bin/rmcd -a IBM.
LPCommands -r
    root  5570560        1   0   Oct 04      -  0:00 bin/nonstop_aix @config/nonstop.
properties
    root  5701822  2097342 208   Oct 04      - 938:56 dsmserv quiet
    root  5832888        1   0   Oct 04      -  0:02 /usr/local/sbin/sshd
    root  5898436  3866772   0   Oct 04      -  0:00 /usr/sbin/qdaemon
    root  5963972        1   0   Oct 04      -  0:00 /usr/sbin/uprintfd
    root  6095040  3866772   0   Oct 04      -  0:00 /usr/sbin/writesrv
    root  6160590  3866772   0   Oct 04      -  0:08 /usr/sbin/pcmsrv
    root  6291682  3866772   0   Oct 04      -  0:00 /usr/sbin/rsct/bin/IBM.DRMd

Не связана ли проблема с сетевыми интерфейсами?

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

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

Листинг 8. Запуск команды ping для проверки доступности сервера
ping 192.168.168.30
PING 192.168.168.30: (192.168.168.30): 56 data bytes
64 bytes from 192.168.168.30: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 192.168.168.30: icmp_seq=1 ttl=255 time=0 ms
64 bytes from 192.168.168.30: icmp_seq=2 ttl=255 time=0 ms
64 bytes from 192.168.168.30: icmp_seq=3 ttl=255 time=0 ms

----192.168.168.30 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms

Подобная проверка доступности IP-адреса сервера помогает определить, не связана ли проблема с конфигурацией DNS-сервера. Если вы подозреваете, что проблемы связаны с сетевой инфраструктурой, то разумно будет начать с изучения диаграммы или описания конфигурации сети.

Не связана ли проблема с определенными приложениями?

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

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


Общий совет

Документация perfpmr рекомендует предоставлять чёткое формальное описание конкретного случая проявления проблемы. Также рекомендуется отделять симптомы и факты от теорий, идей и собственных умозаключений. В документации сказано: "Если все факты доступны, то команда по оценке производительности сможет быстро отделить от них те, которые не относятся к самой проблеме".

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

Для определения модели и серийного номера компьютера можно воспользоваться командой lsconf.

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


Награда за терпение

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

Ресурсы

Научиться

Получить продукты и технологии

  • Загрузите perfpmr - пакет инструментов AIX Performance PMR для сбора данных.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

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

Выберите имя, которое будет отображаться на экране



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

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

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=863812
ArticleTitle=В поисках производительности: Часть 1. Диагностирование проблем
publish-date=04052013