Чому час виклику вибухає, коли частота запиту падає?

Виправлення : час відгуку ( %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

Це звичайна поведінка в центрах обробки даних. Час, коли ваш час відповіді повільний, відповідає тому, що зазвичай називається Пакетне вікно. Це період часу, коли очікується, що активність користувачів буде низькою, і пакетні процеси можуть запускатися. У цей період також робляться резервні копії. Ці дії можуть напружувати ресурси сервера та мереж, спричиняючи такі проблеми, як ви бачите.

Є кілька ресурсів, які можуть спричинити проблеми:

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

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

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

Є такі інструменти , як niceі ioniceякі можуть бути застосовані для періодичних процесів , щоб мінімізувати їх вплив. Вони ефективні лише для питань процесора або вводу / виводу. Вони навряд чи зможуть вирішити проблеми із пам’яттю чи мережевою діяльністю.

Переміщення резервної активності в окрему мережу та зменшення конфлікту в мережі. Деякі програми резервного копіювання можуть бути налаштовані для обмеження пропускної здатності, яка буде використовуватися. Це може вирішити суперечки з мережею.

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

Це відношення може статися в іншому напрямку, якщо відправники запиту чекають завершення попереднього запиту, перш ніж надсилати новий. У такому випадку трафік падає, коли час запитів зростає (з будь-якої причини), завдяки черзі на стороні клієнта.

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

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

Альтернативне пояснення - просто кешування. Якщо певний скрипт / база даних / все, що нещодавно не використовувалося, відповідні кешовані дані можуть бути скинуті, щоб звільнити пам'ять для решти операційної системи. Це можуть бути індекси бази даних або буфери O / S стосовно файлу, або щось інше подібне. Після цього запит повинен буде відновити цю інформацію, якщо минув час з часу останнього запиту. У зайняті періоди цього не буде, оскільки останній запит був частим. Це також пояснить, чому ви бачите низький час відгуку та високий час відгуку протягом напруженого періоду.

Те, що ви там бачите, мені здається, що це може бути статистичним питанням. Це може бути не так, відповідь БіллТхора цілком може бути правильною, але я опублікую це для повноти.

Графіки часу реакції на основі відсотків. Зразковий пул з 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 відбувається щось дійсно дивне. Хоча загальна картина виглядає нормально, спостерігається дуже різка перерва, яка виникає близько 21:00, а потім знову близько 7 ранку. Нормальний графік буде значно плавнішим під час переходу на години, які не є піковими.

Це говорить про те, що в профілі є зміна, і, можливо, у вас є два різних типи клієнтів:

1. Той, який працює лише з 7 ранку (іш) до 21 вечора (іш), при великих обсягах і
2. інша, яка, ймовірно, працює цілодобово, при менших обсягах.

Другий натяк - близько 18:00. Більшу частину часу до і після ми маємо високий профіль гучності - висока TPS і низька затримка. Але приблизно о 18:00 спостерігається раптове падіння з 800-1000 об / хв до менше 400 об / хв. Що може це спричинити?

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

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

Наступні кроки

На цьому етапі я б глибоко занурився в колоди, щоб з’ясувати, чим відрізняється проба з низьким обсягом 18:00 порівняно із зразками великого обсягу до та після неї.

Я б шукав:

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

До речі, "подія" о 18:00 для мене є достатнім свідченням того, що це не має нічого спільного з перевантаженістю / активністю центру обробки даних. Щоб це було правдою, перевантаженість повинна спричинити падіння ТПС, що можливо в 18:00, але вкрай малоймовірно, що це спричинить стійке і плавно викривлене падіння ТПС протягом 10 годин між 9:00 та 7 ранку.