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


Коррекция : время отклика (%D) - это мкс не мс! 1

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


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

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

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

 введите описание изображения здесь>> </a> </p>

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

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

<p> Данные, показанные на графиках, записывались с самим Apache: </p>

<pre><code>---- +: = 1 = + ----</code></pre></body></html>

22 голоса | спросил Raffael 20 J000000Wednesday16 2016, 13:11:44

6 ответов


31

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

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

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

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

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

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

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

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

ответил BillThor 20 J000000Wednesday16 2016, 16:38:38
8

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

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

ответил Karol Nowak 20 J000000Wednesday16 2016, 18:24:15
7

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

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

ответил abligh 20 J000000Wednesday16 2016, 20:05:49
2

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

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

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

ответил Kaithar 21 J000000Thursday16 2016, 11:16:52
0

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

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

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

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

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

ответил kubanczyk 22 J000000Friday16 2016, 13:02:16
0

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

Во-первых, есть что-то действительно странное в вашей 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 утра.

ответил Nathan Webb 27 J000000Wednesday16 2016, 15:03:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132