 | Определение будущих потребностей в ресурсах
В этом разделе описывается материал по теме 306.4 экзамена на профессионала Linux высокого уровня (LPIC-3) 301. Эта тема обладает весом 1.
Из этого раздела вы узнаете, как:
- Прогнозировать момент исчерпания пропускной способности конфигурации
- Отслеживать темпы роста использования пропускной способности
- Строить графики тенденции использования пропускной способности
В предыдущем разделе вы познакомились с библиотекой PDQ и примером отчета. В отчете были показаны рассчитанные значения использования и максимальной загрузки очереди, а также системы в целом. Вы можете использовать этот же метод для прогнозирования момента исчерпания пропускной способности конфигурации. Кроме того, вы можете использовать графики для отображения темпов роста системы с течением времени, а также для расчета того момента, когда пропускная способность достигнет предела.
Еще о PDQ
В листинге 14 показана та же Web-служба, что и в листинге 13, но здесь она разделена на две очереди: одна очередь отображает время центрального процессора Web-сервера, затрачиваемое на обработку запроса и формирование ответа, а другая – время ожидания ответа от базы данных на поступивший запрос.
Листинг 14. Новая программа PDQ для примера Web-службы
#!/usr/bin/perl
use strict;
use pdq;
# Observations
my $arrivals = 30000; # requests
my $period = 3600; # seconds
# Derived
my $arrivalRate = $arrivals / $period;
# Create the PDQ model and define some units
pdq::Init("Web Service");
pdq::SetWUnit("Requests");
pdq::SetTUnit("Seconds");
# The queuing nodes
pdq::CreateNode("dblookup", $pdq::CEN, $pdq::FCFS);
pdq::CreateNode("process", $pdq::CEN, $pdq::FCFS);
# The circuit
pdq::CreateOpen("system", $arrivalRate);
# Set the service demand
pdq::SetDemand("dblookup", "system", 0.05);
pdq::SetDemand("process", "system", 0.03);
# Solve
pdq::Solve($pdq::CANON);
pdq::Report();
|
Код в листинге 14 добавляет в систему еще одну очередь. Общее время обслуживания составляет все те же 0.08 секунды, из которых 0.05 секунды затрачены на поиск в базе данных и 0.03 секунды – на обработку данных центральным процессором. В листинге 15 показан сгенерированный отчет.
Листинг 15. Отчет программы PDQ из листинга 14
***************************************
****** Pretty Damn Quick REPORT *******
***************************************
*** of : Sun Feb 17 11:35:35 2008 ***
*** for: Web Service ***
*** Ver: PDQ Analyzer v4.2 20070228***
***************************************
***************************************
***************************************
****** PDQ Model INPUTS *******
***************************************
Node Sched Resource Workload Class Demand
---- ----- -------- -------- ----- ------
CEN FCFS dblookup system TRANS 0.0500
CEN FCFS process system TRANS 0.0300
Queueing Circuit Totals:
Streams: 1
Nodes: 2
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.1257 Seconds
Bounds Analysis:
Max Demand 20.0000 Requests/Seconds
Max Throughput 20.0000 Requests/Seconds
****** RESOURCE Performance *******
Metric Resource Work Value Unit
------ -------- ---- ----- ----
Throughput dblookup system 8.3333 Requests/Seconds
Utilization dblookup system 41.6667 Percent
Queue Length dblookup system 0.7143 Requests
Residence Time dblookup system 0.0857 Seconds
Throughput process system 8.3333 Requests/Seconds
Utilization process system 25.0000 Percent
Queue Length process system 0.3333 Requests
Residence Time process system 0.0400 Seconds
|
Взгляните на часть отчета с выходными данными и обратите внимание на то, что среднее время отклика уменьшилось по сравнению с листингом 13, а максимальное количество запросов в секунду возросло с 12.5 до 20. Это произошло благодаря тому, что в новой модели предусмотрена конвейерная обработка. Пока происходит передача одного запроса в базу данных, другой запрос может обрабатываться центральным процессором. Это невозможно было рассчитать в предыдущей модели, поскольку в ней использовалась всего одна очередь.
Еще важнее то, что вы можете видеть, что база данных загружена на 42%, а центральный процессор – только на 25%. Таким образом, именно база данных является тем ресурсом, который будет исчерпан первым при высокой загрузке системы.
Увеличьте частоту поступления запросов до 60 000 в час, и вы увидите, что среднее время отклика возрастет до 0.36 секунд, а загрузка базы данных составит 83%. Также вы увидите, что 0.30 секунды из 0.36 уходит на ожидание ответа от базы данных. Таким образом, время обработки запросов можно улучшить, ускорив доступ к базе данных.
Вы можете определить максимальную производительность различными способами. Производительность системы составляет 100% при 20 запросах в секунду (верхняя часть отчета). Вы также можете определить производительность в терминах времени среднего отклика. Приблизительно при 15 запросах в секунду время отклика превысит четверть секунды. Если ваша задача - сохранить время отклика меньше этого значения, то на этом этапе ваша система исчерпает ресурсы, хотя у вас и останется аппаратный запас мощностей.
Использование графиков для анализа производительности
Графики предоставляют отличную возможность для отображения статистической информации. Вы можете построить график за продолжительный период времени, например, за 6 месяцев или год, и получить представление о темпах роста. На рисунке 6 представлен график использования ресурсов процессора сервером приложений в течение года. Величины средней ежедневной загрузки были загружены в электронную таблицу и представлены в виде графика. На рисунке также была добавлена линия тенденции изменения, позволяющая увидеть рост.
Рисунок 6. График использования центрального процессора сервера
На основании этого графика вы можете планировать загрузку системы в будущем (исходя из предположения, что темпы роста остаются постоянными). На рисунке 6 рост составляет приблизительно 10% каждые 3 месяца. Влияние загрузки очередей более заметно при более высокой загрузке, поэтому может оказаться, что обновление системы целесообразно произвести, не дожидаясь, пока загрузка достигнет 100%.
Как строить графики
Построение графиков в электронной таблице плохо подходит для анализа множества серверов, для каждого из которых имеется свой набор данных измерений. Один из методов предусматривает загрузку выходных данных sar в утилиту построения графиков наподобие GNUplot. Также можно обратить внимание на другие доступные инструменты построения графиков, многие из которых распространяются по лицензии open source. В их числе - ряд утилит, основанных на пакете RRDTool.
RRDTool – это набор программ и библиотек, которые помещают данные в кольцевую базу данных формата RRD (Round-robin database). База данных RRD непрерывно архивирует данные по мере их поступления, поэтому вы можете иметь ежечасные данные за последний год и пятиминутные средние значения за неделю. Размер базы данных формата RRD всегда остается постоянным, поскольку старые данные удаляются. Пакет RRDTool также содержит инструменты для построения графиков.
В разделе Ресурсы приведено несколько ссылок на утилиты для построения графиков.
Что включать в графики
В графики следует включать любую информацию, которая важна для вашей службы, а также все, что потенциально может использоваться для принятия решений. Графики также помогают понять, что происходило в прошлом, так что вы можете строить графики таких величин, как, например, скорость вентиляторов. Тем не менее обычно ваше внимание будет сфокусировано на статистике загрузки центрального процессора, памяти, диска и сети. При возможности стройте графики времени отклика от работающих служб. Это поможет вам не только принимать лучшие решения для организации работы пользователей, но и разрабатывать различные модели вашей системы.
| |
