Здравствуйте.

Решил начать использовать расширение postgres_fdw, уж очень много плюшек сулит его использование, особенно в моем проекте с десятками серверов, каждый из которых несет уникальную функциональность в рамках проекта. Пока ставил и настраивал, все было красиво, но вот реальность оказалась очень печальной и я не пойму в чем дело, какие-то неверные настройки, неверное использование или данное расширение просто тормознутое.

Главный сервер - 40 ядер, 64GB оперативки, 3 tablespace, важные данные на RAID5 из 3 SSD дисков, индексы лежат на отдельном SSD, разные кэшданные рассчитываемые на лету потерять которые не жалко ибо всегда могут быть пересчитаны - еще один SSD.

Разных тестов в разных режимах провел много, вот один из них.

Имеется SQL запрос, insert 3 bigint чуть больше 40K записей, размер запроса около 800kB.

Вставляю его в базу, время работы 200-500ms.

Далее делаю внешние сервера и внешние таблицы ровно точно такой же структуры и делаю ровно тот же insert только в эти внешние таблицы, результаты такие

Вставка в другую базу на том же самом сервере - 3.5-4 сек - уже непонятно с чего такое замедление

Вставка на виртуалку в той же физической и логической сети на 1Gb, 2 ядра, 12GB оперативки, одна tablespace на SAS дисках, RAID или нет не знаю. Время работы 23.7 сек. Замедление тоже непонятно, хотя должно быть, все таки не столько мощи и передача по сети.

Вставка на другой физический сервер доступный по сети, до канала 1Gb - канал 100Mb - от канала 1Gb, эффективная скорость между серверами 35-44Mb, 40 ядер, 64GB оперативки, 2 tablespace важные данные на RAID5 из 3 SSD дисков, индексы лежат на отдельном SSD. Время работы 28 мин 40 сек. Вообще нет никаких предположений с чем связано такое замедление.

Первое на что подумано было - сеть, все проверили - загрузку канала, роутинги, как ни крути при эффективной скорости канала между 2-мя сервера в 44Mb, по скорости исполнения запроса получается всего 9-11Mb, что крайне сомнительно, есть основания полагать, что либо что-то не то в настройках одного или обоих PG, либо сам postgres_fdw видя что сервер из другой подсети начинает умничать и бить данные на пакеты не эффективно, которые плохо сочетаются с настройками сетевого оборудования.

Похожая описанной ситуация и при чтении данных, т.е. чтение данных с удаленных серверов, при чтении с самого себя время увеличивается на 1-2%, при чтении с виртуалки на 15-20%, при чтении с удаленного сервера время чтения в 3-5 раз больше, чем надо на то, чтобы ответ пропихнуть по каналу. Исходя из описаний устройства самого postgres_fdw ничего не указывает на причины такого замедления.

Ради интереса исследовали предположение, что возможно postgres_fdw запрос вида

insert values (),(),() бьет по каким-то причинам на 3 запроса вставки по одной записи, тест со вставкой в ту же таблицу сразу 10 записей работает в 2 раза медленее на удаленном сервере, чем в одном запросе подать 10 запросов по вставке одной записи. Это вообще вызывает кучу вопросов, должно быть все наоборот или хотя бы так же, если бы предположение было верным.

Maxim Boguk,

PING 10.125.3.235 (10.125.3.235) 56(84) bytes of data.
64 bytes from 10.125.3.235: icmp_seq=1 ttl=62 time=18.1 ms
64 bytes from 10.125.3.235: icmp_seq=2 ttl=62 time=21.6 ms

insert into groupe_tree_cache (parent_id, child_id, groupe_tree_cache_id) values
(1, 2, 3),
(1, 2, 3),
(1, 2, 3),
еще 40000 подобных строк

Maxim Boguk,

Где это можно прочесть, в документации ничего про это нет, либо прошляпил. Когда стало тормозить с выборками, пошел читать описание как оно работает с точки зрения запроса данных, на чьей стороне исполняется запрос, какие данные запрашиваются, фильтрация и т.д.

P.S. Про работу с INSERT

Большое спасибо, с чтением данных очень сильно помогло, с другого удаленного железного сервера на том же канале 140K записей, ответ в виде CSV размером примерно 30MB с настройками по умолчанию чтение идет 24 сек, с установкой fetch_size=1000000 чтение идет 9 сек, если это читать просто с помощью PgAdmin на прямую то чтение данных идет 7.5 сек, если подать запрос на прямую с основного сервера через psql, то 7-7.5 сек - это приемлемое замедление, 10-15% на фоне удобства разработки появляющихся новых возможностей - это хорошо.

По поводу изменения данных хорошо бы почитать где это написано, а так будем думать.

Собственно именно это я и держал в голове, что надо инициатора поменять + некоторые нюансы конкретной нашей реализации.

P.S. А где вы прочли про внутреннюю реализацию?

Maxim Boguk,

Большое спасибо за советы и ответы.

В исходники было бы интересно слазить, да начальство меня пристрелит на месте за это :)

P.S. Не ожидал такого быстрого ответа на такой не простой вопрос, мои вопросы обычно остаются без ответов, почему и не хожу практически на форумы.

Если я правильно понял, то построчная обработка запросов на изменение данных - это не особенность реализации postgres_fdw, это вообще реализация fdw механизма и надо как минимум ждать доработки самого механизма, а потом уже доработку postgres_fdw, что скорее всего произойдет одновременно.