☰

Postgresql hinter Firewall: Abfrage dauert zu lange

tag-icon • tag-icon linux firewall iptables postgresql
Postgresql hinter Firewall: Abfrage dauert zu lange

Hier ist mein Setup: zwei CentOS 5.2-Boxen auf VMWare ESXi 4.0. Die IP der ersten Box ist 192.168.22.52 auf eth0 und 192.168.99.1 auf eth1. Die zweite Box läuft mit PostgreSQL 8.3 mit der IP 192.168.99.2 auf eth0. Hier sind iptables fürKasten1, für Box2 siehe Kommentar unten.

Ich habe die Portweiterleitung 5432 auf Box1 eingerichtet und kann über pgAdminIII oder psql von einem Vista-Notebook aus eine Verbindung zu PostgreSQL auf Box2 herstellen (192.168.22.1, es gibt keine anderen Boxen in diesem Subnetz, es hat einen eigenen Switch und ist physisch isoliert). Die Datenbank, mit der ich mich verbinde, hat zwei Schemata, eines ist „kleiner“ (im Grunde nur eine Tabelle), ein anderes ist größer (etwa 30 Tabellen, 100 Funktionen usw.). Ich kann also mit dem kleineren Schema arbeiten (die Tabelle durchsuchen usw.), aber wenn ich versuche, das größere Schema zu erweitern, friert pgAdminIII für etwa 20 Minuten ein.

Das PostgreSQL-Protokoll zeigt, dass eine Abfrage viel zu lange dauert:

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

Sowohl Box1 als auch Box2 sind Klone der Entwicklungsboxen und die ursprüngliche Netzwerkstruktur war anders – auf Box2 konnte direkt ohne Portweiterleitung zugegriffen werden und beim Zugriff auf die Datenbanken gab es überhaupt keine Probleme.

Wenn ich die obige Abfrage jetzt über psql auf Box2 oder dem „ursprünglichen“ Computer ausführe oder von Box1 eine Verbindung zu Box2 herstelle, wird sie sofort ausgeführt.

Während die Abfrage ausgeführt wird, meldet tcpdump auf Box2 regelmäßig:

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

Ansonsten sehe ich nicht viel Verkehr. Die MTU auf allen ethN-Schnittstellen beträgt 1500. Ping -l 1472 -f 192.168.99.1 vom Notebook geht ohne Probleme durch.

Ich vermute, dass ich etwas zu iptables oder der Netzwerkeinrichtung übersehe und würde mich über Ihren Rat freuen.

Antwort1

Einige Dinge, die Sie ausprobieren können:

  1. Überprüfen Sie zunächst, ob Ihr Netzwerk ordnungsgemäß funktioniert. Angenommen, Sie haben verwaltete Switches, überprüfen Sie die Schnittstellenstatistiken auf Geschwindigkeits-/Duplex-Fehlanpassungen oder eine nicht übereinstimmende MTU. Überprüfen bzw. ersetzen Sie die Verkabelung, wenn Fehler auftreten (z. B.: Der Versuch, GigE über Cat5 statt Cat5e auszuführen, wird wahrscheinlich Probleme verursachen).

  2. Führen Sie einige Tests durch, um zu beweisen, dass Sie zwischen den beiden Maschinen und zur externen Maschine Übertragungen mit Kabelgeschwindigkeit durchführen können. Netcat-, FTP- oder HTTP-Übertragungen sind hier ein guter Anfang (SCP wird möglicherweise CPU-gebunden und ist daher möglicherweise nicht der beste Test).

  3. Testen Sie dieselbe Abfrage lokal auf dem Postgres-Server. Wenn sie in einem angemessenen Zeitrahmen abgeschlossen wird, wissen Sie, dass es nicht an der Datenbank liegt. Wenn sie nicht abgeschlossen wird oder „zu lange“ dauert, liegt eine fehlerhafte Abfrage oder ein anderes Datenbankproblem vor, das behoben werden muss. Denken Sie unbedingt an die Speicher-E/A-Seite der Dinge. Möglicherweise überlasten Sie die Kapazität Ihrer Festplatten. Überprüfen Sie die VMware-Leistungsdiagramme, um dies zu bestätigen/ablehnen.

  4. Wenn das funktioniert, deaktivieren Sie die Firewall und führen Sie dieselbe Abfrage auf dem Postgres-Server von „box1“ aus aus. Wenn das funktioniert, ist die VM->VM-Konnektivität wahrscheinlich einwandfrei.

  5. Wenn das funktioniert, schalten Sie die Firewall wieder ein und testen Sie sie erneut. Wenn das funktioniert, liegt Ihr Problem wahrscheinlich außerhalb dieses Hosts, sodass Sie den Switch oder den externen Host debuggen müssen.

Viel Glück.

Antwort2

Sie haben ein MTU-Problem, aber ich bin mir nicht sicher, warum. Ich versuche, Ihre virtuelle Topologie hier zu verstehen.

Ihr Windows Vista-Notebook ist also mit dem „lokalen“ Netzwerk oder dem Internet verbunden?

Ich gehe davon aus, dass Ihr Windows Vista-Notebook mit dem Internet verbunden ist und dass Sie auf die externe IP-Adresse von „Box 1“ zugreifen, um die Portweiterleitung auf Port 5432 zu „Box 2“ zu nutzen. Wenn das der Fall ist, was erhalten Sie zurück, wenn Sie Folgendes versuchen:

ping -l 1472 -f <IP-Adresse von Box 1>

Edit: Okay – sehr gut. Wenn Sie möchten, führen Sie ein „ifconfig“ sowohl auf „Box 1“ als auch auf „Box 2“ aus und prüfen Sie den MTU-Wert auf jeder Ethernet-Schnittstelle. Sie sollten alle 1500 sein. (Ich versuche nur herauszufinden, warum „Box 1“ „Box 2“ mitgeteilt hat, dass sie ein 556 Byte großes Datagramm für Ihr Notebook nicht fragmentieren kann …)

Edit: Zow. Okay – das ist wild.

Wenn es nicht zu viel verlangt ist, könnten Sie den Inhalt (oder Links dazu) Ihrer iptables-Konfigurationen in die Frage posten? (Ich bin hier langsam ratlos. Was Sie beschreiben, habe ich häufig gemacht, bin mir aber nicht sicher, wie es funktioniert.)

Edit: Jetzt bin ich wieder bei dir. Okay. Ich bin jetzt etwas ratlos. Die iptables-Konfiguration scheint keine Probleme zu verursachen. Ich sehe, dass du UDP 5432 an „Box 2“ weiterleitest. Das musst du nicht weiterleiten – Postgres verwendet nur TCP. Das schadet aber nicht.

Haben Sie während Ihrer 20-minütigen Wartezeit einen Datenverkehr zwischen dem Vista-Notebook und „Box 2“ bemerkt? Können Sie diesen Zustand bei jeder Verbindung reproduzieren?

Es macht zwar keinen großen Unterschied, aber in der FORWARD-Kette auf „Box 1“ würde ich normalerweise die Regel festlegen, dass Pakete mit RELATED,ESTABLISHED ACCEPTS als erste Regel in der Kette gelten (um die Verarbeitung abzukürzen). Ich kann mir jedoch nicht vorstellen, dass dies für Sie erhebliche Auswirkungen auf die Leistung hätte.

Ich hasse es, die Antwort auf ein Problem nicht zu wissen. Das wird mich nachts wach halten.

Antwort3

Ist es denkbar, dass einer dieser Rechner versucht, IPv6 zweckentfremdet zu verwenden? Das heißt, haben Sie sichergestellt, dass IPv6 überall dort ausgeschaltet ist, wo es nicht verwendet werden soll, und, falls es überhaupt verwendet wird, richtig konfiguriert ist?

verwandte Informationen