Enorme quantidade de conexões TIME_WAIT, diz netstat


28

Ok, isso está me assustando - vejo cerca de 1500-2500 destes:

root@wherever:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942

Esse número está mudando rapidamente.

Eu tenho uma configuração bastante apertada do iptables, então não tenho idéia do que pode causar isso. alguma ideia?

Obrigado,

Tamas

Edit: Saída de 'netstat -anp':

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -               

1
Você tem algo NFS montado na mesma máquina que está exportando?
Paul Tomblin

@Paul Tomblin: Não.
KTamas

1
Bem, você deve examinar as conexões estabelecidas para descobrir qual programa é esse. O "rcpinfo -p" também pode ajudar a descobrir o que está se comunicando com o portmapper.
cstamas

Para aqueles que encontram seu caminho aqui enquanto tentam encontrar uma maneira de ajustar o atraso no Windows, isso pode ser feito através de uma configuração do registro .
Synetech

Respostas:


22

EDIT: tcp_fin_timeout NÃO controla a duração TIME_WAIT, é codificado permanentemente aos 60s

Como mencionado por outros, ter algumas conexões TIME_WAITé uma parte normal da conexão TCP. Você pode ver o intervalo examinando /proc/sys/net/ipv4/tcp_fin_timeout:

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

E altere-o modificando esse valor:

[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

Ou permanentemente, adicionando-o ao /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Além disso, se você não usar o serviço RPC ou NFS, poderá desativá-lo:

/etc/init.d/nfsd stop

E desligue-o completamente

chkconfig nfsd off

sim, meu script ipconfig já o reduz para 30. Eu não tenho o nfsd no /etc/init.d/, mas eu tenho o portmap em execução, parei, agora os TIME_WAITs caem para algumas instâncias (1-5). Obrigado.
KTamas

18
Tcp_fin_timeout não tem nada a ver com soquetes no estado time_wait. Isso afeta fin_wait_2.
Sadiq

2
+1 para o comentário de diq. Eles não estão relacionados.
Mcauth

1
Correto ... você pode ver a contagem decrescente dos soquetes de 60, mesmo que tcp_fin_timeout seja alterado usandoss --numeric -o state time-wait dst 10.0.0.100
Greg Bray

16

TIME_WAIT é normal. É um estado após o fechamento de um soquete, usado pelo kernel para rastrear pacotes que podem ter se perdido e aparecer tarde para a festa. Um número alto de conexões TIME_WAIT é um sintoma de obter muitas conexões de vida curta, e não há nada com que se preocupar.


Esta resposta é curta e doce. Isso ajuda muito. A última frase me confundiu um pouco, mas acho que o ponto é que você precisa entender por que tantas conexões estão sendo criadas. Se você estiver gravando um cliente que gera muitas solicitações, provavelmente deseja ter certeza de que ele está configurado para reutilizar conexões existentes, em vez de criar novas para cada solicitação.
nobar 26/07

Suor curto, não completo. TIME_WAITs dependem do contexto. Se você tiver muitos deles, pode ser que alguém esteja atacando seu servidor.
Mindaugas Bernatavičius

5

Isso não é importante. Tudo o que significa é que você está abrindo e fechando muitas conexões TCP Sun RCP (1500-2500 delas a cada 2-4 minutos). O TIME_WAITestado é o que um soquete entra quando fecha, para impedir que mensagens cheguem para os aplicativos errados, como poderiam se o soquete fosse reutilizado muito rapidamente e para algumas outras finalidades úteis. Não se preocupe com isso.

(A menos que, é claro, você não esteja executando algo que deva processar tantas operações de RCP. Então, preocupe-se.)


Eu corro courier-imap e postfix, principalmente.
KTamas

4

Algo no seu sistema está executando muito RPC (Chamadas de Procedimento Remoto) dentro do seu sistema (observe que a origem e o destino são o host local). Isso costuma ser visto no lockd para montagens NFS, mas você também pode vê-lo em outras chamadas RPC, como rpc.statd ou rpc.spray.

Você pode tentar usar "lsof -i" para ver quem tem esses soquetes abertos e ver o que está fazendo isso. Provavelmente é inofensivo.


Nada incomum lá, eu vejo um TCP *: sunrpc (LISTEN) para o portmap, mas acho que isso é normal.
KTamas

Continue fazendo isso repetidamente até ver quem está abrindo a conexão.
Paul Tomblin

O netstat -epn --tcp mostrará as mesmas informações. A menos que você esteja usando o NFS, provavelmente você tem muito pouco motivo para usar o portmap. Você pode removê-lo.
21715 David Pashley

Na verdade, eu não uso o NFS, no entanto, o apt-get remove portmap quer remover o 'fam' que foi instalado automaticamente provavelmente pela libfam0 que foi instalado pelo courier-imap. O apt-cache diz que 'fam' é um pacote recomendado para libfam0.
KTamas

2

tcp_fin_timeoutNÃO controla o TIME_WAITatraso. Você pode ver isso usando ss ou netstat com -o para ver os cronômetros de contagem regressiva:

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

mesmo com tcp_fin_timeout definido como 3, a contagem regressiva para TIME_WAIT ainda inicia em 60. No entanto, se você tiver net.ipv4.tcp_tw_reuse definido como 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse), o kernel poderá reutilizar soquetes em TIME_WAIT se determinar que não haverá conflitos possíveis no TCP numeração de segmentos.


1

Eu também tive o mesmo problema. Eu me custou várias horas para descobrir o que está acontecendo. No meu caso, o motivo disso foi que o netstat tenta procurar o nome do host correspondente ao IP (presumo que ele esteja usando a API gethostbyaddr). Eu estava usando uma instalação Linux embutida que não tinha /etc/nsswitch.conf. Para minha surpresa, o problema só existe quando você está realmente executando um netstat -a (descoberto executando o portmap no modo detalhado e de depuração).

Agora, o que aconteceu foi o seguinte: Por padrão, as funções de pesquisa também tentam entrar em contato com o daemon ypbind (Sun Yellow Pages, também conhecido como NIS) para consultar um nome de host. Para consultar este serviço, o portmapper portmap deve ser contatado para obter a porta para este serviço. Agora o portmapper no meu caso foi contatado via TCP. O portmapper então informa à função libc que esse serviço não existe e a conexão TCP é fechada. Como sabemos, as conexões TCP fechadas entram no estado TIME_WAIT por algum tempo. Portanto, o netstat captura essa conexão ao listar e esta nova linha com um novo IP emite uma nova solicitação que gera uma nova conexão no estado TIME_WAIT e assim por diante ...

Para resolver esse problema, crie um /etc/nsswitch.conf que não esteja usando os serviços rpc NIS, ou seja, com o seguinte conteúdo:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.