Come NON ottenere così tante connessioni CLOSE_WAIT di Apache?

netstat mostra che ci sono 153 connessioni attive nello stato CLOSE_WAIT. Le connessioni non vengono mai chiuse. Così straordinariamente il server è pieno di queste connessioni che riempie la RAM e ora i siti Web non si caricano.

netstat mostra molti come il seguente:

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

Se guardo l'appache error_log, prima che arrivi la situazione CLOSE_WAIT ci sono linee come le seguenti

[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)

La mia configurazione Apache 2.2.3 RAM 1024 MB (scoppia 2048 MB) CentOS versione 5.3 (Final) con 2 installazioni WPMU 2.9.2

sfondo

Il socket entra nello stato CLOSE_WAIT quando l'estremità remota termina la connessione inviando un pacchetto con il flag FIN impostato. Quindi attende in questo stato l'applicazione locale al close()socket, quindi invia il proprio FIN al client e passa il socket allo stato LAST_ACK. Vedere anche il diagramma di transizione dello stato TCP e RFC 793 .

Si noti inoltre che CLOSE_WAIT non è correlato al famigerato TIME_WAIT poiché il primo si verifica sul ramo di chiusura passivo (l'estremità remota si chiude per prima) mentre il secondo sul ramo di chiusura attivo (l'estremità locale si chiude per prima).

Descrizione del problema

Normalmente le connessioni passano da CLOSE_WAIT a LAST_ASK abbastanza rapidamente. Se l'indirizzo remoto e la porta continuano a cambiare rapidamente, un numero discreto di connessioni nello stato CLOSE_WAIT potrebbe semplicemente essere la conseguenza di un numero molto elevato di connessioni aperte, utilizzate e chiuse. Le prestazioni del sistema dovrebbero essere esaminate, ma di per sé ciò non costituisce un problema.

Se l'indirizzo remoto e la porta cambiano lentamente, indica che i processi dell'applicazione devono attendere la CPU, nel qual caso le medie di carico elevato lo confermeranno.

Se d'altra parte l'indirizzo remoto e la porta rimangono costanti e il numero di connessioni nello stato CLOSE_WAIT continua a crescere, molto probabilmente indica un problema con l'applicazione. Questo è un caso speciale del bug di perdita di risorse: l'applicazione perde socket aperti invece di chiuderli tempestivamente. Questo consuma la memoria del kernel e alla fine farà fallire l'applicazione quando raggiunge il numero massimo di descrittori di file aperti.

Si noti tuttavia che il ritmo della perdita potrebbe essere lento. Accade spesso che bug come questo derivino da una mancata gestione di un'eccezione nel mezzo di una richiesta, interrompendo il flusso di esecuzione in un thread di lavoro che può successivamente impedire la pulizia (inclusa la chiusura del socket). L'eccezione illecita può verificarsi raramente.

Soluzione temporanea

La soluzione temporanea al problema è aumentare i limiti dei descrittori di file aperti e riavviare periodicamente l'applicazione quando (preferibilmente prima) il problema inizia a influire sulle prestazioni. Si noti che ciò potrebbe influire inavvertitamente sulle connessioni attualmente aperte. L'esistenza di server ridondanti e il bilanciamento del carico possono aiutare a nascondere il problema agli utenti.

Soluzione permanente

La soluzione permanente al problema è distribuire la versione dell'applicazione senza il bug. Il grado in cui la soluzione temporanea danneggia gli utenti e l'azienda, la prontezza della versione con patch e lo stato dell'ultima versione funzionante aiutano a decidere se eseguire il rollback all'ultima versione funzionante dell'applicazione o attendere la correzione.