LINUX.ORG.RU

При работе с PostgreSQL тормозит сеть

 , ,


0

1

Изучая производительность базы данных на наших задачах был удивлен, что тормозит сеть. Сделал простой тест, дабы убедиться.

PQexec(conn, "NOTIFY a");
PQexec(conn, "begin;NOTIFY a;commit");

Что первый, что второй вариант, выдают порядка 15000 раз в секунду. Но, если разбить вторую строчку на три запроса:

PQexec(conn, "begin");
PQexec(conn, "NOTIFY a");
PQexec(conn, "commit");
То будучи разделенными они выдадут всего 5000 раз в секунду.

Как я понял, никакого способа общаться с PostgreSQL-сервером кроме как через сокет нет. Или все-таки есть?

Может, как-то можно затюнить сам юникс сокет?

Вариант объеденять запросы в один не подходит(придется править odbc-драйвер и кучу нашего кода).

★★

Ответ на: комментарий от dizza

Тормоза в том, что мы в нашем приложении делаем много быстрых запросов и производительность упирается в сеть. В связи с чем TimesTen на наших задачах уделывает PostgreSQL как стоячего.

kulti ★★ ()
Ответ на: комментарий от kulti

Стоп-стоп. TimesTen использует локальный кеш, так? Это fприори даст лучшую производительность. Те цифры, которые ты написал, скорее всего предельные для TCP. Если хочется похожую производительность, может взять что-то вроде hazelcast, ehcache?

dizza ★★★★★ ()
Ответ на: комментарий от dizza

То, что TimesTen будет быстрее, это факт ясный. Вопрос, что можно сделать с постгресом, чтоб побыстрее работало. Вот пытаемся от посылок лишних сообщений избавится, т.к. сеть «тормозит»...

kulti ★★ ()
Ответ на: комментарий от tailgunner

Как я понял, это опция, чтобы данные не отправлялись, пока ее не отключат. Как вариант управления - интересно, но при чем здесь LD_PRELOAD? И у нас PostgreSQL на локалхосте, для unix socket подобной опции вроде нет.

kulti ★★ ()
Ответ на: комментарий от kulti

Как я понял, это опция, чтобы данные не отправлялись, пока ее не отключат.

...или до истечения тайм-аута.

Как вариант управления - интересно, но при чем здесь LD_PRELOAD?

Вбей в гугл «TCP_CORK LD_PRELOAD».

для unix socket подобной опции вроде нет.

...и это как бы намекает «попробуйте TCP-сокет» - там есть и TCP_CORK, и его противоположность TCP_NODELAY, и куча мануалов по настройке.

tailgunner ★★★★★ ()
Ответ на: комментарий от kulti

они же NoSql

Они вообще из другой оперы. Я имел в виду сделать из них локальный кеш для постгра на подобие того, что есть в timesten.

dizza ★★★★★ ()
Ответ на: комментарий от kulti

Ну, TimesTen работает (на реальных задачах) в 20-40 раз быстрее - есть куда стремиться =)

Так TimesTen имеет принципиально другую архитектуру и назначение. Вот и менять нужно архитекуру. Оптимизациями сети все равно не добъетесь тех же результатов, что и коммуникация в пределах ноды.

Как вариант можно попробовать приложение наоборот засунуть внутри постгра в виде хранимок. Если это позволяет задача.

Короче нужно описание задачи, а то все это остается гаданием на кофейной гуще.

dizza ★★★★★ ()
Ответ на: комментарий от dizza

Как вариант можно попробовать приложение наоборот засунуть внутри постгра в виде хранимок.

Как это? В смысле процедуры postgres'a? В нашем случае, это фактически означает, что нам нужно полностью переписать приложение. А задача, которая уже решена на TimesTen - это PCRF. Текущая задача - добавить поддержку еще одной БД.

kulti ★★ ()
Ответ на: комментарий от kulti

задача, которая уже решена на TimesTen

текущая задача - добавить поддержку еще одной БД.

Насколько я понял, TimeTen - это in-memory СУБД. Откуда уверенность, что задача вообще выполнима?

tailgunner ★★★★★ ()

нужно делать нескодько одновременных запросов, тогда будет ок. И откуда уверенность что тормозит именно сеть? Три команды требуют три раза запуска парсера, например. Мб это вовсе и не сеть.

mashina ★★★★★ ()
Ответ на: комментарий от tailgunner

А никто и не хочет тех же самых показателей. Хотим типа сделать решение подешевле - TimesTen стоит вполне приличных денег, и если удастся заставить работать через PostgreSQL хотя бы раз в 5 медленнее...

kulti ★★ ()
Ответ на: комментарий от dizza

Прямо сейчас статистикой не владею, так что врать не буду. Но, имхо, тут проблема в том, что переделывать мы по серьезному вряд ли будем. Есть уже работающий код через ODBC - добавляем небольшие оптимизации для PostgreSQL. И у нас уже получилось в 4-17 раз медленнее на разных тестах.

kulti ★★ ()
Ответ на: комментарий от mashina

Какой парсер? Парсер команд - он и там и там запускается одинаковое кол-во раз (только в первом случае ему еще нужно большую команду на три маленьких разбить). А если вы про парсер сообщение, которое по сети передается, то это и есть накладные расходы на работу по сети.

kulti ★★ ()
Ответ на: комментарий от kulti

и если удастся заставить работать через PostgreSQL хотя бы раз в 5 медленнее...

Начните с размещения БД на SSD... или tmpfs %)

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Ага, были у нас такие мысли))) Кстати, работа с PostgreSQL через TCP-сокет процентов на 15 быстрее, чем через Unix-сокет.

kulti ★★ ()
Ответ на: комментарий от tailgunner

Пока с дефолтными. Еще экспериментировал в libautocork, но никакого прироста производительности не наблюдал. Но я совсем немного посмотрел (по сути наискосок кишочки посмотрел и запустил), т.к. домой уже уходил. Завтра еще попробую.

kulti ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.