Як налагодити тайм-аути apache?

Я запускаю веб-додаток PHP на сервері Apache 2.2 (Ubuntu Server 10.04, 8x2GHz, 12Gb RAM), використовуючи prefork. Щодня Apache отримує близько 100k-200k запитів, з них близько 100-200 звернень до межі часу очікування (тобто приблизно один на кожну тисячу), майже всі інші запити подаються набагато нижче часу очікування.

Що я можу зробити, щоб дізнатися, чому це відбувається? Або це нормально, щоб деякі невеликі частини всіх запитів закінчувались?

Це те, що я робив до цього часу:

Як видно, дуже мало запитів, які знаходяться між обмеженням часу та більш розумним запитом. Наразі обмеження на час очікування встановлено на 50 секунд, раніше воно було встановлено на 300, і все ще була така ж ситуація з деякими тайм-аутами, а потім величезна відстань в порівнянні з іншими запитами.

Усі запити, які вичерпуються, - це AJAXзапити, але тоді переважна більшість є, тому, можливо, це більше збіг обставин. Код повернення Apache є 200, але чітко досягнуто обмеження на час очікування. Вони є з широкого спектру різних IP-адрес.

Я переглянув запити, які вичерпуються, і в них немає нічого особливого, якщо я роблю ті самі запити, які вони проходять набагато менше секунди.

Я намагався подивитися на різні ресурси, щоб побачити, чи зможу я знайти причину, але не пощастило. Вільної пам’яті завжди багато (мінімум близько 3 Гб вільної), завантаження іноді досягає 1,4, а використання процесора - до 40%, але багато час очікування трапляється, коли завантаження та використання процесора низькі. Запис / читання диска майже постійний протягом дня. У журналі повільних запитів MySQL немає записів (встановлено для того, щоб записувати що-небудь понад 1 секунду), жоден запит не використовує, що багато баз даних записують / читають.

Синій - це використання процесора, який досягає 40%, бордовий - навантаження з піком в 1,4. Тож ми можемо побачити, що ми отримуємо тайм-аути навіть при низькому використанні / завантаженні процесора (десять секундних шипів добре відповідають використанню процесора, але це інша проблема, я більше сподіваюся з'ясувати, що може спричинити це).

У журналі помилок Apache немає помилок, і я не бачив, щоб він досяг більше 200 активних процесів Apache.

Налаштування сервера:

Timeout 50 
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 2

<IfModule mpm_prefork_module>
    ServerLimit     350
    StartServers        20
    MinSpareServers     75
    MaxSpareServers     150
    MaxClients          320
    MaxRequestsPerChild 5000
</IfModule>

Оновлення:

Я оновив до Ubuntu 12.04.1, про всяк випадок, жодних змін. Я додав mod_reqtimeout з налаштуваннями:

RequestReadTimeout header=20-40,minrate=500
RequestReadTimeout body=10,minrate=500

Зараз майже всі тайм-аути трапляються за 10 секунд, один-два за 20 секунд. Я вважаю, що це означає, що більшість часу це питання отримує орган запиту, який проблематично отримати? Тіло запиту ніколи не повинно бути більше кількох сотень байт. Я моніторив мережевий трафік за 1 секунду, і він ніколи не перевищує 1 Мбіт / с, і я не бачу ніяких rxerrs або rxdorps, враховуючи, що сервер знаходиться на лінії 1 Гбіт / с, це не здається The HopelessN00b розмістив о. Чи може це бути лише випадком поганих підключень користувачів?

Для шипів щогодини (вони, здається, трохи крутяться, на графіках вище вони на 33 хвилини минулої години, зараз вони минули 12 хвилин), я спробував побачити, чи періодично щось працює ( крони тощо), але нічого не знайшли. Збір сміття PHP працює двічі щогодини, але не під час шипів, все ж я намагався його відключити, але це не має ніякого значення.

Я використовував dstat з --top-cpu та top, щоб роздивитись процеси під час шипів, і все, що з’являється, - апаш, який важко працює протягом декількох секунд, але жоден інший процес не використовує значний процесор.

Я зробив масштаб в графіку шипів:

Мені це здається, що апаш зупиняється на кілька секунд, а потім наполегливо працює над обробкою запитів, які надходили під час зупинки. Що може спричинити таку зупинку чи я її неправильно трактую?

Перше, що я зауважу, дивлячись на ваш перший графік, здається, щогодинне уповільнення (відбувається приблизно 40 хвилин після години), що може сприяти проблемі. Ви повинні ознайомитись із планувальниками завдань на ОС / базі даних.

Виходячи з наданих вами даних, наступним моїм кроком слід було б переглянути частоту відповідей (кількість відповідей по осі Y проти тривалості на X), але тільки з URL-адресами, які демонструють час очікування (або бажано одну URL-адресу за раз ). У типовій системі це повинно дотримуватися звичайного або пуассонового розподілу - запити, які вичерпуються, можуть просто бути частиною хвоста - у цьому випадку вам потрібно зосередити зусилля на загальній настройці. OTOH, якщо дистрибутив є двомодальним, вам потрібно шукати суперечки десь у вашому коді.

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

В блозі Server Fault є публікація,Per Second Measurements Don't Cut It ... чи можливо деякі з цих запитів стикаються з тією ж проблемою, з якою зіткнулася команда ServerFault?

Ми виявили, що ми часто відкидаємо пакети в інтерфейсах 1 Гбіт / с зі швидкістю лише 10-30 Мбіт / с, що шкодить нашій продуктивності. Це пояснюється тим, що швидкість 10-30 Мбіт / с - це дійсно кількість бітів, переданих за 5 хвилин, перетворених на швидкість однієї секунди. Коли ми зблизилися з Wireshark і застосували один мілісекундний IO-графік, ми побачили, що ми часто розриваємо 1 Мбіт на мілісекундну швидкість так званих інтерфейсів 1 Гбіт / с.