Alterar ou não o timeout do FIN-WAIT e o FIN-WAIT-2 no kernel do Linux?

Tags: , , , , , ,

A resposta é sim, mas vamos entender um pouco sobre TCP/IP e seus estados, heim?

Quando o servidor fecha uma conexão TCP, ele envia um pacote com o bit FIN para o cliente, que então responde com um bit ACK. O cliente envia um pacote com o bit FIN definido para o servidor, que responde com um ACK e a conexão é fechada. O nome do estado desta conexão durante o período em que o servidor pega um bit ACK do cliente e depois um FIN é denominado FIN_WAIT_2. 🙂

E qual é o problema disso? Vários. O FIN_WAIT é conhecido por conseguir exaurir os recursos de seu kernel quando aparece aos montes no resultado de um nestat -anp. O interessante é que o FIN_WAIT_2 é menos danoso que o FIN_WAIT, porque cada conexão TCP/IP consome neste estado 1.5 K de memória – multiplique isso por mais de 15.000 conexões. Alguns servidores passam desse número facilmente, por isso que tem gente que prefere utilizar o Nginx. A performance dele neste cenário é bem melhor. 🙂

Uma das maiores preocupações para o ambiente web com o FIN_WAIT_2 é quanto ao erro Too Many Open Files.

Todo o Linux possui um limite de open files (8192 por default – que não é nada dependendo do servidor)  – vale lembrar que o CentOS/RedHAt/Fedora continuam com o valor em open files  1024 – que poderá ser verificado da seguinte forma:

cat /proc/sys/fs/file-max

ulimit -n

É mais do que recomendado que você aumente o número de file descriptors  no seu S.O. Isso pode ser feito com um simples parâmetro no arquivo /etc/sysctl.conf (fs.file-max = 70000)  – executando o sysctl -p para as configurações serem implementada – e nos ambientes que utilizam PAM, alterar/incluir alguns linhas no arquivo /etc/security/limits.conf:

nginx       soft    nofile   10000
nginx       hard    nofile  30000

Até aí, tudo resolvido? Não. Isso porque há um timeout configurado no Linux em 60segundos, que faz persistir as conexões em estados FIN_WAIT e FIN_WAIT_2, e pode acabar causando sérios problemas em seu Linux, mesmo que você tenha aumentado a quantidade de File Descriptors.

Você vê isso acontecer quando há um sistema que necessite se comunicar constantemente com o Microsoft Active Directory. A quantidade de conexões TCP/IP em estado FIN_WAIT ou FIN_WAIT_2 neste S.O. é absurda. Galera que trabalha com BPM, fique ligada, heim?

Este mesmo problema acontece com servidores web, então é comum alterar o timeout do FIN_WAIT de 60s para 10s. Você pode verificar este parâmetro com o seguinte comando:  cat /proc/sys/net/ipv4/tcp_fin_timeout

E para alterá-lo, é só incluir a seguinte linha abaixo no arquivo: /etc/sysctl.conf, salvar e executar o comando sysctl -p
net.ipv4.tcp_fin_timeout = 10

E aí vai mais uma dica para quem gosta de entender a fundo os parâmetros que podem ser configurados para melhorar a performance de seu S.O.. Este site traz uma série de explicações sobre alguns dos parâmetros mais obscuros, digamos assim, para o kernel do Linux e que podem ser configurados no sysctl.conf

Uma das coisas que eu também gosto de configurar nos meus S.O.s, principalmente quando eles são web servers, são os seguintes parâmetros no /etc/sysctl.conf:

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.core.netdev_max_backlog = 2500

#Tcp_tw_recycle Enable fast recycling TIME-WAIT sockets –
#tcp_tw_reuse This allows reusing of sockets which are in the TIME_WAIT state when it is safe from a protocol perspectiv.
#tcp_max_tw_buckets: Maximal number of timewait sockets held by the system simultaneously. If this number is exceeded time-wait socket is immediately destroyed and a warning is printed. This limit exists only to prevent simple DoS attacks, you must not lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than the default value.

Sempre executei a série de parametrizações que citei acima em ambientes de grande porte, sem ter tido grandes problemas, mas vale lembrar o seguinte: cada parâmetro configurado deverá ser analisado previamente e testado para que seja constada a sua efetividade e não causar novos danos.

COMPARTILHE ESTE ARTIGO

COMENTÁRIOS

7 comentários em “Alterar ou não o timeout do FIN-WAIT e o FIN-WAIT-2 no kernel do Linux?

  1. Janduci

    Artigo extremamente útil. Gostei de saber sobre a quantidade de memória alocada para o estado da conexão. A propósito, Gustavo, você conhece alguma fonte que detalhe a quantidade de memória utilizada por cada estado da conexão TCP?

    Abaixo um link muito útil e de fácil entendimento sobre os estados das conexões TCP

    http://www.google.com.br/url?sa=t&rct=j&q=state%20connection%20tcp&source=web&cd=4&ved=0CDsQFjAD&url=http%3A%2F%2Fwww.cs.northwestern.edu%2F~agupta%2Fcs340%2Fproject2%2FTCPIP_State_Transition_Diagram.pdf&ei=GCYTT436OsTL0QGa9L27Aw&usg=AFQjCNFUHxGWWK4K5C4ujJaohuY5XtMbiQ&cad=rja

    vlw

  2. Possivel Aluno

    A quantidade de memória consumida por uma conexão tcp/ip vai depender da IMPLEMENTAÇÃO da pilha de protocolos tcp/ip do Sistema Operacional utilizado. Nos BSD, isso eh bem melhor implementado, de maneira que consome menos recursos que no linux e no windows. O pior deles é no windows, que existe uma biblioteca de alto nível(a winsoc), que faz o interfaceamento da pilha de protocolos no alto nível. Isso acaba consumindo bem mais recursos que no linux e bsd….
    Claro que o valor REAL de quanto é esse consumo vai depender de algumas coisas, como a versão do Kernel em uso(e, consequementemente, da implementação da pilha tcp/ip)

  3. Gustavo Lima

    Eu já li algo a respeito quanto a possível alteração destes valores, isso seria ou possível se você mexer no kernel, falando é claro do mundo linux.

  4. Janduci

    Opa, sobre o link zuado, por favor, pesquisem no google

    TCPIP_State_Transition_Diagram

    e terão o link para o pdf

  5. Marcos Carraro

    Buenas Galera, e Guto,

    Sempre é bom estar lendo seus post, muito obrigado por compartilhar seu conhecimento com o mundo, sem termos que pagar para estar lendo dicas que realmente são valiosas.

    Costumo da uma parametrizada no kernel usando esses dois links, é claro entre outros txt perdidos pelo /var HAHAHAH

    http://www.ubuntugeek.com/performance-tuning-with-system-control-sysctl-in-ubuntu.html

    http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt

    Abraços galera, e boa revisão de kernel. HHAHAHAH

DEIXAR UM COMENTÁRIO

MENU