As conexões em CLOSE_WAIT são geralmente um problema da aplicação. Eu vi muitas aplicações da computação distribuída que interagiram com as aplicações web causar CLOSE_WAIT. Observar que as conexões FIN_WAIT_2 são apenas o outro lado de uma conexão que esteja em CLOSE_WAIT.
CLOSE_WAIT é causado quando um lado da conexão tem fechado sua extremidade da conexão do TCP, mas o outro objetivo está ainda aberto. Em sistemas baseados no Unix, o soquete não é fechado até que o último processo que o manda abrir o feche. Isso significa que um ou outro a aplicação que o possui não está lendo o soquete (e assim não sabe que o outro extremidade fechado ele) nem apenas não está sendo closing ele, ou há um outro processo com esse mesmo soquete aberto.
Eis porque nós vemos este problema com computação distribuída. Tende a estar muitas conexões entrantes todo o tempo, e as linhas diferentes aceitam as conexões e bifurcam-se então fora de um processo novo para segurá-lo. Se entre a aceitação e a forquilha, uma outra conexão está aceitada, quando a forquilha acontece o segundo processo tem agora ambos os soquetes abertos, mas conhece somente aproximadamente um. Isso significa que o primeiro processo não pode fechar seu soquete até que o segundo processo retire. Se o segundo processo é vivida muito longa, então a conexão fura em CLOSE_WAIT.
Eu igualmente vi um caso onde houvesse uma condição de raça no usuário própria e os soquetes acumulassem lá.
Às vezes a computação distribuída ou os servidores de aplicações esperam que a aplicação está supor para fechar todos os soquetes não utilizados. Às vezes é apenas um erro em um dos três níveis.
O que você deve fazer é identificar que processo tem o soquete aberto. Você pode usar os pfiles chama (/proc cd; pfiles *) encontrar os processos envolveu. Tentar então figurar para fora se é um processo que tenha legìtima o soquete e não seja closing ele, ou se é um processo que não devesse o ter tido de todo. Isto dar-lhe-á uma idéia o que está indo sobre.
