Удаленный Postgresql - чрезвычайно медленный

Question

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

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

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

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

Things отметить:

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

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

VPS работает 100MBPS, а затем компьютер, с которым я подключаюсь, находится на линии 8MB.

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

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

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

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

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

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

Подключение через удаленную сеть через локальную сеть осуществляется мгновенно.

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

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

Edit: Обратите внимание, что клиент и сервер как работает 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

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

Answer 3

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

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

Если это не так, пожалуйста, напишите pg_hba.conf (без ранений).

Другой Возможные причины:

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

Были напуганы этой проблемой на некоторое время, и этот вопрос привел меня к ответу, поэтому я подумал, что поделился бы тем, что он помогает.

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

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