Управление загрузкой процессора

Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется.

Управление загрузкой процессора

Все ресурсы влияют тем или иным образом на загрузку процессора. К примеру, медленные дисковые устройства заставляют CPU выполнять холостые циклы в ожидании завершения операции ввода/вывода. Смена контекста (context switch) аналогичным образом увеличивает время отклика системы.

Что такое загрузка процессора

Чтобы понять, чем занят процессор необходимо знать –  из каких компонент состоит его загрузка. На UNIX-системах работу процессора разделяют на следующие компоненты:

  • User Time (время пользователя)– время, которое процессор тратит на выполнение задач пользователя. Это основное, за что вы платите при покупке процессора.
  • System time (время системы) –  количество времени, которое система тратит на подкачку, смену контекста, запуск задач по расписанию и другие системные задачи. Вы никогда не избавитесь от этого времени, но вы можете минимизировать его. Подробности – глава 3, “Системное администрирование” ,страница 129
  • Wait on I/O (ожидание ввода-вывода) – время, которое CPU простаивает в ожидание запрошенного ресурса, например – ожидание выполнения дисковой операции.
  • Idle Time (время простоя) – сумма времён, когда CPU простаивает. Если нет команд в очереди инструкций и процессор не ждет отклика  ресурсов, то такое время отмечается как время простоя. Некоторые операционные системы могут учитывать как время простоя и время ожидания ввода-вывода. Ведь по сути, во время такого ожидания процессор не выполняет никаких операций и ждет отклика устройства ввода-вывода. Поэтому опираться только лишь на показатель Idle Time во время оценки производительности системы не стоит – будут погрешности

На Windows-системах загрузку  процессора разделяют на следующие компоненты:

  • User Time (время пользователя) – время выполнения задач пользователя.
  • Priveleged Time (привилегированное время) – время, которое система тратит на подкачку, смену контекста, задачи по расписанию и другие системные задачи.
  • Idle Time (время простоя) – время простоя CPU.  Необходимо отметить, что Windows включает в этот показатель время ожидания ввода/вывода.
  • Processor Time (время процессора)– сумма всех предыдущих индикаторов. Можно предполагать, что 100 минус processor time равен времени простоя CPU.

Настройка операционной системы.

Любое время, потраченное на ожидание ввода-вывода кажется неопытному администратору нежелательным.  Но, на самом деле, не все I/O wait являются поводом для беспокойства. Время I/O Wait возникает каждый раз, когда процессор выполнил свою работу и находится в ожидании других ресурсов : дисков или памяти.  Это естественно – центральный процессор является быстрейшим из ресурсов и должен ждать отклика более медленных устройств. Если же ожидание ввода-вывода оказывает заметное влияние на систему, то это является причиной для беспокойства.

При настройке системы желательно (но необязательно) иметь всегда ненулевое значение Idle time (время простоя). Да, вполне возможно нагрузить под завязку двухпроцессорную систему на 100% полезной работой (иными словами мы будем иметь 100% User Time).  Это не означает, что система имеет плохую производительность, напротив, она работает так быстро насколько может.  При настройке производительности мы пытаемся перенести узкое место (bottleneck) на самый быстрый ресурс – CPU. Если процессоры на 100% заняты пользовательскими задачами, то система настроена просто прекрасно. Дальнейшее увеличение производительности возможно только при увеличении тактовой частоты или при добавлении новых ядер.  Утилизацию  процессора необходимо рассматривать только в совокупности показателей.  В общих чертах, если время I/O Wait увеличивается, то совсем необязательно, что узким местом стала подсистема ввода-вывода.   Если мы говорим об идеальных условиях, то достаточно иметь 70 % времени на пользовательские задачи (User Time), 20% – время системы (System Time), 0% – ожидание ввода-вывода (I/O Wait) и 10% – время простоя (Idle Time). Еще одной метрикой наблюдения является отсутствие 100 % загрузки CPU на пользовательские задачи, если, конечно, это не обычное поведение вашей системы. Такую нагрузку могут вызвать неконтролируемые процессы.  Неконтролируемые процессы – это, в основном,  клиентские процессы, главный отличительный признак которых – отсутствие присоединенных к себе терминалов (tty) и исполнение в режиме отличном от пакетного (-b).

Отношение User Time к System Time должно быть приблизительно как 3:1 на host-based системах, в то время как на системах клиент-сервер это время может быть ближе как 1.5:1. Если время, затраченное на пользовательские задачи ниже 20% от общего использования CPU и меньше времени системы,  то такое отношение может изменяться в широких пределах. В некоторых случаях System Time больше User Time из-за плохого выделения ресурсов. Таким образом, во время увеличения User Time при настройке сервера следует стремиться к тому, чтобы System Time составляло треть или менее от пользовательского времени. Это легко увидеть, взглянув на ресурсы CPU в любом средстве мониторинга.

Иллюстрация 5 показывает пример информации отображаемой Performance Monitor

Время простоя CPU (CPU Idle Time)

Наличие Idle time может являться хорошим знаком. Это означает, что вашей системе есть куда расти. Необязательно, чтобы время простоя было всегда больше нуля.  Если Idle Time равно нулю длительный период времени и нет существенного времени I/O Wait, то для полного понимания ситуации необходимо пристальнее взглянуть на работу CPU.

Например, посмотрите на глубину очереди CPU (cpu queue depth). Значение CPU queue depth показывает количество процессов в ожидании исполнения. Если в очереди всегда есть некоторое количество процессов, то необходимо предпринять один из следующих вариантов:

  • Увеличить мощность CPU (см раздел 1 – 40 ”Оптимизация использования CPU”)
  • Уменьшить потребление ресурсов  исправлением кода приложения или перенести вычисления на свободные от высокой нагрузки интервалы времени

Если время I/O wait высокое и нет времени Idle Time, то необходимо повысить эффективность дисковой подсистемы (см главу 2 “Управление ресурсами OpenEdge”) – увеличить пропускную способность дисковой подсистемы или  изменить временной график ваших вычислений. Если I/O Wait занимает 10 % или меньше и значение Idle Time не равно нулю, то необходимость в каких-либо действиях отсутствует.

Наблюдения за системой

Круглосуточный мониторинг  за вашей системой  всегда помогает принять решение при оптимизации загрузки процессора. Ваша система может выглядеть отлично в течение рабочего времени (пока вы видите, что происходит), но ночью могут быть серьезные проблемы производительности.  Есть множество приложений, которые производят 70% своих вычислений в вечерние часы.  Большинство систем выполняют в ночные часы совсем другие задачи, чем днем. Типичная система делает OLTP-транзакции с 9 утра  до 5 вечера, производит закрытие дня с 7 вечера до 12 ночи и запускает большие “тяжелые” отчеты после полуночи.

Есть некоторые приёмы, которые вы можете использовать для  более эффективного использования существующих ресурсов. К примеру, можно определить такое время суток, когда базе данных необходимо больше процессов APW (page writers); или запускать “тяжелый” отчет в ночные часы.

Например, обсудим резервирование БД. Если резервное копирование присходит в то время, когда запущены отчеты или  программы закрытия финансового дня – вы рискуете столкнуться с проблемами дисковой производительности, которые в свою очередь явятся причиной медленной работы системы и увеличат время I/O Wait . Анализ собранной за сутки статистики сможет выявить данную проблему.

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

Использование OE Management для мониторинга производителоьности CPU

Информацию о CPU лучше разместить на странице My Dashboard для того, чтобы она все время была на виду. При настройке страницы My Dashboard вы можете выбрать CPU в пункте Other system resources to show, чтобы увидеть фрейм-viewlet со статистикой использования CPU.

Быстрый процессор или многопроцессорная конфигурация?

Конечно, в идеале, вы должны иметь более чем достаточное количество быстрых CPU в вашей системе. Но на самом деле системный администратор обычно вынужден выбирать –  много медленных процессоров или мало быстрых.  Преимущество быстрых процессоров в том, что они выполняют однопоточные задачи очень быстро.  Пример однопоточной операции в OpenEdge – бинарный дамп (на текущий момент – не совсем удачный пример, так как его можно запускать в многопоточном режиме – /dmi). Этот процесс выгружает все записи таблицы. Сервер с одним быстрым CPU выполнит этот процесс быстрее, чем сервер с медленной мультипроцессорной конфигурацией (при условии равенства других ресурсов, конечно). Бинарный дамп выполняется очень редко, почему же он должен быть критерием выбора CPU? Главная причина – во время бинарного дампа и последующей бинарной загрузки вашим пользователям недоступна база данных, поэтому этот процесс должен быть завершен как можно быстрее. Однако, в большинстве видов деятельности есть и еще другие примеры однопоточных операций, которые являются таковыми из-за своей архитектуры. Процесс закрытия финансового дня – хороший пример, в это время последовательно применяются все финансовые операции, прежде чем они попадут в бухгалтерский реестр. В то же время, мультипроцессорные конфигурации позволяют совершать одновременно различные операции. К примеру, один пользователь  вводит заказы в систему в то время, как другой совершает отгрузку продукции.  Это очевидные преимущества для бизнеса с точки зрения эффективности.

Итак, что же решить? Лучше всего – провести анализ вашего приложения и его использования. Например, если у вас большинство однопоточных задач, то выигрыш от быстрого процессора будет больше, даже за счет уменьшения количества CPU.  А приложение с большим количеством ввода данных и малой долей однопоточных задач выиграет от наличия бОльшего количества CPU, даже если они будут медленными. В любом случае – залогом правильного решения будет детальный анализ утилизации процессоров.

Итог

В этой главе мы узнали как эффективно управлять системными ресурсами.

Вы должны уметь:

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

Leave a Reply

You must be logged in to post a comment.