Postgresql por trás do firewall: a consulta demora muito

Question

Aqui está minha configuração: duas caixas CentOS 5.2 no VMWare ESXi 4.0. A primeira caixa ip é 192.168.22.52 na eth0 e 192.168.99.1 na eth1. A segunda caixa executa o PostgreSQL 8.3 com o ip 192.168.99.2 no eth0. Aqui estão iptables para box1 , para box2, veja o comentário abaixo.

Configurei o encaminhamento de porta 5432 no box1 e pude conectar-me ao PostgreSQL no box2 via pgAdminIII ou psql do Vista notebook (192.168.22.1, não há outras caixas nesta sub-rede, ele tem seu próprio switch e é fisicamente isolado). O banco de dados ao qual estou me conectando tem dois esquemas, um é 'menor' (basicamente apenas uma tabela), outro é maior (cerca de 30 tabelas, 100 funções, etc.) Então eu posso trabalhar com o esquema menor tabela e assim por diante), mas eu quando tento expandir o esquema maior - pgAdminIII congela por 20 min ou assim.

O log do PostgreSQL mostra que há uma consulta que demora muito:

2009-06-04 21:04:46 EEST LOG:  00000: duration: 493578.874 ms  statement: 
SELECT pr.oid, pr.xmin, pr.*, format_type(TYP.oid, NULL) AS typname, 
typns.nspname AS typnsp, lanname, proargnames, proconfig,
        pg_get_userbyid(proowner) as funcowner, description
              FROM pg_proc pr
              JOIN pg_type typ ON typ.oid=prorettype
              JOIN pg_namespace typns ON typns.oid=typ.typnamespace
              JOIN pg_language lng ON lng.oid=prolang
              LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
             WHERE proisagg = FALSE AND pronamespace = 2200::oid
               AND typname <> 'trigger'
             ORDER BY proname

Tanto box1 quanto box2 são clones das caixas de desenvolvimento, e a estrutura de rede original era diferente - box2 era acessível diretamente sem o encaminhamento de porta e não havia nenhum problema em acessar os bancos de dados.

Agora, se eu executar a consulta acima via psql na caixa 2 ou na máquina 'original', ou na caixa 1 conectando à caixa 2, ela será executada imediatamente.

Durante a execução da consulta, o tcpdump na caixa2 informa periodicamente:

12:45:39.770609 IP 192.168.99.2.postgres > 192.168.22.1.49484: . 8760:10220(1460) ack 1 win 54
12:45:39.968496 IP 192.168.22.1.49484 > 192.168.99.2.postgres: . ack 10220 win 16425
12:45:39.968541 IP 192.168.99.2.postgres > 192.168.22.1.49484: . 10220:11680(1460) ack 1 win 54
12:45:39.968574 IP 192.168.99.2.postgres > 192.168.22.1.49484: . 11680:13140(1460) ack 1 win 54
12:45:39.969250 IP 192.168.22.1.49484 > 192.168.99.2.postgres: . ack 13140 win 16425
12:45:39.969275 IP 192.168.99.2.postgres > 192.168.22.1.49484: . 13140:17520(4380) ack 1 win 54
12:45:39.969408 IP 192.168.22.52 > 192.168.99.2: ICMP 192.168.22.1 unreachable - need to frag (mtu 1500), length 556

Além disso, não vejo muito tráfego. MTU em todas as interfaces ethN é 1500. ping -l 1472 -f 192.168.99.1 do notebook passa sem problemas.

Eu suspeito que estou perdendo alguma coisa sobre iptables ou configuração de rede e gostaria de receber seu conselho.

    

Answer 1

Algumas coisas para tentar:

1. Comece verificando sua rede está se comportando. Assumindo você ter gerenciado interruptores, olhe para o estatísticas de interface para velocidade / duplex incompatibilidade ou um MTU incompatível. Considere verificar / substituindo o cabeamento se alguma coisa é executando erros (por exemplo: tentando executar GigE sobre Cat5 em vez de Cat5e provavelmente dar tristeza).

2. Execute alguns testes para provar que você pode obter transferências wire-speed entre os dois máquinas e para o exterior máquina; netcat, ftp ou http transferências são um bom começo aqui (scp pode ficar ligado à CPU e, portanto, pode não ser o melhor teste).

3. Teste a mesma consulta localmente no Servidor Postgres. Se completar em um prazo adequado, você sabe não é o banco de dados. Se isso não completa ou leva "também longo ", então você tem uma consulta ruim ou outro problema de banco de dados para depurar. Certifique-se de considerar o armazenamento I / O lado das coisas; você deve ser saturando o que seus discos são capaz de fornecer. Verifica a Gráficos de desempenho do VMware para confirmar / negar.

4. Supondo que funciona, desative o firewall e execute a mesma consulta contra o servidor postgres de "box1". Se isso funcionar, a VM- > VM conectividade é provável multa.

5. Supondo que funciona, traga o firewall de backup e teste novamente. E se isso funciona, então o seu problema é provavelmente externo a esse host, deixando o interruptor ou o externo host para depurar.

Boa sorte.

    

Answer 2

Você está tendo um problema de MTU, mas não tenho certeza do motivo. Estou tentando envolver minha cabeça em sua topologia virtual aqui.

Então, o seu notebook Windows Vista está conectado à rede "local" ou à rede da Internet?

Estou supondo que o seu notebook Windows Vista esteja conectado à Internet e que você esteja acessando o endereço IP do lado externo da "caixa 1" para usar o encaminhamento de porta na porta 5432 para chegar à "caixa 2". Se for esse o caso, o que você recebe quando tenta:

ping -l 1472 -f < box 1 endereço IP >

Edit: Ok - muito bom. Se desejar, execute um "ifconfig" na "caixa 1" e na "caixa 2" e examine o valor da MTU em cada interface Ethernet. Eles devem ser todos 1500. (Eu só estou tentando entender por que "caixa 1" disse "caixa 2" que ele não poderia fragmentar um datagrama de 556 bytes para o seu bloco de anotações ...)

Editar: Zow. Ok, isso é selvagem.

Se não for pedir muito, você poderia postar o conteúdo (ou links) das suas configurações do iptables na pergunta? (Eu estou começando a ficar perplexo aqui. O que você está descrevendo é algo que eu fiz com frequência, mas não tenho certeza de como ele está sendo quebrado.)

Edit: Volte com você agora. OK. Estou ficando perplexo com isso agora. A configuração do iptables não parece estar causando nenhum problema. Eu vejo que você está encaminhando o UDP 5432 para a "caixa 2". Você não precisa encaminhar isso - o Postgres usa apenas o TCP. Isso não vai doer nada, no entanto.

Durante sua espera de 20 minutos, você viu o tráfego se movendo entre o notebook Vista e a "caixa 2"? Você consegue reproduzir essa condição toda vez que se conecta?

Não que isso faça uma grande diferença, mas na cadeia FORWARD na "caixa 1", eu normalmente criaria a regra que ACEITARia pacotes com o conjunto RELATED, ESTABLISHED definido como a primeira regra na cadeia (para curto-circuito em processamento). Eu não posso pensar que isso teria um impacto significativo no desempenho para você.

Eu odeio não saber a resposta para um problema. Isso vai me manter acordado à noite.

    

Answer 3

É concebível que uma dessas máquinas esteja tentando usar inadequadamente o IPv6? Ou seja, você certificou-se de que o IPv6 está desativado em todos os lugares onde não deveria ser usado e, se usado, configurado corretamente?