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

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

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

• Высокая загрузка процессора. Это может привести к тому, что 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. Тот, который работает только между 7am (ish) и 9pm (ish), при больших объемах и
2. другой, который, вероятно, работает круглосуточно, при меньших объемах.

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

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

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

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

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

Я бы поискал:

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

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