веб-сервер apache не відповідає стані сервера, показуючи всі дочірні процеси, які очікують на з'єднання [закрито]


10

Моя установка: у мене є 3 майже однакових машини для веб-серверів, які обслуговують той же самий високо завантажений динамічний веб-сайт із простим балансуванням навантаження над dns. Служба працює вже понад два роки з тим самим конфігурацією apache: apache2, php5, ubuntu 8.04 linux 2.6.24-29-сервер.

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

Я використовував apache mod_status для налагодження цієї ситуації. Таблиця показників процесів виглядає приблизно так:

_C.___K_______________________R._______.__K_K____K___C_______.__
_______C__________.___________________________________.________C
_.____K__________K___K_WK_____._K_____________________________._
W______K__________K________.____________________._______C_______
_C_.__K__K____.._.._____________________________________C_______
_R___________K___.______C________.C_________.______._____C______
____________KKC____K_____K__WC_________________C_____.__.____.__
_____________________C_________K______.____C______._____________
_.___C____.___.___________________________.K______.____K________
W__.___________________C.__.____K________K_______R_._.__._______
__C__C_.__________C__C_______._____W______________C_.___C_______
____.______C_____________C________.____C____________.________._K
__.__________.K_____________K_________._____C____.K__________KW_
__K.W________R_________._______.___W___________.____.__K_____W__
W___.___..________W____K

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Тож більшість процесів просто чекають на з'єднання. приблизно через 5 хвилин ситуація повернеться до нормального стану: у мене є найменше процесів на кожній машині, у більшості працівників є статус "".

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

ситуація однакова на всіх 3 веб-серверах (усі вони мають цей пік навантаження та невідповідний стан одночасно), тому я не маю на увазі, що це пов'язано з обладнанням. але я думаю, це може бути пов'язано з певною мережевою проблемою (tcp).

якісь ідеї?

EDIT: ще трохи інформації, яку я щойно виявив:

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

Після того, як це сталося, я зробив декілька статистичних даних про з'єднання із такою командою: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

  • 109 CLOSE_WAIT
  • 2652 ВСТАНОВЛЕНО
  • 2 FIN_WAIT1
  • 11 LAST_ACK
  • 12 СПИСОК
  • 91 SYN_RECV
  • 1 SYN_SENT
  • 16 TIME_WAIT

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

  • 4 ЗАКРИТТЯ
  • 108 ВСТАНОВЛЕНО
  • 18 FIN_WAIT1
  • 182 FIN_WAIT2
  • 37 LAST_ACK
  • 12 СПИСОК
  • 50 SYN_RECV
  • 11276 TIME_WAIT

Тож у звичайній ситуації у мене є лише 100-200 відкритих підключень клієнтів, якими обробляється апаш в цей момент. Коли у мене є цей «крах», у мене є набагато більше зв’язків. Який найкращий спосіб проаналізувати це?

EDIT2: важливими рядками в apache2.conf є:

KeepAlive On
MaxKeepAliveRequests 20
KeepAliveTimeout 1
<IfModule mpm_prefork_module>
ServerLimit           920
StartServers          30
MinSpareServers       80
MaxSpareServers      120
MaxClients          920
MaxRequestsPerChild   700
</IfModule>

Це префорк apache2 з php_mod.

На сервері є 8 ГБ оперативної пам’яті та 4-гбітний своп-розділ.


Чи показує веб-сайт однакові симптоми, коли ви запускаєте wget або згортаєтесь з локального хоста або між серверами (якщо вони є в одній мережі)?
Алекс Форбс

Можливо, дамп трафіку ( tcpdump) допоможе вам докорінитись до коріння проблеми ... btw, яка ваша політика використання пам'яті та брандмауера?
drcelus

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

Якщо ви можете підтвердити, що він працює локально, але не ззовні, це посилює справу з проблемою мережі - це означає, що ви повинні протестувати за допомогою tcpdumps та wireshark з обох кінців, щоб побачити, що проходить, а не напружуючи процеси apache. Я б також міг перевірити хост у тій самій локальній мережі, якщо це можливо. І перевірте dmesg, щоб побачити, чи є повідомлення, які можуть бути пов’язані, але звучить так, як ви вже це зробили.
Алекс Форбс

це щойно повторилося. і я зміг переконатися, що я також не в змозі підключитися локально, коли ця проблема виникає. Я також зробив декілька статистичних даних про з'єднання з netstat: дивіться текст запитання
Jeff

Відповіді:


2

Вам слід включити розширений статус mod_status ( http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendedstatus ), щоб контролювати поточні хости та запити, що обробляються. Я думаю, що є сценарій (и) / сторінок (и), котрий запускає занадто багато часу, щоб випустити з'єднання, і це робить з'єднання стеку.


1

По-перше: перевірте свій Max open filesліміт на процес. Активне з'єднання розетки вважається відкритим файлом. cat /proc/###/limitsце хороший спосіб перевірити ефективне значення для іншого процесу. Ви можете отримати список відкритих файлів, lsof -p ###де ### - ідентифікатор процесу вашого веб-сервера. Ви можете порівняти, lsof -p ### | wc -lщоб побачити, як близько ви наближаєтесь до межі. Ви також повинні бачити повідомлення у файлі помилок apache, якщо ви досягаєте межі.

Вам потрібна обробка файлів для кожного з'єднання сокета, а також для кожного cgi-скрипту або посилання на файл даних. Для 920 MaxClients слід налаштувати принаймні 4000 файлів для процесу httpd. Ви можете збільшити кількість файлів, додавши файл у /etc/security/limits.d/ із наступним вмістом. Переконайтесь, що ім’я користувача відповідає тому, що ви використовуєте для свого веб-сервера.

apache soft nofile 10000
apache hard nofile 10000

По-друге: Якщо проблема з виснаженням портів, ви можете відрегулювати деякі параметри ip у /etc/sysctl.conf. (Починаючи з net.ipv4.tcp_fin_timeout). Зазвичай це проблема лише з великою кількістю дуже малих з'єднань. Багато TIME_WAIT розеток є одним із показників цього, але це вказує на вичерпаність портів лише у разі, якщо вони супроводжуються помилками в syslog about possible SYN floodingі Sending cookies. Ви також повинні переконатися, що ваш сервер знаходиться за брандмауером, який може перешкоджати зловмисним атакам SYN.


0

Крім того, майте на увазі, що в MPM перед форфором кожен процес матиме PHP у своєму просторі пам’яті (яке його встановлення межі пам’яті?). Можливо, ви хочете спробувати перейти на MPM для робочого, який може зажадати трохи іншого модуля PHP.

Також варто віддалено сережки, щоб обрізати конфігурацію Apache сторонніх модулів

На мій досвід, такі речі ініціюються такими речами, як сканер пошукової системи або такі, як конфлікти ARP. Або рівні трафіку в якійсь пов’язаній частині мережі.

Можливо, ви знайдете корисним «сар» ... не найдружнішим, але, безумовно, корисним.

Можливо, також пов'язані з іо. Sar може сказати вам (якщо ви налаштуєте його для запису дискової активності), який середній час очікування io. Ви також можете подивитися на час очікування IO вгорі (який у відсотках, прочитайте, що це насправді означає). Це може бути суттєво, якщо ви використовуєте SAN або віртуальне середовище.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.