В поисках производительности: Часть 2. Профилактика лучше лечения

Список шагов, помогающих избежать возникновения "узких мест" в системе

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

Энтони Инглиш, ведущий специалист по 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

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

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

Применяйте упреждающий подход

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

Документирование конфигурации

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

В системах IBM® Power Systems™ существует множество инструментов, полезных при документировании конфигурации. Например, с помощью команды prtconf можно вывести конфигурацию виртуальной машины, как показано в листинге 1.

Листинг 1. Команда prtconf выводит конфигурацию системы
# prtconf
		
System Model: IBM,9117-MMA
Machine Serial Number: 01A02B3
Processor Type: PowerPC_POWER6
Processor Implementation Mode: POWER 6
Processor Version: PV_6_Compat
Number Of Processors: 2
Processor Clock Speed: 4208 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
LPAR Info: 4 A3_everest-nim
Memory Size: 8192 MB
Good Memory Size: 8192 MB
Platform Firmware level: EM350_108
Firmware Version: IBM,EM350_108

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

Внедрите механизм управления изменениями

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

Внесите рекомендуемые изменения в настройки

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

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

В листинге 2 приведен вывод команды iostat, из которого становится понятно, что служба, отвечающая за работу очереди для данного физического диска, неспособна обрабатывать получаемые запросы. Обратите внимание на значение sqfull в списке параметров очереди, равное 239; это означает, что другие запросы ввода/вывода вынуждены ждать.

Листинг 2. Команда iostat демонстрирует переполнение очереди
hdisk89        xfer:  %tm_act      bps      tps      bread      bwrtn
                        75.0     43.4M   336.5        6.1K      43.4M
               read:      rps  avgserv  minserv  maxserv   timeouts      fails
                         1.5    123.9     15.1      1.0S          0          0
              write:      wps  avgserv  minserv  maxserv   timeouts      fails
                       335.0     28.1      1.5    275.0           0          0
              queue:  avgtime  mintime  maxtime  avgwqsz    avgsqsz     sqfull
                        43.9      0.0    297.1      2.5        1.6     239.0

Глубину очереди можно увеличить с помощью команды chdev, как показано в листинге 3.

Листинг 3. Увеличение глубины очереди
chdev -l hdisk89 -a queue_depth=20

Предпринимайте только одно действие в каждый момент времени

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

Обращайтесь за помощью как можно раньше

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

Периодически выполняйте оценку производительности

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

Планируйте нагрузку

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

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

Избегайте точечных решений

Многие системы обладают недостаточной производительностью только потому, что не пользуются всеми возможностями доступных технологий. Например, применение локального решения, основанного на выделении дисков и адаптеров ввода/вывода, означает, что другие виртуальные машины не смогут использовать эти ресурсы в режиме совместного доступа. Технологии виртуализации в IBM PowerVM® обладают различными возможностями, которые помогут сбалансировать нагрузку, поэтому не стоит игнорировать их за счет внедрения разовых локальных решений.

Обеспечьте безопасность журнальных файлов

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

Полезно также сохранять стандартный вывод программ и все сообщения об ошибках. Чтобы сохранить стандартный вывод, используйте при запуске команды 1 > (перенаправление первого потока вывода) и укажите имя файла, как показано в листинге 4.

Листинг 4. Сохранение стандартного вывода
# ./myscript.sh 1>myscript.out

Также важно сохранять стандартные сообщения об ошибках, выводимые программой. Для этого при запуске программы необходимо указать 2 > (перенаправление второго потока вывода) и имя файла, как показано в листинге 5.

Листинг 5. Сохранение стандартных сообщений об ошибках
# ./myscript.sh 2>myscript.err

Можно сохранять стандартный вывод и сообщения об ошибках в один файл, как показано в листинге 6.

Листинг 6. Сохранение стандартного вывода и сообщений об ошибках в один файл
# ./myscript.sh > myscript.out 2>&1

Установите график регулярного обслуживания системы

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

Установите точку отсчета

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

Подготовьтесь к возникновению проблем

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

Таблица 1. Что следует включить в план действий при возникновении проблем
ПунктОписание
процесс для описания проблем, связанных с производительностьючтобы пользователи могли легко описать и задокументировать симптомы проблемы
контакты службы поддержкичтобы быстро найти необходимого специалиста и сохранить информацию, полученную от команды сторонней службы поддержки
журнал произошедших изменений
  • что именно изменилось в системе?
  • в чем заключалось изменение?
  • когда было сделано изменение?
  • помогло ли данное изменение?
  • как «откатить» данное изменение

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


Управление ожиданиями

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

Выделите время для диагностирования проблемы

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

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

Даже если вам и не удастся установить источник проблемы, вы всё равно можете предпринять шаги, которые смогут облегчить этот поиск в будущем. Некоторые из них перечислены в статье "Insufficient Evidence When Problems Occur" (см. раздел "Ресурсы").

Планируйте ожидаемую нагрузку для системы

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

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

Ожидания пользователей

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

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


Держите ситуацию под контролем

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

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

Ресурсы

Научиться

Обсудить

Комментарии

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=863813
ArticleTitle=В поисках производительности: Часть 2. Профилактика лучше лечения
publish-date=04052013