Удаленный Postgresql - очень медленно

Question

Я установил PostgreSQL на VPS, который у меня есть - программное обеспечение для доступа к базе данных - это программа PokerTracker.

PokerTracker регистрирует все ваши руки и статистику во время игры в онлайн-покер.

Я хотел, чтобы это было доступно с нескольких разных компьютеров, поэтому решил установить его на свой VPS, и после нескольких сбоев мне удалось подключить его без ошибок.

Однако производительность ужасна. Я провел множество исследований по «медленному удаленному postgresql» и т. Д., И мне еще предстоит найти ответ, поэтому я надеюсь, что кто-то сможет помочь.

На что обратить внимание:

Запрос, который я пытаюсь выполнить, очень маленький. При локальном подключении к VPS запрос выполняется мгновенно.

При удаленном запуске запроса требуется около 1 минуты 30 секунд.

VPS работает со скоростью 100 МБ / с, а затем компьютер, к которому я подключаюсь, находится на линии 8 МБ.

Сетевое взаимодействие между ними происходит практически мгновенно, я могу нормально подключаться без каких-либо задержек и размещаю несколько веб-сайтов, работающих на MSSQL, и все запросы выполняются мгновенно, независимо от того, подключены ли они удаленно или локально, так что это кажется специфичным для PostgreSQL.

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

База данных - это новая база данных, в которой почти нет данных, и я провела анализ / анализ и т. Д., Но все безрезультатно, я не вижу улучшений.

Я не понимаю, как MSSQL может запрашивать практически мгновенно, но PostgreSQL так сильно борется.

Я могу без проблем подключиться к порту 5432 по IP-адресу VPS, и, как я уже сказал, запрос действительно выполняется, это занимает очень много времени.

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

Дистанционное подключение через другой компьютер через локальную сеть происходит мгновенно.

Я также отредактировал файл postgre conf, чтобы учесть больше памяти / буферов и т. Д., Но я не думаю, что это проблема - то, что я прошу это сделать, очень просто - оно не должно быть интенсивным вообще.

Спасибо, Рики

Изменить: Обратите внимание, что клиент и сервер работают под управлением Windows.

Вот информация из файлов конфигурации.

pg_hba - currently allowing all traffic:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

# IPv4 local connections:
host     all     all     0.0.0.0/0   md5
# IPv6 local connections:
# host   all     all     ::1/128     md5

И postgresqlconf - я знаю, что для этой конфигурации я выделил огромное количество буферов / памяти, просто чтобы проверить, была ли это проблема - показаны только незакомментированные строки:

listen_addresses = '*'
port = 5432
max_connections = 100
shared_buffers = 512MB
work_mem = 64MB
max_fsm_pages = 204800
shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll'
log_destination = 'stderr'
logging_collector = on
log_line_prefix = '%t '
datestyle = 'iso, mdy'
lc_messages = 'English_United States.1252'
lc_monetary = 'English_United States.1252'
lc_numeric = 'English_United States.1252'
lc_time = 'English_United States.1252'
default_text_search_config = 'pg_catalog.english'

Любая другая необходимая информация, пожалуйста, дайте мне знать. Спасибо за вашу помощь.

Answer 1

Я включил ведение журнала и отправил журналы разработчикам своего программного обеспечения.Их ответ состоял в том, что изначально программное обеспечение предназначалось для работы в локальной или почти локальной базе данных, поэтому работа на VPS, как ожидается, будет медленной - из-за задержки в сети.

Спасибо за вашу помощь, но похоже, что яУ меня нет идей, и это из-за программного обеспечения, а не PostgreSQL на VPS специально.

Спасибо, Рики

Answer 2

Вы можете сделать explain analyze, который сообщит вам время выполнения запроса на сервере (без сетевых накладных расходов на отправку результата клиенту).

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

Answer 3

Эта проблема мучила меня некоторое время, и этот вопрос привел меня к ответу, поэтому я подумал, что поделюсь, если это поможет.

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

Отключение маршрута по умолчанию заставило запросы возвращаться обратно в обычное времякадры.Но долгосрочным решением было изменить listen_addresses с '*' на правильный IP.

Answer 4

Это не ответ на вопрос, почему pg-доступ медленнее по VPN, но возможным решением / альтернативой может быть настройка TeamPostgreSQL для доступа к PG через браузер. Это веб-приложение AJAX, которое включает в себя несколько очень удобных функций для навигации по вашим данным, а также для управления базой данных.

Это также позволило бы избежать разрыва соединений, что, по моему опыту, характерно при работе с pg через VPN.

Существует также phpPgAdmin для веб-доступа, но я упоминаю TeamPostgreSQL, потому что он может быть очень полезен для навигации и получения обзора данных в базе данных.

Answer 5

Возможно, Postgres пытается аутентифицировать вас, используя идент , который не работает (например, перемотан) и должен подождать тайм-аут, прежде чем разрешить соединение другими способами.

Попробуйте запросить у select version() удаленного сервера с помощью psql - это должно быть мгновенным, поскольку оно не касается диска.

Если это не мгновенно, пожалуйста, отправьте свои pg_hba.conf (некомментированные строки).

Другая возможная причина:

• аутентификация с использованием RevDNS;
• антивирус на сервере или клиенте;
• какое-то другое соединение блокирует таблицу или строку, поскольку ононе закончился ясно.

Answer 6

Используйте инструменты мониторинга сети (я рекомендую wireshark, потому что он может отслеживать многие протоколы, в том числе postgresql), чтобы проверить, в порядке ли сетевое соединение.Вы увидите пропущенные / повторно переданные пакеты, если соединение плохое.