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

Исправление : время отклика ( %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 будет ожидать квант времени для обработки запроса.
• Высокое использование памяти. Это может сбрасывать буферы, которые позволяют apache обслуживать ресурсы, не считывая их с диска. Это также может привести к подкачке / обмену рабочих Apache.
• Высокая активность диска. Это может привести к тому, что активность дискового ввода-вывода будет поставлена ​​в очередь с соответствующими задержками в обслуживании контента.
• Высокая сетевая активность. Это может привести к тому, что пакеты будут поставлены в очередь для передачи, увеличат количество попыток и в противном случае ухудшат обслуживание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Второй намек около 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 утра.