我在使用 Postgre SQL 作为后端的医疗记录程序时遇到了问题。
几个办公室通过 Cisco VPN 连接到公司站点。公司有一台 ASA5055，大多数站点使用 PIX。我确定速度不是问题，因为我可以通过 VPN 以大约 500KB/s 的对称速度通过网络共享发送/接收文件。
我在测试帐户的软件中运行了一份报告，该报告显示一份简单的 1 页报告，如果是 PDF 文件，则总共大约 50KB。如果在 LAN 上运行该报告，它会立即显示。当远程运行时，即使在所有其他办公室都关闭并且没有其他东西通过隧道时，也需要 40-50 秒。根据这些信息，我得知该报告的大小不超过 200KB。Ping 时间不到 100ms。
在此期间，我可以通过任务管理器观察网络接口，发现报告正以 5-10KB/s 的速度“流式传输”到客户端。
服务器是 2008R2 Enterprise，2x 4 核 Xeon，56GB 内存。系统似乎按预期运行，没有 I/O 错误。
可能是什么原因或解决方案可以解决此问题？我应该特别关注什么来进一步解决此问题？
答案1
您可能遇到了延迟问题。我见过数据库在糟糕的链接上表现得非常糟糕。我的下一步是跟踪本地和远程连接的数据包（可能可以在数据库服务器上完成），并查看数据包之间的相对时间。虽然在两种情况下，在一个流中加载单个文件可能都很快，但如果事务需要在客户端和服务器之间来回传输，延迟可能会降低可感知的吞吐量。
答案2
正如埃里克所评论的，问题可能是延迟。
您可以尝试这个实验。在psql服务器上，打开\timing并运行相关的 SQL 查询。然后在服务器上再次运行它，但要计算运行 psql 的全部时间：
time psql -c "SELECT ..."
我的理解是前者将测试服务器内部的查询时间，而后者还将包括连接开销以及与客户端来回通信的时间。现在重复测试，但psql在 VPN 的另一端运行。
结果\timing差异大吗？结果如何psql？这些答案应该有助于确认问题是否在 PostgreSQL 中，以及是否是由于 WAN 延迟造成的。
除了调整网络连接的其他方法之外，您还可以考虑使用 PostgreSQL 复制解决方案，或者如果情况的严重性值得进一步提高性能，则可以考虑在客户端使用缓存替代方案。
答案3
仅当使用以下方式获取报告时，延迟才可能是问题的原因大量小的 SQL 查询。每个查询都意味着至少一次往返服务器，并且它们不能并行运行，至少不能在同一个连接上运行。
另一方面，如果用一些大型 SQL 查询，延迟无关紧要，因为往返服务器的次数很少。在这种情况下，速度不会像下载文件时那样有太大差异，带宽是驱动因素。
要检查报告运行时运行了多少查询，您可以log_statement="all"在报告期间临时在 PostgreSQL 中设置。请参阅有关log_statement。
或者通过反复查询状态活动系统视图。