Почему время отклика взрывается, когда частота запросов падает?

22

Исправление : время отклика ( %D) мкс, а не мс! 1

Это ничего не меняет в странности этого паттерна, но означает, что он практически менее разрушительный.

Почему время отклика обратно соотносится с частотой запроса?

Разве сервер не должен отвечать быстрее, когда он менее занят обработкой запросов?

Любое предложение, как заставить Apache "воспользоваться" меньшей нагрузкой?

Эта модель является периодической. Это означает, что он будет отображаться, если количество показов падает ниже 200 запросов в минуту - что происходит (из-за естественной активности пользователей) с поздней ночи до раннего утра.

Запросы - это очень простые POST, отправляющие JSON длиной менее 1000 символов - этот JSON сохраняется (добавляется в текстовый файл) - вот и все. Ответ просто "-".

Данные, показанные на графиках, были зарегистрированы с помощью самого Apache:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

apache-2.4 ubuntu-14.04 high-load

— Раффаэль
источник

2

Возможно ли, что что-то вызывает нагрузку на кеш, и в результате ему приходится восстанавливать данные с диска? Как выглядит активность диска?

— TLW

2

Эти запросы поступают в минуту или запросы обрабатываются в минуту?

— user253751

Какое программное обеспечение вы использовали для записи и построения этих данных? Искренне любопытный

— Делиссон Хунио

1

@wingleader: записано с Apache2 и подготовлено с помощью R

— Raffael

@immibis: посмотрите конфигурацию журнала, которую я добавил - я думаю, что это «прибытие»

— Раффаэль

31

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

Есть несколько ресурсов, которые могут вызвать проблемы:

Высокая загрузка процессора. Это может привести к тому, что apache будет ожидать квант времени для обработки запроса.
Высокое использование памяти. Это может сбрасывать буферы, которые позволяют apache обслуживать ресурсы, не считывая их с диска. Это также может привести к подкачке / обмену рабочих Apache.
Высокая активность диска. Это может привести к тому, что активность дискового ввода-вывода будет поставлена в очередь с соответствующими задержками в обслуживании контента.
Высокая сетевая активность. Это может привести к тому, что пакеты будут поставлены в очередь для передачи, увеличат количество попыток и в противном случае ухудшат обслуживание.

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

Если вы наблюдаете за системой muninили какой-либо другой системой, которая собирает и отображает графики использования ресурсов, вы можете найти там некоторые индикаторы. Я все еще нахожу sarболее точным.

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

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

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

— BillThor
источник

1

Ссылка на sarможет быть полезной. Я нашел это: en.wikipedia.org/wiki/Sar_(Unix)

— Роджер Липскомб

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

— Дженс Тиммерман,

8

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

Или это может быть артефакт вашего измерения - если на приведенном выше графике показаны выполненные запросы , а не поступающие запросы , скорость будет снижаться по мере увеличения времени обработки запроса (при условии конечной емкости: D).

— Кароль Новак
источник

Конечно, это всего лишь царапина на поверхности возможных причин, но вводная проблема не дает особого взгляда. Этот процесс говорит с чем-то еще? Какие типы запросов он обслуживает? Меняется ли рабочая нагрузка с течением времени? И так далее ....

— Кароль Новак

интересная перспектива, но не вписывается в периодичность и продолжительность симптомов

— Раффаэль

7

Хотя ответ @ BillThor может быть верным, маловероятно, что период низкой нагрузки полностью занят процессами резервного копирования (т. Е. Периоды точно совпадают).

Альтернативное объяснение - просто кеширование. Если данный сценарий / база данных / что-либо еще не использовалось в последнее время, соответствующие кэшированные данные могли быть удалены, чтобы освободить память для остальной части операционной системы. Это могут быть индексы в базе данных, буферы O / S по отношению к файлу или что-либо подобное. Затем запрос должен будет восстановить эту информацию, если с момента последнего запроса прошло некоторое время. В периоды занятости это не произойдет, так как последний запрос будет частым. Это также объясняет, почему вы наблюдаете низкое время отклика и высокое время отклика в период занятости.

— abligh
источник

Особенно, если кеширование запросов и / или кеширование доступа к диску. Кроме того, если есть какая-либо стратегия «повторного использования потоков», это тоже помогает.

— Маккензм

Там нет никакого чтения какого-либо участия.

— Рафаэль

1

@Raffael Я очень сомневаюсь, что вы можете гарантировать, что «никакого чтения не будет». На тривиальном уровне, предположим, что страницы Apache выгружены из памяти, потому что что-то еще требовало оперативной памяти? Предположим, что ваш MPM для Apache уменьшил количество потоков / процессов, в то время как вещи бездействуют, и есть издержки на создание новых? Вы серьезно говорите, что если вы запускаете straceпроцесс Apache, вы не видите read()системных вызовов или чего-то подобного? Это было бы довольно необычно.

— abligh

@abligh: хорошо, правильно, мой «сервис» явно не реализует ничего чтения с диска

— Раффаэль

@Raffael, если вы хотите проверить эффект кэширования ОС (только), то в течение периода занятости делайте echo 3 > /proc/sys/vm/drop_cachesкаждые 5 секунд в течение минуты и смотрите, получаете ли вы аналогичные эффекты на время отклика.

— abligh

2

То, что вы видите, выглядит для меня как статистическая проблема. Может быть и не так, ответ @ BillThor вполне может быть правильным, но я опубликую это для полноты.

Графики времени отклика основаны на процентилях. Примерный пул из 800-1000 запросов является хорошим примером для этого, пул из 50-100 запросов, возможно, не так много.

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

— Kaithar
источник

1

если наблюдение состояло только из 50-100 запросов, то действительно, это могло бы быть просто случайностью, но если вы посмотрите на график, вы увидите, что мы говорим о 60 x 5 экспериментах, каждый из которых включает от 50 до 100 запросов - этого, безусловно, достаточно для исключить случайность. Также, если вы присмотритесь, вы увидите, что стабильный средний 50-й процентиль появляется примерно при 2500 мс.

— Рафаэль

Не обязательно, это не совсем так, как ведет себя такая статистика. Например, 1000 запросов в течение 1 часа и 1000 запросов в течение 1 минуты не будут вести себя одинаково. Также, вероятно, не происходит здесь. Небольшие размеры выборки ведут себя странно, в этом случае это больше похоже на выборки 60х5. Шаблон может быть результатом нелинейной нагрузки.

— Кайтар

0

Есть ложь, большая ложь и статистика.

Моя гипотеза: у вас есть три различные категории запросов:

Нормальный поток переменных, который содержит большинство запросов, и все они выполняются в течение 200-300 мкс.
Небольшой поток с постоянной скоростью около 20 запросов в минуту (даже ночью). Каждый занимает около 2500 мкс для завершения.
Крошечный поток с постоянной скоростью около 10 запросов в минуту (даже ночью). Каждый занимает значительно более 4000 мкс.

Ночью 50 запросов в минуту составляют соответственно 20 + 20 + 10. Итак, результат 50% -ного процентиля теперь сильно зависит от результата потока 2. А 95% -ный процентиль зависит от потока 3, поэтому он никогда не может даже отображаться на графике.

В течение дня потоки 2 + 3 хорошо спрятаны над процентилем 95%.

— kubanczyk
источник

Что вы имеете в виду с потоком? Запросы абсолютно однородны, в то время как запросы клиентов абсолютно неоднородны.

— Рафаэль

0

Чем больше я на это смотрю, тем больше я склонен думать, что есть проблема со сбором данных.

Во-первых, с вашим TPS происходит нечто действительно странное. Несмотря на то, что общая картина выглядит нормально, происходит очень резкий перерыв около 9 часов вечера, а затем снова около 7 часов утра. Нормальный график будет намного более плавным во время перехода в непиковые часы.

Это говорит о том, что в профиле произошли изменения, и вы, возможно, имеете 2 разных типа клиентов:

Тот, который работает только между 7 утра (выход) и 9 вечера (выход), на больших объемах, и
другой, который, вероятно, работает круглосуточно, на более низких объемах.

Второй намек около 18:00. Большую часть времени до и после мы имеем профиль большого объема - высокий TPS и низкая задержка. Но около 18:00 происходит внезапное падение с 800-1000 об / мин до менее 400 об / мин. Что может вызвать это?

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

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

Следующие шаги

На этом этапе я бы глубоко погрузился в журналы, чтобы узнать, что отличается от 18:00 образцов с малым объемом по сравнению с образцами с большим объемом до и после него.

Я бы искал:

различия в географическом местоположении (в случае, если задержка влияет на $ request_time)
различия в URL (не должно быть)
различия в методе HTTP (POST / GET) (не должно быть)
повторные запросы с одного и того же IP
и любые другие отличия ...

Кстати, «событие» 18:00 - достаточное доказательство того, что это не имеет никакого отношения к перегруженности / активности центра обработки данных. Чтобы это было правдой, затор должен был бы вызвать снижение TPS, что возможно в 18:00, но крайне маловероятно, чтобы вызвать устойчивое и плавное изгибание TPS в течение 10 часов с 9 вечера до 7 утра.

— Натан Уэбб
источник