Запросы Apache за два дня

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

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

Чтобы различить, какими процессами потребляются те или иные ресурсы, можно выбрать один из двух путей:

  • Изоляция каждого работающего приложения и измерение его потребления ресурсов.
  • Обеспечение постоянного потребления ресурсов некоторыми приложениями.

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

Когда-то в Flickr приемом и обработкой фотографий занимались те же компьютеры, которые генерировали страницы веб-сайта Flickr.com; такая конфигурация усложняла планирование мощностей. Обработка графики требует значительных затрат процессорного времени, а с увеличением количества отправляемых фотографий увеличивалась и зависимость компьютеров от ресурсов дискового ввода/вывода. Добавьте к этому рост трафика, и мы быстро убедимся в том, что все три разные функции сражаются за одни и те же ресурсы.

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

  • отправка фотографии (в основном дисковый ввод/вывод и сетевые ресурсы);
  • обработка графики (процессор);
  • генерирование страниц сайта (память и процессор)

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

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

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

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

Функционирование веб-сервера и общая загрузка процессора за два дня

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

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

Общая загрузка процессора и интенсивность обработки фотографий за два дня

Мы располагали всеми данными необходимыми для обоснованной оценки того, какие ресурсы процессора расходовались на обработку изображений (в отличие от ресурсов, необходимых для обслуживания запросов Apache). Оставалось только проанализировать данные для получения конкретных значений.

Как видно из рисунка, по крайней мере в эти конкретные выходные обработка каждых 30 фотографий в минуту повышала загрузку процессора на лишние 25 процентов.

Интенсивность обработки фотографий в субботу и воскресенье

Мы получили чрезвычайно грубую оценку, которая базируется на малом и статистически незначительном наборе данных. Рассматривайте ее всего лишь как пример изоляции использования ресурсов в многофункциональной системе. Более корректное подтверждение соотношения 25:30 потребовало бы анализа большего объема трафика и интенсивности отправки, с последующим повторным сравнением данных. Но этот процесс предоставляет в наше распоряжение отправную точку, на которой могут базироваться оценки потолков.

Интенсивность обработки фотографий и загрузка процессора за два дня

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