У меня проблема с программой медицинских записей, которая использует Postgre SQL в качестве серверной части.
Несколько офисов подключаются к корпоративному сайту через Cisco VPN. В корпоративных сетях есть ASA5055, и большинство сайтов используют PIX. Я определил, что скорость не является проблемой, поскольку я могу отправлять / получать файлы по сети через VPN со скоростью около 500 КБ / с симметрично.
Я запускаю отчет в программном обеспечении на тестовой учетной записи, который показывает простой одностраничный отчет, если бы это был файл PDF, его общий размер составлял бы около 50 КБ. Если отчет запускается в локальной сети, он появляется немедленно. При удаленном запуске, даже в то время, когда все остальные офисы закрыты и через туннель больше ничего не проходит, это занимает 40-50 секунд. Используя эту информацию, я пришел к выводу, что размер отчета не превышает 200 КБ. Пинги ниже 100 мс.
В течение этого времени я могу наблюдать за сетевым интерфейсом через диспетчер задач, и кажется, что отчет «передается» клиенту со скоростью 5-10 КБ / с.
Сервер 2008R2 Enterprise, 2x 4 ядра Xeon, 56 ГБ оперативной памяти. Система работает нормально, ошибок ввода-вывода нет.
Какие могут быть причины или решения этой загадки? Есть ли что-то конкретное, на что мне следует обратить внимание, чтобы устранить эту проблему?
Вероятно, у вас проблемы с задержкой. Я видел, как производительность базы данных по дрянным ссылкам становится настоящим злом. Следующим моим шагом было бы провести трассировку пакетов как локальных, так и удаленных соединений (возможно, это можно сделать на сервере db) и посмотреть на относительное время между пакетами. В то время как размещение одного файла в одном потоке может быть быстрым в обоих случаях, если транзакция требует некоторого обмена данными между клиентом и сервером, задержка может снизить воспринимаемую пропускную способность.
Задержка может быть причиной проблемы только в том случае, если отчет получен с множество небольших SQL-запросов. Каждый запрос подразумевает как минимум одно обращение к серверу туда и обратно, и они не могут выполняться параллельно, по крайней мере, не в одном и том же соединении.
С другой стороны, если это сделано с несколько больших SQL-запросов, задержка не имеет значения, поскольку существует несколько циклов обращения к серверу. В этом случае скорость не будет сильно отличаться, как при загрузке файла, при этом пропускная способность является движущим фактором.
Чтобы проверить, сколько запросов выполняется при выполнении отчета, вы можете временно установить log_statement="all" в PostgreSQL во время отчета. См. Документ о log_statement.
Или посмотрите его в реальном времени, неоднократно запрашивая pg_stat_activity системный вид.
Как прокомментировал Эрик, проблема может заключаться в задержке.
Вы можете попробовать этот эксперимент. В psql на сервере включите \timing и запустите соответствующий SQL-запрос. Затем снова запустите его на сервере, за исключением времени полного запуска psql:
time psql -c "SELECT ..."
Насколько я понимаю, первый будет проверять время запроса внутри сервера, а второй также будет включать накладные расходы на соединение, а также время, связанное с обменом данными с клиентом. Теперь повторите тест, но запустите psql на другом конце VPN.
Сделал ли \timing результаты сильно разнятся? Как насчет psql полученные результаты? Эти ответы должны помочь подтвердить, что проблема в PostgreSQL, и что это связано с задержкой WAN.
Помимо других способов настройки сетевого подключения, вы можете рассмотреть решение для репликации PostgreSQL или рассмотреть альтернативы кэширования на стороне клиента, если серьезность ситуации требует дальнейшего улучшения производительности.