Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
 быстродействие postgres_fdw  [new]
tm123
Member

Откуда:
Сообщений: 7
Здравствуйте.

Решил начать использовать расширение 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 запросов по вставке одной записи. Это вообще вызывает кучу вопросов, должно быть все наоборот или хотя бы так же, если бы предположение было верным.
20 янв 20, 11:51    [22062920]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4071
tm123,

Для начала покажите ping от базы до "Вставка на другой физический сервер доступный по сети"
скорее всего в network latency упираетесь... она всетаки на 3-6 порядков медленее чем доступ в локальную оперативную память.

А так - на коротких запросах замедление через fdw на 1-2 порядка штатное и нормальное явление иначе бы все давно на кластерах бы сидели.

Ну и вопрос как именно ваш sql запрос выглядит.
20 янв 20, 12:54    [22062961]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4071
tm123,

Конкретно любой insert в FDW в реальности делается на fdw сторону ПОСТРОЧНО.
Поэтому 40.000 строк - 80.000*network latency между серверами времени только на сетевой обмен.
20 янв 20, 13:03    [22062965]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4071
tm123,

Скорость чтения с fdw через сеть СИЛЬНО определяется параметром fetch_size
как например разобрано в https://www.cybertec-postgresql.com/en/foreign-data-wrapper-for-postgresql-performance-tuning/
(если конечно вам много читать надо)
20 янв 20, 13:05    [22062966]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
tm123
Member

Откуда:
Сообщений: 7
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 подобных строк
20 янв 20, 13:32    [22062994]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
tm123
Member

Откуда:
Сообщений: 7
Maxim Boguk,

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

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

Сообщение было отредактировано: 20 янв 20, 13:35
20 янв 20, 13:34    [22062995]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
tm123
Member

Откуда:
Сообщений: 7
Maxim Boguk
tm123,

Скорость чтения с fdw через сеть СИЛЬНО определяется параметром fetch_size
как например разобрано в https://www.cybertec-postgresql.com/en/foreign-data-wrapper-for-postgresql-performance-tuning/
(если конечно вам много читать надо)



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

По поводу изменения данных хорошо бы почитать где это написано, а так будем думать.
20 янв 20, 14:00    [22063027]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4071
tm123
Maxim Boguk
tm123,

Скорость чтения с fdw через сеть СИЛЬНО определяется параметром fetch_size
как например разобрано в https://www.cybertec-postgresql.com/en/foreign-data-wrapper-for-postgresql-performance-tuning/
(если конечно вам много читать надо)



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

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


Память оно при таких настройках виде конечно на хосте-приемнике будет конкретно подьедать. Впрочем она дешевая ноне.
20 янв 20, 14:33    [22063053]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4071
tm123
Maxim Boguk,

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

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


Это внутренние детали реализации.
bulk insert в fdw не реализован, может когда то и сделают...

ps:
Если надо INSERT с удаленными данными - то надо fdw разворачивать так чтобы insert локально выполнялся а данные подтягивались для него с удаленного сервера (используя удачно подобранный fetch_size).
А если надо без удаленных данных вставлять прямо из кода - то возникает вопрос почему это не вставить прямо на нужном сервере.
20 янв 20, 14:37    [22063057]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
tm123
Member

Откуда:
Сообщений: 7
Maxim Boguk

Это внутренние детали реализации.
bulk insert в fdw не реализован, может когда то и сделают...

ps:
Если надо INSERT с удаленными данными - то надо fdw разворачивать так чтобы insert локально выполнялся а данные подтягивались для него с удаленного сервера (используя удачно подобранный fetch_size).
А если надо без удаленных данных вставлять прямо из кода - то возникает вопрос почему это не вставить прямо на нужном сервере.


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

P.S. А где вы прочли про внутреннюю реализацию?
20 янв 20, 16:39    [22063141]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4071
tm123
Maxim Boguk

Это внутренние детали реализации.
bulk insert в fdw не реализован, может когда то и сделают...

ps:
Если надо INSERT с удаленными данными - то надо fdw разворачивать так чтобы insert локально выполнялся а данные подтягивались для него с удаленного сервера (используя удачно подобранный fetch_size).
А если надо без удаленных данных вставлять прямо из кода - то возникает вопрос почему это не вставить прямо на нужном сервере.


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

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


В исходниках.
20 янв 20, 16:48    [22063160]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
tm123
Member

Откуда:
Сообщений: 7
Maxim Boguk,

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

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

P.S. Не ожидал такого быстрого ответа на такой не простой вопрос, мои вопросы обычно остаются без ответов, почему и не хожу практически на форумы.
20 янв 20, 17:02    [22063172]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 974
tm123,

https://github.com/postgres/postgres/blob/REL_11_STABLE/contrib/postgres_fdw/postgres_fdw.c#L1773
и вот этот раздел документации чтобы примерно представлять что есть что в FDW: https://www.postgresql.org/docs/11/fdwhandler.html
20 янв 20, 17:09    [22063178]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
tm123
Member

Откуда:
Сообщений: 7
Melkij
tm123,

https://github.com/postgres/postgres/blob/REL_11_STABLE/contrib/postgres_fdw/postgres_fdw.c#L1773
и вот этот раздел документации чтобы примерно представлять что есть что в FDW: https://www.postgresql.org/docs/11/fdwhandler.html


Если я правильно понял, то построчная обработка запросов на изменение данных - это не особенность реализации postgres_fdw, это вообще реализация fdw механизма и надо как минимум ждать доработки самого механизма, а потом уже доработку postgres_fdw, что скорее всего произойдет одновременно.
21 янв 20, 09:44    [22063484]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие postgres_fdw  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 974
ну поскольку есть callback'и BeginForeignModify и EndForeignModify - то принципиально возможно, например, собирать таплы в memory context и отправлять пачками по мере заполнения. Или сделать один COPY (но надо что-то решить со случаем если в ForeignModify будут намешаны insert/update/delete).
Далее надо проверить насколько это легально с точки зрения ожиданий поведения этого API. Лучше письмом в pgsql-hackers спросить.
21 янв 20, 10:55    [22063548]     Ответить | Цитировать Сообщить модератору
Все форумы / PostgreSQL Ответить