Частота запросов Squid и загрузка процессора (пользовательская + системная) за пять месяцев

Как упоминалось ранее, в Flickr принимаются во внимание все метрики, упоминавшиеся в предыдущем разделе. Кэши постоянно заполнены, а вытеснение идет непрерывно при отправке пользователями новых фотографий. Используется кэширование Squid на диске и в памяти, поэтому по обоим ресурсам тоже необходимо собирать данные.

Для начала взгляните на графики, представленные на рисунке, которые показывают как частота запросов влияет на системные ресурсы.

Как видно из графиков, частота запросов Squid за период сбора данных неуклонно росла. «Зигзаги» представляют пиковые периоды еженедельной активности (понедельники), о которых говорилось ранее. За тот же период времени общая загрузка процессора тоже возрастала, но непосредственного риска исчерпания ресурсов процессора пока не видно. Так как серверы Squid широко используют дисковое кэширование, также необходимо измерять и интенсивность дискового ввода/вывода. Результаты показаны на рисунке.

Ожидание и интенсивность дискового ввода/вывода на сервере Squid

Рисунок подтверждает наши предположения: количество операций, ожидающих завершения дискового ввода/вывода, почти идеально коррелирует с интенсивностью запросов. Мы знаем, что сервер Squid использует диск интенсивнее, чем любой другой ресурс (например, процессор или память). Из этого мы делаем вывод, что определяющей ресурсной метрикой является ожидание дискового ввода/вывода, как и в случае с потолком базы данных. Воспользовавшись RRDTool для получения метрик ожидания дискового ввода/вывода и интенсивности запросов, мы можем построить график по этим данным в Excel, как показано на рисунке.

Интенсивность запросов Squid и ожидание дискового ввода/вывода за день

Теперь мы ясно видим, что две метрики связаны друг с другом (по тому как они одновременно возрастают) и как ожидание дискового ввода/вывода влияет на производительность Squid.

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

Мы видим, что время обслуживания попаданий не претерпевает сколько-нибудь существенных изменений за период наблюдении (оно колеблется около 100 миллисекунд). Следует учесть, что метрика «времени обслуживания » Squid учитывает время до момента получения клиентом последнего байта ответа, а оно может изменяться в зависимости от удаленности клиента от сервера. Из диаграммы следует, что, хотя ожидание дискового ввода/вывода возросло, оно не отразилось на времени отклика сервера Squid, по крайней мере при той нагрузке, которую он испытывал. Нам хотелось бы, чтобы время обслуживания находилось в разумном диапазоне, чтобы пользователю не приходилось подолгу ждать фотографий, поэтому мы установили для этого конкретного сервера максимальное время обслуживания равным 180 миллисекундам. Но что произойдет, если объем трафика поднимет время обслуживания выше порогового значения?

Интенсивность запросов Squid и ожидание дискового ввода/вывода за день

Чтобы получить ответ на этот вопрос, мы снова займемся уже знакомым делом — повышением нагрузки. Медленно увеличивайте нагрузку на серверах, записывая их метрики. Поскольку мы теперь знаем, какой из аппаратных ресурсов следует за повышением трафика, известно, что нужно искать порог, при котором ожидание дискового ввода/вывода начинает влиять на время обслуживания попаданий в кэш. Повышение интенсивности запросов к нашему серверу Squid должно происходить медленно, чтобы избежать слишком резкого подъема частоты попадании. Как видно из рисунка, воспроизведение URL-адресов из Httperf или Siege или исключение серверов из пула с распределением нагрузки позволяет постепенно повышать частоту запросов на одном сервере Squid.

Время обслуживания попадании в кэш Squid (в миллисекундах): данные за пять месяцев

Выявление потолков Squid: время обслуживания попадании и ожидание дискового ввода/вывода

Как видите, время обслуживания растет со временем ожидания дискового ввода/вывода (что, собственно, и предполагалось). Ввиду широкого разброса размеров фотографий время обслуживания также весьма разнообразно, но время 180 миллисекунд начинает встречаться приблизительно на 40 процентах ожидания дискового ввода/вывода. Остается лишь определить интенсивность запросов, при которой достигается этот порог.

Интенсивность запросов Squid и ожидание дискового ввода/вывода, потолок

На этом рисунке мы видим искомую «красную линию» (выражаясь образно). На 40 процентах ожидания дискового ввода/вывода мы обрабатываем до 850 запросов в секунду. Если взять за основу время обслуживания, это будет максимальная производительность, которую мы можем ожидать от нашей аппаратной платформы с этой конкретной конфигурацией. Для полноты картины стоит сказать, что в эту конфигурацию входит Dell PowerEdge 2950 с шестью SAS-дисками (15 000 об./мин), 4 Гбайт ОЗУ и одним четырехъядерным процессором.

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

Частота попаданий в кэш (%) и возраст LRU (дни), данные за пять месяцев

На этих двух графиках представлена частота попаданий в кэш и эталонный возраст LRU для конкретного кэширующего сервера Squid, который использовался для обслуживания запросов в течение 5 месяцев. Частота попаданий в кэш выражена в процентах, а эталонный возраст LRU — в днях. В течение наблюдаемого периода возраст LRU и частота попаданий снижались с небольшой, но различимой скоростью, это обстоятельство объясняется возрастанием количества фотографий, отправляемых пользователями. С ростом рабочего набора запрашиваемых фотографий кэшу приходится выполнять все большую работу по вытеснению, чтобы освободить место для новых объектов. Но даже при таком снижении эффективности похоже, что при 72-процентной частоте попаданий эталонный возраст LRU для этого сервера составляет около 3 часов. Значение более чем достойное и вполне приемлемое для нашей среды. В дальнейшем следует наблюдать за частотой попаданий и изменять размер кэша в случае необходимости.

Подведем итог. В этом примере задействованы две метрики, связанные с потолками нашей системы кэширования — ожидание дискового ввода/вывода и эффективность кэширования.

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

Потолок в 850 запросов в секунду предполагает стабильную частоту попадания в кэш, которая тоже может изменяться со временем.