Как НЕ получить столько подключений apache CLOSE_WAIT?

netstat показывает, что 153 соединения находятся в состоянии CLOSE_WAIT. Соединения никогда не закрываются. Поэтому со временем сервер заполняется этими соединениями, которые заполняют оперативную память, и теперь веб-сайты не загружаются.

netstat показывает много как следующее:

tcp      160      0 my_server_name:http         my_server_name:51584        CLOSE_WAIT
tcp      160      0 my_server_name:http         my_server_name:51586        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50827        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50830        CLOSE_WAIT
tcp      312      0 my_server_ip.static.:http rate-limited-proxy-72:61249 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:58663 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:34655 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:56681 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:40829 CLOSE_WAIT
tcp      576      0 my_server_ip.static.:http b3090792.crawl.yahoo.:38278 CLOSE_WAIT
tcp       47      0 my_server_ip.static.:http 203.200.5.143.ill-bgl:49379 CLOSE_WAIT

Если я посмотрю на appache error_log, то перед тем, как наступит ситуация CLOSE_WAIT, появятся следующие строки:

[warn] child process 15670 still did not exit, sending a SIGTERM
[error] child process 15670 still did not exit, sending a SIGKILL
[notice] child pid 3511 exit signal Segmentation fault (11)

Моя установка Apache 2.2.3 RAM 1024 МБ (пакетная 2048 МБ) CentOS выпуск 5.3 (финальная версия) с 2 установками WPMU 2.9.2

Фон

Сокет входит в состояние CLOSE_WAIT, когда удаленный конец завершает соединение, отправляя пакет с установленным флагом FIN. Затем он ожидает в этом состоянии локального приложения к close()сокету, а затем отправляет свой собственный FIN клиенту и переводит сокет в состояние LAST_ACK. См. Также схему перехода состояний TCP и RFC 793 .

Также обратите внимание, что CLOSE_WAIT не имеет отношения к печально известному TIME_WAIT, поскольку первый происходит в пассивной ветви закрытия (удаленный конец закрывается первым), в то время как последний в активной ветви закрытия (локальный конец закрывается первым).

Описание проблемы

Обычно соединения переходят из CLOSE_WAIT в LAST_ASK довольно быстро. Если удаленный адрес и порт продолжают быстро меняться, то значительное количество соединений в состоянии CLOSE_WAIT может быть просто следствием очень большого количества открытых, используемых и закрытых соединений. Производительность системы должна быть исследована, но сама по себе это не представляет проблемы.

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

С другой стороны, если удаленный адрес и порт остаются постоянными, а количество соединений в состоянии CLOSE_WAIT продолжает расти, это, скорее всего, указывает на проблему с приложением. Это особый случай ошибки утечки ресурса: приложение пропускает открытые сокеты вместо того, чтобы своевременно их закрывать. Это потребляет память ядра и в конечном итоге приводит к сбою приложения, когда оно достигает максимального числа дескрипторов открытых файлов.

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

Временное решение

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

Постоянное решение

Постоянное решение проблемы - развернуть версию приложения без ошибок. Степень, в которой временное решение наносит вред пользователям и бизнесу, готовность исправленной версии и состояние последней рабочей версии, помогают решить, следует ли выполнить откат до последней рабочей версии приложения или дождаться исправления.