Налаштування продуктивності сервера Apache з високим навантаженням

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

• Debian Lenny (всі стабільні пакети + виправлено до оновлень безпеки)
• Apache 2.2.9
• PHP 5.2.6
• Великий екземпляр Amazon EC2

Поведінка, яку ми бачимо, полягає в тому, що Інтернет зазвичай відчуває чуйність, але з невеликою затримкою розпочинає обробляти запит - іноді частку секунди, іноді 2-3 секунди в наш піковий час використання. Про фактичне навантаження на сервер повідомляється як про дуже високу - часто 10.xx або 20.xx, як повідомляється top. Крім того, за цей час (навіть vi) запускати інші речі на сервері дуже повільно, тому навантаження, безумовно, там вище. Як не дивно, Apache залишається дуже чуйним, окрім першої затримки.

У нас Apache налаштований так, використовуючи prefork:

StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          150
MaxRequestsPerChild   0

І KeepAlive як:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

Переглядаючи сторінку статусу сервера, навіть у цей час великого навантаження ми рідко потрапляємо до шапки клієнта, зазвичай обслуговуючи між 80-100 запитами та багатьма з тих, хто знаходиться у стані очікування. Це підказує мені виключати початкову повільність запиту як "очікування обробника", але я можу помилятися.

Моніторинг CloudWatch Amazon повідомляє мені, що навіть коли наша ОС повідомляє про завантаження> 15, використання нашого примірника процесора становить від 75-80%.

Приклад виведення з top:

top - 15:47:06 up 31 days,  1:38,  8 users,  load average: 11.46, 7.10, 6.56
Tasks: 221 total,  28 running, 193 sleeping,   0 stopped,   0 zombie
Cpu(s): 66.9%us, 22.1%sy,  0.0%ni,  2.6%id,  3.1%wa,  0.0%hi,  0.7%si,  4.5%st
Mem:   7871900k total,  7850624k used,    21276k free,    68728k buffers
Swap:        0k total,        0k used,        0k free,  3750664k cached

Більшість процесів виглядають так:

24720 www-data  15   0  202m  26m 4412 S    9  0.3   0:02.97 apache2                                                                       
24530 www-data  15   0  212m  35m 4544 S    7  0.5   0:03.05 apache2                                                                       
24846 www-data  15   0  209m  33m 4420 S    7  0.4   0:01.03 apache2                                                                       
24083 www-data  15   0  211m  35m 4484 S    7  0.5   0:07.14 apache2                                                                       
24615 www-data  15   0  212m  35m 4404 S    7  0.5   0:02.89 apache2            

Приклад виведення vmstatодночасно з вищезазначеним:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 8  0      0 215084  68908 3774864    0    0   154   228    5    7 32 12 42  9
 6 21      0 198948  68936 3775740    0    0   676  2363 4022 1047 56 16  9 15
23  0      0 169460  68936 3776356    0    0   432  1372 3762  835 76 21  0  0
23  1      0 140412  68936 3776648    0    0   280     0 3157  827 70 25  0  0
20  1      0 115892  68936 3776792    0    0   188     8 2802  532 68 24  0  0
 6  1      0 133368  68936 3777780    0    0   752    71 3501  878 67 29  0  1
 0  1      0 146656  68944 3778064    0    0   308  2052 3312  850 38 17 19 24
 2  0      0 202104  68952 3778140    0    0    28    90 2617  700 44 13 33  5
 9  0      0 188960  68956 3778200    0    0     8     0 2226  475 59 17  6  2
 3  0      0 166364  68956 3778252    0    0     0    21 2288  386 65 19  1  0

І нарешті, вихід з Apache server-status:

Server uptime: 31 days 2 hours 18 minutes 31 seconds
Total accesses: 60102946 - Total Traffic: 974.5 GB
CPU Usage: u209.62 s75.19 cu0 cs0 - .0106% CPU load
22.4 requests/sec - 380.3 kB/second - 17.0 kB/request
107 requests currently being processed, 6 idle workers

C.KKKW..KWWKKWKW.KKKCKK..KKK.KKKK.KK._WK.K.K.KKKKK.K.R.KK..C.C.K
K.C.K..WK_K..KKW_CK.WK..W.KKKWKCKCKW.W_KKKKK.KKWKKKW._KKK.CKK...
KK_KWKKKWKCKCWKK.KKKCK..........................................
................................................................

Зі свого обмеженого досвіду я роблю такі висновки / питання:

• Ми можемо дозволити надто багато KeepAliveзапитів

• Я бачу деякий час, витрачений на очікування IO у vmstat, хоча не послідовно і не багато (я думаю?), Тому я не впевнений, що це велика проблема чи ні, я менш досвідчений з vmstat

• Крім того, у vmstat я бачу в деяких ітераціях ряд процесів, які чекають на його обслуговування, саме тому я приписую початкову затримку завантаження сторінки на нашому веб-сервері, можливо, помилково

• Ми обслуговуємо суміш статичного вмісту (75% або вище) та вмісту сценарію, а вміст сценарію часто досить інтенсивний для процесорів, тому важливий пошук правильного балансу між ними; довгостроково ми хочемо перенести статику в інше місце для оптимізації обох серверів, але наше програмне забезпечення сьогодні не готове до цього

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

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

Ми можемо дозволити надто багато запитів KeepAlive

Ні - keeplive ще підвищує продуктивність, сучасні браузери дуже розумні про знання , коли трубопровід і коли для виконання запитів паралельно, хоча таймаут в 5 секунд все ще досить високий, і у вас є БАГАТО серверів очікування - якщо ви » У мене ВЕЛИЧЕЗНІ проблеми із затримкою, я рекомендую зменшити це до 2-3. Це повинно трохи скоротити запуск.

Якщо ви вже не встановили mod_deflate на веб-сервері - тоді я рекомендую зробити це - і додайте ob_gzhandler () до своїх PHP-скриптів. Ви можете зробити це як автодоповнення:

if(!ob_start("ob_gzhandler")) ob_start();

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

Я рекомендую встановити верхню межу на MaxRequestsPerChild - скажіть щось на зразок 500. Це просто дозволяє певний оборот процесів, якщо у вас десь витік пам'яті. Ваші процеси httpd виглядають ВЕЛИЧЕЗНО - переконайтесь, що ви видалили не потрібні вам модулі apache, і переконайтеся, що ви подаєте статичний вміст з хорошою інформацією про кешування.

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

оновлення

Якщо статичний вміст не сильно відрізняється на сторінках, то, можливо, варто також експериментувати з:

if (count($_COOKIE)) {
    header('Connection: close');
}

на скриптах PHP теж.

Вам слід подумати про встановлення асинхронного зворотного проксі-сервера, оскільки ряд процесів у стані W теж великий. Ваші процеси Apache, здається, витрачають багато часу на надсилання вмісту для повільних клієнтів через мережу, заблоковану на цьому. Nginx або lighttpd як інтерфейс до вашого сервера Apache може різко зменшити кількість процесів у стані W. І так, вам слід обмежити кількість запитів на збереження. Напевно, варто спробувати вимкнути киепалів.

До речі, 107 процесів Apache занадто високі для 22 об / хв, мені вдалося обслуговувати 100-120 об / хв, використовуючи лише 5 процесів Apache. Можливо, наступним кроком буде профайл вашої заявки.

У вашому vmstat є два рядки, які показують, що час очікування процесора досить високий, і навколо них ви маєте неабияку кількість записів (io - bo) та перемикання контексту. Я хотів би подивитись на те, що пишуть блоки, і як усунути це очікування. Я думаю, що найбільше вдосконалення можна було б покращити вводу IO вашого диску. Перевірте syslog - встановіть його для запису асинхронізації. Переконайтеся, що кеш запису контролера працює (перевірте - у вас поганий акумулятор).

Keepalive не викликає ваших проблем з персоналом, це економить ваш час на налаштування з'єднання, якщо ви не використовуєте кеш попереду. Ви можете трохи нарізати MaxSpareServers, щоб у хрускіті ви не чекали всіх вил.

ви можете розглянути можливість вимкнення кипариву як першу спробу ...

при обробці 107 запиту я б утримав MaxSpareServers вище, ніж ви встановили ...

IMHO у довгостроковій nginx як зворотній проксі для статичного вмісту слід враховувати

Перша пропозиція: відключити кепалів. Мені це колись було потрібно, коли я міг визначити конкретну ситуацію, коли продуктивність збільшувалась, але загалом запити / сек зменшились із включеним Keepalive.

Друга пропозиція: встановіть MaxRequestsPerChild. Я лунаю symcbean тут, це допоможе в процесі перекидання в разі витоку пам'яті. 500 - це хороша відправна точка.

Третя пропозиція: збільшити MaxClients. Підрахунок для цього є (фізична пам'ять - пам'ять, яка використовується не httpd процесом) / розмір кожного процесу httpd. Залежно від того, як було складено httpd, ця кількість досягає 255. Я використовую 250 для своїх публічних серверів для роботи з скануваннями google / yahoo / MS.

Четверта пропозиція: Збільшити MaxSpareServers: щось на зразок 4-5x MinSpareServers.

Якщо заборонити ці пропозиції не вдається, я би розглядав балансування навантаження за допомогою зворотного проксі-сервера або пам'яті для БД.