Postgresql за брандмауэром: запрос выполняется слишком долго

Postgresql за брандмауэром: запрос выполняется слишком долго

Вот моя настройка: два компьютера CentOS 5.2 на VMWare ESXi 4.0. IP первого компьютера 192.168.22.52 на eth0 и 192.168.99.1 на eth1. На втором компьютере запущен PostgreSQL 8.3 с IP 192.168.99.2 на eth0. Вот iptables длякоробка1, для box2 см. комментарий ниже.

Я настроил переадресацию порта 5432 на box1 и могу подключиться к PostgreSQL на box2 через pgAdminIII или psql с ноутбука Vista (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 — являются клонами устройств разработки, и исходная сетевая структура была иной: box2 был доступен напрямую, без переадресации портов, и не возникало никаких проблем с доступом к базам данных.

Теперь, если я запущу указанный выше запрос через psql на box2 или «исходной» машине, или с box1, подключенного к box2, он выполнится немедленно.

Во время выполнения запроса tcpdump на box2 периодически выдает:

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

В остальном трафика особого не вижу. MTU на всех интерфейсах ethN 1500. ping -l 1472 -f 192.168.99.1 с ноутбука проходит без проблем.

Я подозреваю, что упускаю что-то в настройках iptables или сети, и был бы признателен за ваш совет.

решение1

Вот что стоит попробовать:

  1. Начните с проверки того, что ваша сеть ведет себя нормально. Предполагая, что у вас есть управляемые коммутаторы, посмотрите статистику интерфейса на предмет несоответствия скорости/дуплекса или несоответствия MTU. Рассмотрите возможность проверки/замены кабелей, если что-то работает с ошибками (например, попытка запустить GigE по Cat5 вместо Cat5e, скорее всего, приведет к неприятностям).

  2. Проведите несколько тестов, чтобы убедиться, что вы можете осуществлять передачу данных со скоростью кабеля между двумя машинами и на внешнюю машину; для начала подойдут передачи данных через netcat, ftp или http (scp может ограничивать производительность ЦП, поэтому этот тест может оказаться не лучшим).

  3. Проверьте тот же запрос локально на сервере Postgres. Если он завершается в соответствующие сроки, вы знаете, что это не база данных. Если он не завершается или выполняется «слишком долго», то у вас плохой запрос или другая проблема с базой данных, которую нужно отладить. Обязательно рассмотрите сторону ввода-вывода хранилища; вы можете перегружать то, что способны предоставить ваши диски. Проверьте графики производительности VMware, чтобы подтвердить или опровергнуть.

  4. Если это работает, отключите брандмауэр и выполните тот же запрос на сервере postgres из "box1". Если это работает, то соединение VM->VM, скорее всего, в порядке.

  5. Если это сработает, верните брандмауэр в рабочее состояние и проверьте снова. Если это сработает, то ваша проблема, скорее всего, внешняя по отношению к этому хосту, оставляя коммутатор или внешний хост для отладки.

Удачи.

решение2

У вас проблема с MTU, но я не уверен, почему. Я пытаюсь разобраться в вашей виртуальной топологии.

Итак, ваш ноутбук с Windows Vista подключен к «локальной» сети или к сети Интернет?

Я предполагаю, что ваш ноутбук с Windows Vista подключен к Интернету и что вы обращаетесь к внешнему IP-адресу "box 1", чтобы использовать переадресацию порта 5432 для доступа к "box 2". Если это так, что вы получаете в ответ, когда пытаетесь:

ping -l 1472 -f <IP-адрес ящика 1>

Редактировать: Хорошо -- очень хорошо. Если вы это сделаете, запустите "ifconfig" на "box 1" и "box 2" и проверьте значение MTU на каждом интерфейсе Ethernet. Они все должны быть 1500. (Я просто пытаюсь понять, почему "box 1" сообщил "box 2", что он не может фрагментировать 556-байтовую датаграмму, связанную с вашим ноутбуком...)

Редактировать: Ого. Ладно, это дико.

Если это не слишком большая просьба, не могли бы вы разместить содержимое (или ссылки на него) ваших конфигураций iptables в вопросе? (Я начинаю приходить в замешательство. То, что вы описываете, я часто делаю, но не уверен, как это работает.)

Редактировать: Снова с вами. Хорошо. Теперь я начинаю путаться. Конфигурация iptables не выглядит так, как будто она должна вызывать какие-либо проблемы. Я вижу, что вы перенаправляете UDP 5432 на "box 2". Вам не нужно это перенаправлять — Postgres использует только TCP. Хотя это ничему не повредит.

За 20 минут ожидания вы видели движение трафика между ноутбуком Vista и "box 2"? Можете ли вы воспроизвести это состояние каждый раз при подключении?

Не то чтобы это имело большое значение, но в цепочке FORWARD на "box 1" я бы обычно делал правило, которое ПРИНИМАЕТ пакеты с RELATED,ESTABLISHED, установленным первым правилом в цепочке (для укорачивания обработки). Я не думаю, что это окажет какое-либо существенное влияние на производительность для вас, хотя.

Ненавижу не знать ответа на вопрос. Это не даст мне спать по ночам.

решение3

Возможно ли, что одна из этих машин пытается ненадлежащим образом использовать IPv6? То есть, вы убедились, что IPv6 отключен везде, где он не должен использоваться, и, если используется вообще, правильно ли настроен?

Связанный контент