Início / dba / Perguntas / 59650
Accepted
Harel
Asked: 2014-02-26 14:40:13 +0800 CST

pgBouncer funciona muito bem, mas ocasionalmente fica indisponível

  • 772

Estou executando o pgBouncer na frente de um banco de dados postgres 9 ocupado. Na maioria das vezes funciona bem. Mas, a cada poucas horas, recebo um e-mail de erro do meu aplicativo, com exceção do psycopg2:

OperationalError('não foi possível conectar ao servidor: não é possível atribuir o endereço solicitado O servidor está sendo executado no host "neo-hulk" e aceita conexões TCP/IP na porta 6432?')

Este é um aplicativo python com vários trabalhadores de aipo executando tarefas. Quando esses erros chegam, verifico o pgbouncer db e o tamanho do pool está dentro dos limites. Depois de algumas experiências, defini o tamanho máximo do pool para 400 e o tamanho do pool para 200. O modo pool é "sessão" (as solicitações são, em sua maioria, de confirmação automática, quase sem transações).

O que faz o pgBouncer 'desaparecer' assim? é apenas por curtos períodos de tempo (e, no total, estamos falando de uma pequena quantidade de solicitações em comparação com o grande volume de solicitações atendidas), mas as solicitações que falham são importantes.

Obrigado!

postgresql python

1 respostas

  1. Best Answer

    A parte " Não é possível atribuir o endereço solicitado " na mensagem de erro vem da pilha TCP do kernel. Quando encontrado de forma intermitente, isso normalmente significa que o espaço de soquetes disponíveis está esgotado devido a muitos soquetes em estado de espera ( TIME_WAIT, ou menos provavelmente FIN_WAIT_1ou FIN_WAIT_2)

    A faixa de portas de soquete pode ser gerada por cat /proc/sys/net/ipv4/ip_local_port_range. O valor padrão em um kernel padrão do Linux é geralmente 32768 61000.

    Você pode verificar o resultado netstat -ton|grep WAITno(s) cliente(s) e no host do pgBouncer quando o sistema estiver ocupado. O -osinalizador mostrará os contadores de timeout relacionados aos estados de espera.

    Se o número total de soquetes TCP estiver próximo 61000-32768=28232, o problema provavelmente será o esgotamento desse intervalo. Como um soquete fechado gasta 60 segundos no TIME_WAITestado em condições normais, se um host cliente se conectar mais de 28232 vezes em um minuto, novas conexões falharão com o erro mencionado até que as portas sejam liberadas.

    Como primeira solução alternativa, o intervalo de portas TCP pode ser estendido:

     # echo "1025 65535" >/proc/sys/net/ipv4/ip_local_port_range

    Se não for satisfatório, verifique os sinalizadores tcp_tw_recyclee , também sintonizáveis ​​por e .tcp_tw_reuse/proc/sys/net/ipv4sysctl

    Eles são definidos como (de man tcp):

           tcp_tw_recycle (Booleano; padrão: desativado; desde o Linux 2.4)
              Habilita a reciclagem rápida de soquetes TIME_WAIT. Habilitando isso
              opção não é recomendada, pois causa problemas durante o trabalho
              com NAT (Network Address Translation).

       tcp_tw_reuse (Booleano; padrão: desabilitado; desde Linux 2.4.19/2.6)
              Permitir a reutilização de soquetes TIME_WAIT para novas conexões quando for
              seguro do ponto de vista do protocolo. Não deve ser alterado sem
              conselho/solicitação de especialistas técnicos.

    Pessoalmente, tive sucesso tcp_tw_recyclequando enfrentei esse problema com um aplicativo cliente MySQL, mas não tome isso como uma recomendação, pois meu entendimento do TCP é, na melhor das hipóteses, superficial.

    • 20

relate perguntas