 | Оценка потребностей в ресурсах
В этом разделе описывается материал по теме 306.3 экзамена на профессионала Linux высокого уровня (LPIC-3) 301. Эта тема обладает весом 2.
Из этого раздела вы узнаете, как:
- Устанавливать потребности в ресурсах
- Детализировать потребности приложений
- Определять потребности приложений в памяти и ресурсах центрального процессора
- Проводить полный анализ, исходя из потребностей отдельных приложений
Устранение текущих проблем является ключевой задачей системного администратора. Другая задача – это анализ текущей работы системы с целью предсказания ограничений на количество ресурсов в будущем и разрешения этой ситуации прежде, чем она выльется в проблему. В этом разделе рассматривается анализ текущих потребностей, а в следующем – прогнозирование использования ресурсов в будущем, исходя из материалов текущего раздела.
Вы можете использовать два подхода к анализу текущих потребностей: измерять текущие потребности в течение некоторого периода времени (наподобие базового уровня), или моделировать систему и задавать ряд параметров, которые приводят эту модель в состояние, соответствующее текущему состоянию системы. Первый подход проще и позволяет получить достаточно правдоподобную информацию. Второй подход точнее, но более трудоемок. Настоящее преимущество моделирования проявляется тогда, когда вам необходимо спрогнозировать поведение системы в будущем. Когда у вас имеется модель вашей системы, вы можете изменить определенные параметры, отражающие ее будущее развитие, и посмотреть, как изменится производительность.
На практике оба этих подхода используются совместно. В некоторых случаях построение модели конкретной системы оказывается слишком сложным, поэтому результаты измерений являются единственной основой для прогнозирования требований к ресурсам в будущем. С другой стороны, для построения моделей все-равно необходимы измерения.
Моделирование поведения системы
Активность системы может быть смоделирована в виде серии очередей. Очередь – это конструкция, которая принимает на вход запросы и удерживает их до тех пор, пока ресурс не станет доступен. Как только ресурс становится доступен, задание выполняется и покидает очередь.
Несколько очередей можно объединить вместе в более объемную систему. Диск может быть смоделирован как очередь, в которой запросы поступают в буфер. Когда обслуживание запроса может быть выполнено, запрос передается к диску. Обычно запрос поступает от центрального процессора, который является одним простым ресурсом с несколькими задачами, конкурирующими за его использование. Изучением очередей и их приложений занимается теория очередей.
Книга Analyzing Computer System Performance with Perl::PDQ (ссылку вы можете найти в разделе Ресурсы) знакомит вас с теорией очередей и показывает, как смоделировать компьютерную систему в виде серии очередей. Далее в этой книге описывается библиотека языка С, которая называется PDQ, и сопутствующий интерфейс языка Perl, позволяющие вам определять и использовать очереди для получения оценки производительности.
Знакомство с очередями
На рисунке 4 изображена простая очередь. Запрос поступает слева и входит в очередь. Как только запросы обрабатываются кругом, они покидают очередь. Прямоугольные блоки слева от круга означают объекты, поставленные в очередь.
Рисунок 4. Простая очередь
Поведение очереди характеризуется параметрами времени, частоты и размеров. Частота поступления обозначена буквой лямбда (Λ) и обычно выражается количеством запросов в секунду. Значение Λ можно определить, выполнив наблюдения за вашей системой в течение подходящего интервала времени и посчитав поступления запросов. Подходящий интервал должен по меньшей мере в сто раз превышать время обслуживания, которое представляет собой продолжительность обработки запроса. Время пребывания – это общее время, в течение которого запрос находился в очереди, включая время, затраченное на его обработку.
Частота поступления описывает частоту, с которой объекты поступают в очередь, а пропускная способность определяет частоту, с которой объекты покидают очередь. В более сложной системе узловая пропускная способность определяет пропускную способность отдельного узла очереди, а системная пропускная способность относится ко всей системе в целом.
Размер буфера в большинстве случаев не имеет значения, поскольку буфер будет иметь ограниченный и предсказуемый размер, пока выполняются следующие условия:
- Размер буфера достаточно большой для обработки поставленных в очередь объектов.
- Очередь не увеличивается безгранично.
Второе условие является наиболее важным. Если очередь может отправлять запросы с частотой один запрос в секунду, но запросов, поступающих за одну секунду в очередь, больше, то очередь будет увеличиваться безгранично. В реальности частота поступления будет колебаться, но при анализе производительности нас интересует устойчивое состояние, поэтому используются средние значения. Возможно, что в какой-то момент в очередь попадут 10 запросов в секунду, а в другой момент – ни одного. До тех пор, пока среднее значение меньше, чем один запрос в секунду, очередь будет иметь конечную длину. Если среднее значение частоты поступления превышает частоту, с которой запросы выходят из очереди, длина очереди будет продолжать расти и никогда не достигнет устойчивого состояния.
Очередь, изображенная на рисунке 4, называется открытой очередью, поскольку в нее входит неограниченное число запросов, и им не обязательно возвращаться назад после своей обработки. Закрытая очередь возвращает информацию на вход; в системе находится ограниченное число запросов. После того, как запросы были обработаны, они возвращаются в очередь поступления.
Классическим примером очереди является продовольственный магазин. Количество людей, встающих в очередь к кассе, поделенное на период измерения – это частота поступления. Количество рассчитавшихся и покидающих очередь людей, поделенное на период измерения – это пропускная способность. Среднее время, которое затрачивает кассир на обслуживание одного покупателя – это время обслуживания. Среднее время, в течение которого покупатель стоит в очереди и ждет расчета с кассиром, плюс время обслуживания этого покупателя кассиром – это время пребывания.
Чтобы перейти к рассмотрению PDQ, рассмотрим следующий сценарий. Web-служба получает 30,000 запросов за один час. Наблюдая некоторое время за ненагруженной системой, мы установили, что время обслуживания составляет 0.08 секунды. На рисунке 5 это изображено в виде очереди.
Рисунок 5. Web-служба, смоделированная в виде очереди
Какую информацию может предоставлять PDQ? В листинге 13 приведена требуемая программа PDQ и ее вывод данных.
Листинг 13. Программа PDQ и ее вывод данных
#!/usr/bin/perl
use strict;
use pdq;
# Observations
my $arrivals = 30000; # requests
my $period = 3600; # seconds
my $serviceTime = 0.08; # seconds
# Derived
my $arrivalRate = $arrivals / $period;
my $throughput = 1 / $serviceTime;
# Sanity check -- make sure arrival rate < throughput
if ($arrivalRate > $throughput) {
die "Arrival rate $arrivalRate > throughput $throughput";
}
# Create the PDQ model and define some units
pdq::Init("Web Service");
pdq::SetWUnit("Requests");
pdq::SetTUnit("Seconds");
# The queuing node
pdq::CreateNode("webservice", $pdq::CEN, $pdq::FCFS);
# The circuit
pdq::CreateOpen("system", $arrivalRate);
# Set the service demand
pdq::SetDemand("webservice", "system", $serviceTime);
# Run the report
pdq::Solve($pdq::CANON);
pdq::Report();
..... output ..
***************************************
****** Pretty Damn Quick REPORT *******
***************************************
*** of : Sat Feb 16 11:24:54 2008 ***
*** for: Web Service ***
*** Ver: PDQ Analyzer v4.2 20070228***
***************************************
***************************************
***************************************
****** PDQ Model INPUTS *******
***************************************
Node Sched Resource Workload Class Demand
---- ----- -------- -------- ----- ------
CEN FCFS webservice system TRANS 0.0800
Queueing Circuit Totals:
Streams: 1
Nodes: 1
WORKLOAD Parameters
Source per Sec Demand
------ ------- ------
system 8.3333 0.0800
***************************************
****** PDQ Model OUTPUTS *******
***************************************
Solution Method: CANON
****** SYSTEM Performance *******
Metric Value Unit
------ ----- ----
Workload: "system"
Mean Throughput 8.3333 Requests/Seconds
Response Time 0.2400 Seconds
Bounds Analysis:
Max Demand 12.5000 Requests/Seconds
Max Throughput 12.5000 Requests/Seconds
****** RESOURCE Performance *******
Metric Resource Work Value Unit
------ -------- ---- ----- ----
Throughput webservice system 8.3333 Requests/Seconds
Utilization webservice system 66.6667 Percent
Queue Length webservice system 2.0000 Requests
Residence Time webservice system 0.2400 Seconds
|
Листинг 13 начинается с типичной для UNIX строки, определяющей интерпретатор для оставшейся части программы. Первые две строки Perl-кода указывают на использование модулей pdq и strict. Модуль pdq предоставляет функции PDQ, тогда как модуль strict налагает жесткие ограничения на синтаксис Perl, позволяя избежать ряда ошибок при написании кода.
В следующем разделе листинга 13 определены переменные, связанные с наблюдениями за системой. С помощью этой информации в следующем разделе вычисляются частота поступления и пропускная способность. Последняя величина является обратной к времени обслуживания – если вы можете обработать один запрос за N секунд, значит, вы можете обработать 1/N запросов в секунду.
|
Установка PDQ
Дистрибутив PDQ можо загрузить с Web-сайта автора (обратитесь к разделу Ресурсы). Распакуйте его во временную папку с помощью команды tar -xzf pdq.tar.gz и перейдите во вновь созданную папку, выполнив команду cd pdq42. После этого запустите команду make, чтобы выполнить компиляцию исходного кода на языке C и модуля Perl. Наконец, выполните команду cd perl5 и из этой папки запустите команду ./setup.sh, чтобы завершить компоновку модуля Perl и установить его в вашу системную директорию.
|
|
Первый тест на работоспособность проверяет, что длина очереди ограничена. Хотя большинство функций PDQ и сообщают об ошибках, автор модуля рекомендует выполнять явную проверку. Если количество поступающих в секунду запросов больше, чем количество запросов, покидающих очередь за это же время, программа завершается с ошибкой.
В оставшейся части программы выполняются прямые вызовы функций PDQ. Сначала выполняется инициализация модуля и указывается название модели. Затем временной модуль и рабочие модули настраиваются таким образом, чтобы информация в отчетах выводилась в нужном вам виде.
Каждая очередь создается с помощью функции CreateNode. В листинге 13 создана очередь типа CEN (центр организации очереди, в отличие от узла задержки, который не выполняет никакой работы) с именем webservice (эти имена являются метками и помогают вам разобраться в итоговом отчете). Это стандартная очередь типа FIFO (first in, first out – первый вошел, первый вышел), которая в терминах PDQ называется first-come first-served (первый вошел, первый обработан).
Затем происходит вызов функции CreateOpen с целью определения цепи (совокупность очередей). Частота поступления в цепь уже рассчитана. Наконец, с помощью функции SetDemand для очереди задается нагрузка. Функция SetDemand определяет время, необходимое на завершение конкретной рабочей нагрузки (очередь в составе цепи).
Наконец, цепь решается с помощью функции Solve, и с помощью функции Report создается отчет. Обратите внимание на то, что PDQ берет вашу модель, преобразует ее в ряд уравнений и затем решает их. PDQ не имитирует модель каким-либо образом.
Теперь рассмотрим, как интерпретировать полученные результаты. Отчет начинается с заголовка и сводной информации о модели. Раздел WORKLOAD Parameters содержит более интересную для нас информацию. Время обслуживания в цепи составляет 0.08 секунды, в соответствии с заданным ранее значением. Значение per second - это частота поступления.
В разделе SYSTEM performance рассчитывается производительность системы в целом. Цепь выдержала частоту поступления, равную 8.3333 запросам в секунду. Время отклика (response time) составило 0.24 секунды (более подробно об этом позже); это значение включает в себя время обслуживания, равное 0.08 секундам, и время нахождения запроса в очереди. Максимальная производительность цепи оценивается в 12.5 запросов в секунду.
Посмотрев на очередь более внимательно, вы можете увидеть, что она используется на 66.6667%. Средняя длина очереди равна двум запросам. Это означает, что перед входящим запросом в очереди может содержаться еще два запроса, плюс запрос, обрабатывающийся в данный момент. С учетом времени обработки одного запроса, равного 0.08 секундам, среднее время ожидания составляет 0.24 секунды, о чем было сообщено ранее.
Эту модель можно детализировать до компонентов Web-службы. Вместо использования одной очереди, представляющей собой Web-службу, вы могли бы использовать отдельную очередь для обработки запроса, отдельную очередь для доступа к базе данных и отдельную очередь для подготовки ответа. Если ваша модель правильно построена, производительность системы должна оставаться той же самой, просто в этом случае вы получите более подробную информацию о внутренней работе Web-службы. С этого уровня вы можете использовать подход "что если" и смоделировать применение более быстрой базы данных или нескольких Web-серверов, чтобы посмотреть, какой эффект получится в результате внесенных изменений. Разделение модели на отдельные ресурсы поможет вам понять, какая конкретная очередь является узким местом, и сколько ресурсов у вас имеется в запасе.
В листинге 13 приведен элементарный пример использования библиотек PDQ. Чтобы узнать, как строить более сложные модели, прочитайте книгу Analyzing
Computer System Performance with Perl::PDQ (ссылку вы можете найти в разделе Ресурсы).
| |
