Resposta lenta do PostgreSQL sobre VPN

Question

Estou tendo um problema com um programa de registros médicos que usa um Postgre SQL como back-end.

Vários escritórios estão se conectando a um site corporativo via Cisco VPNs. Existe um ASA5055 no corporativo e a maioria dos sites usa um PIX. Eu determinei que a velocidade não é um problema, pois posso enviar / receber arquivos através de um netshare através da VPN a cerca de 500KB / s simetricamente.

Eu executo um relatório no software em uma conta de teste que mostra um relatório simples de uma página, se fosse um arquivo PDF, seria executado com cerca de 50 KB. Se o relatório for executado na LAN, aparecerá imediatamente. Quando executado remotamente, mesmo quando todos os outros escritórios estão fechados e nada mais está passando pelo túnel, leva de 40 a 50 segundos. Usando essa informação, percebo que o relatório não tem mais de 200 KB de tamanho. Os pings estão abaixo dos 100ms.

Durante esse tempo, posso assistir a interface de rede por meio do Gerenciador de tarefas e parece que o relatório está sendo "transmitido" para o cliente a 5-10 KB / s.

O servidor é o 2008R2 Enterprise, 2x 4 core Xeon, 56 GB de RAM. O sistema parece estar funcionando como esperado sem erros de E / S.

Quais poderiam ser algumas causas ou soluções para esse mistério? Existe alguma coisa específica que eu deva analisar para solucionar isso?

    

Answer 1

Você provavelmente está se deparando com problemas de latência. Eu vi o desempenho do banco de dados sobre links de baixa qualidade ficar absolutamente mal. Meu próximo passo seria pegar um rastreamento de pacotes de conexões locais e remotas (pode ser feito no servidor db, provavelmente), e dar uma olhada no tempo relativo entre os pacotes. Embora o bloqueio de um único arquivo em um fluxo possa ser rápido em ambos os casos, se a transação exigir algum avanço entre o cliente e a latência do servidor, isso poderá eliminar o rendimento percebido.

    

Answer 2

Como Erik comentou, o problema poderia ser latência.

Você pode tentar este experimento. Em psql no servidor, ative \timing e execute a consulta SQL relacionada. Em seguida, execute-o novamente no servidor, exceto a hora em tempo integral para executar o psql:

time psql -c "SELECT ..."

Meu entendimento é que o primeiro testará o tempo de consulta dentro do servidor, enquanto o último também incluirá a sobrecarga de conexão, e o tempo de comunicação entre o cliente e o cliente. Agora repita o teste, mas execute psql na outra extremidade da VPN.

Os resultados de \timing variam muito? Como sobre os resultados de psql ? Essas respostas devem ajudar a confirmar o problema no PostgreSQL e que isso se deve à latência da WAN.

Além de outras maneiras de ajustar sua conexão de rede, você pode considerar uma solução de replicação do PostgreSQL ou considerar alternativas de armazenamento em cache no lado do cliente, se a gravidade da situação exigir mais aprimoramentos de desempenho.

    

Answer 3

A latência provavelmente será a causa do problema apenas se o relatório for obtido com muitas pequenas consultas SQL . Cada consulta implica pelo menos uma viagem de ida e volta ao servidor e eles não podem ser executados em paralelo, pelo menos não na mesma conexão.

Por outro lado, se for feito com poucas consultas SQL grandes , a latência é irrelevante, uma vez que há poucas viagens de ida e volta ao servidor. Neste caso, a velocidade não difere tanto quanto ao baixar um arquivo, sendo a largura de banda o fator principal.

Para verificar quantas consultas são executadas quando o relatório está em execução, você pode definir temporariamente log_statement="all" no PostgreSQL durante o relatório. Consulte o documento sobre log_statement .

Ou assista em tempo real consultando repetidamente o pg_stat_activity visualização do sistema.