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

В прикладных системах, ориентированных только на пакетную обра­ботку, коэффициент использования процессора меньше 100%, - это плохо, если в очереди заданий что-то есть. Цель пользователя системы пакетной обработки состоит в достижении максимальной пропускной способности. Если какое-то задание ожидает своей очереди, то каж­дая секунда простоя процессора - это потерянное время, которое уже никогда не вернуть. Но будьте осторожны: длительная стопроцентная загрузка процессора часто приводит к «пробуксовке» планировщика операционной системы, что может снизить производительность.

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

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

Способ определения оптимального соотношения пакетной и интерак­тивной нагрузки описан в [Millsap (2000b)].

Несмотря на то, что число q- изменяемый параметр системы массо­вого обслуживания M/M/m, масштабирование прикладной систе­мы Oracle для работы на нескольких серверах базы данных (даже вслучае применения Oracle9i Real Application Clusters - RAC), тех­нологически это сложное мероприятие, которое практически на­верняка обойдется дороже, чем конфигурация, в которой база дан­ных работает на одном хосте.

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

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

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

Сокращение кода имеет ряд преимуществ по сравнению с модерниза­цией оборудования, а именно:

Усовершенствование оборудования часто означает не только увели­чение стоимости самого оборудования, но и увеличение стоимости поддержки и лицензионных выплат на программное обеспечение. Например, некоторые программные лицензии для систем с (n + 1) процессорами стоят дороже, чем для систем с n процессорами. Уменьшение количества кода для неэффективных команд SQL обыч­но требует не более нескольких часов работы для каждой команды.

Сокращение кода часто оказывается более мощным средством по­вышения производительности, чем усовершенствование оборудова­ния. Например, удвоение скорости процессора возможно не чаще чем раз в два года. Что же касается сокращения кода, то часто уда­ется уменьшить его длину в 100 или более раз всего за несколько ча­сов работы.

Сокращение кода практически не приводит к неожиданным нега­тивным побочным эффектам, которые могут сопутствовать модер­низации оборудования. Возможным побочным эффектом повыше­ния пропускной способности является ухудшение производитель­ности программ, которым не хватало ресурсов не того устройства, для которого была проведена модернизация [Millsap (1999)].

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

Использование M/M/m: пример с решением

Давайте на примере посмотрим, как можно использовать модель и ин­терпретировать полученные результаты. Рассмотрим поэтапно решение поставленной ниже задачи, применяя модель системы массового обслу­живания M/M/m (рабочую книгу Microsoft Excel), которая доступна на нашем сайте http://www.hotsos.com. Задача по сути своей проста, но для ее решения требуется понимание теории массового обслуживания.

Задача формулируется следующим образом:

На выполнение важной команды SQL расходуется 0,49 секунды процессор­ного времени. Предположим, что в период пиковой загрузки системы каж­дый из 100 пользователей будет выполнять эту команду с частотой четыре раза в минуту. Сервер, работающий под Linux, допускает установку до 16 процессоров. Сколько процессоров потребуется данному серверу, если не­обходимо обеспечить время отклика не более одной секунды по крайней мере для 95% выполнений команды пользователями в период пиковой загрузки?

Попробуем ее решить.

В первую очередь необходимо проверить, можно ли применить модель массового обслуживания M/M/wz/oo/FCFS (или, для краткости, M/M/m) к исследуемой нами системе:

Если существует возможность измерить интервал между поступле­ниями запросов, то первым делом необходимо проверить, подчиня­ются ли такие интервалы экспоненциальному распределению. Сде­лаем это с помощью программы из примера 9.4. Если окажется, что время между поступлениями запросов распределено не экспонен­циально, то следует рассмотреть более короткий временной проме­жуток. Например, в случае I (который воспроизведен в табл. 9.5) из уже рассмотренного примера с посетителями ресторана распределе­ние времени между приходами клиентов отличается от экспонен­циального на промежутке с 11:30 до 13:30. Но вот в промежутке с 12:00 до 12:15 оно с большой вероятностью имеет экспоненциаль­ное распределение.

Интервалы времени	Случай I	Случай II
11:30-11:45	0	34
11:45-12:00	0	28
12:00-12:15	240	31
12:15-12:30	0	37
12:30-12:45	0	24
12:45-13:00	0	30
13:00-13:15	0	32
13:15-13:30	0	24
Среднее для 15-минутных интервалов	30	30

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

Необходимо убедиться в том, что экспоненциально распределено время обслуживания. И здесь на помощь приходит программа из примера 9.4 (или какое-то другое средство). Если время обслужива­ния распределено не экспоненциально, то следует переопределить исследуемую единицу обслуживания. Допустим, вы рассматриваете в качестве единицы обслуживания отчеты, при этом время их об­служивания может составлять от 0,2 до 1392,7 секунды. Тогда вре­мя обслуживания, вероятнее всего, не будет распределено экспонен­циально. Выберите в качестве единицы измерения определенный тип отчетов, время обслуживания которого не подвержено таким значительным колебаниям. Или же выберите более мелкую едини­цу измерения, например, для этой цели подойдут операции LIO.

В нашем примере будем считать, что измерения, проведенные в тес­тируемой системе, подтвердили экспоненциальное распределение времени обслуживания для «важной команды SQL».

В формулировке задачи сказано, что в нашем случае в роли канала обслуживания выступает процессор компьютера, работающего под управлением операционной системы Linux. Linux полностью под­держивает симметричную многопроцессорную обработку (SMP), так что нам известно, что наши каналы обслуживания однородны, параллельны и независимы. Некоторые конфигурации операцион­ных систем (например, использующие привязку задач к процессо­рам) нарушают ограничение на однородность процессоров. Далее вы узнаете о том, что в случае применения данной модели необхо­димо также учитывать несовершенство масштабирования. И нако­нец, мы используем модель M/M/m для прогнозирования произво­дительности системы с более чем m процессорами.

На длину очереди к процессору Linux не налагается никаких огра­ничений, поэтому можно не беспокоиться о составляющей «с» оп­ределения M/M/m.

M/M/m/c /FCFS (обслуживание в порядке поступления)

Стандартная политика планирования Linux близка к обслужива­нию в порядке поступления. Несмотря на то, что алгоритм плани­рования разрешает использование приоритетов для процессов и вы­бор одной из нескольких политик (FCFS или циклическое обслужи­вание (round-robin)), модель M/M/m показала себя как пригодная для прогнозирования производительности систем Linux.