☰

防火牆後面的 Postgresql：查詢時間太長

tag-icon • tag-icon linux firewall iptables postgresql
防火牆後面的 Postgresql：查詢時間太長

這是我的設定：VMWare ESXi 4.0 上的兩台 CentOS 5.2 機器。第一個盒子的 ip 在 eth0 上是 192.168.22.52，在 eth1 上是 192.168.99.1。第二個機器在 eth0 上執行 PostgreSQL 8.3，IP 為 192.168.99.2。這是 iptables盒子1，對於 box2，請參閱下面的評論。

我已經在 box1 上設定了連接埠 5432 轉發，並且能夠透過 pgAdminIII 或 Vista 筆記本上的 psql 連接到 box2 上的 PostgreSQL（192.168.22.1，此子網路中沒有其他盒子，它有自己的交換器並且物理隔離）。我連接的資料庫有兩種模式，一種「較小」（基本上只有一個表），另一種較大（約 30 個表、100 個函數等），因此我能夠使用較小的模式（瀏覽表等）但是當我嘗試擴展更大的模式時- pgAdminIII 凍結了20 分鐘左右。

PostgreSQL 日誌顯示有一個查詢花費的時間太長：

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

box1和box2都是開發box的克隆，原來的網路結構不同——box2可以直接訪問，不需要連接埠轉發，訪問資料庫沒有任何問題。

現在，如果我在 box2 或「原始」機器上透過 psql 執行上述查詢，或從連接到 box2 的 box1 執行上述查詢，它會立即執行。

在查詢運行期間，box2 上的 tcpdump 會定期顯示：

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

除此之外，我沒有看到太多流量。所有 ethN 介面上的 MTU 均為 1500。

我懷疑我缺少有關 iptables 或網絡設置的信息，非常感謝您的建議。

答案1

一些值得嘗試的事情：

  1. 首先驗證您的網路是否正常運作。假設您有託管交換機，請查看介面統計資料以了解速度/雙工不符或 MTU 不符的情況。如果出現任何運行錯誤，請考慮檢查/更換佈線（例如：嘗試透過 Cat5 而不是 Cat5e 運行 GigE 可能會帶來麻煩）。

  2. 執行一些測試來證明您可以在兩台機器之間以及到外部機器之間進行線速傳輸； netcat、ftp 或 http 傳輸是一個好的開始（scp 可能會受到 CPU 限制，因此可能不是最好的測試）。

  3. 在 Postgres 伺服器上本地測試相同的查詢。如果它在適當的時間範圍內完成，您就知道它不是資料庫。如果它沒有完成或花費“太長時間”，那麼您有一個錯誤的查詢或其他資料庫問題需要調試。確保考慮儲存 I/O 方面；您的磁碟所能提供的功能可能已飽和。檢查 VMware 性能圖表以確認/否認。

  4. 假設可行，請停用防火牆並從「box1」對 postgres 伺服器執行相同的查詢。如果有效，則 VM->VM 連線可能很好。

  5. 假設有效，請重新啟動防火牆並再次測試。如果有效，那麼您的問題可能是該主機外部的，需要調試交換器或外部主機。

祝你好運。

答案2

您遇到了 MTU 問題，但我不確定原因。我正在嘗試了解您的虛擬拓撲。

那麼，您的 Windows Vista 筆記型電腦連接到「本地」網絡，還是 Internet 網路？

我假設您的 Windows Vista 筆記型電腦已連接到 Internet，並且您正在存取「框 1」的外部 IP 位址，以使用連接埠 5432 上的連接埠轉送來存取「框 2」。如果是這種情況，當您嘗試執行以下操作時會得到什麼結果：

ping -l 1472 -f <框 1 IP 位址>

編輯：好的——非常好。如果願意，請在「box 1」和「box 2」上執行「ifconfig」並檢查每個乙太網路介面上的 MTU 值。它們都應該是 1500。

編輯：佐.好吧——這太瘋狂了。

如果問的不是太多，您能否將 iptables 配置的內容（或連結）發佈到問題中？ （我開始被難住了。你所描述的是我經常做的事情，但我不確定它是如何崩潰的。）

編輯：現在回到你身邊。好的。我現在對這個問題很困惑。 iptables 設定看起來不會造成任何問題。我確實看到您正在將 UDP 5432 轉發到“box 2”。您不需要轉送它——Postgres 僅使用 TCP。不過，這不會有什麼壞處。

在 20 分鐘的等待期間，您是否看到 Vista 筆記型電腦和「box 2」之間的流量移動？每次連線時都能重現這種情況嗎？

並不是說它有很大的區別，而是在「框1」上的轉發鏈上，我通常會將接受帶有RELATED,ESTABLISHED 的封包的規則設定為鏈中的第一個規則（以短路處理）。不過，我認為這不會對您產生任何重大的性能影響。

我討厭不知道問題的答案。這會讓我徹夜難眠。

答案3

是否可以想像其中一台機器試圖不當使用 IPv6？也就是說，您是否確保 IPv6 在不應該使用的地方都已關閉，並且如果使用的話，配置是否正確？

相關內容