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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Тот, который работает только с 7:00 до 21:00, при большой громкости и
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 часов с 21:00 до 7:00.