postgres，服务器通过VBS意外关闭了连接

Question

我收到此错误：

“服务器意外关闭连接这可能意味着服务器在处理请求之前或处理时异常终止。”

使用此VBScript（vbs）：

dim cn
set cn = CreateObject("ADODB.Connection")  
cn.ConnectionString= "DSN=dsn_name_here" 
cn.open 
cn.CommandTimeout = 28800

cn.execute("vacuum analyze fund_data;")
cn.execute("vacuum analyze daily_data;") '<-- error here

这条线很好：cn.execute("vacuum analyze fund_data;")

但这行错误：cn.execute("vacuum analyze daily_data;")

我想我知道为什么以及如何预防它，但我想知道是否有更好的解决方案以及如何确定根本原因。

我认为原因与缺乏资源有关。 daily_data是一个比fund_data更大的表，我有两个其他相当大的查询运行时，这一个错误，其中一个也失败了同样的错误。我想太多了，但我如何确定根本原因？是否缺少磁盘空间？ （我知道我们没有足够的RAM，所以我认为查询正在写入磁盘。我们正在讨论升级我们的服务器，但我想了解并能够诊断。）有没有办法确定根目录？

我认为解决方案是以不同的方式对查询进行计时，以便它们不会同时运行。问题在于，因为我们渴望资源，所以一切都在缓慢运行，而且每日时间表都超额预订，我需要潜入一些vacuums。从脚本的角度（或DBA的立场）是否有更好的方法而没有进入实际查询的详细信息？

为什么postgres不会减慢或锁定查询而不是终止它们？或者其他事情没有？

PS - 我会把这个问题移到SO DBA网站，如果这更合适，但我想我会首先尝试从脚本角度提问。

编辑1：我正在运行的：

来自pgadmin：

select version();
PostgreSQL 9.6.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit

从安装PostgreSQL的虚拟服务器的终端：

lsb_release -a
LSB Version: n/a
Distributor ID: SUSE LINUX
Description: SUSE Linux Enterprise Server 12
Release: 12
Codename: 12

uname -r
3.12.28-4-default

VBScript从Windows 7笔记本电脑运行。

我有什么不对吗？

Aaditi：

我在这里更新了我的odbc驱动程序：https://www.postgresql.org/ftp/odbc/versions/msi/

他们现在已经（没有注意到我在更新之前所拥有的）：

%WINDIR%\SysWOW64\odbcad32.exe驱动程序选项卡具有PostgreSQL ANSI（x64）9.06.05.00和PostgreSQL Unicode（x64）9.06.05.00

%WINDIR%\SysWOW64\odbcad32.exe驱动程序选项卡有PostgreSQL ANSI 9.06.05.00和PostgreSQL Unicode 9.06.05.00

使用新驱动程序重新启动笔记本电脑，并通过这个良好但稍微不准确的链接将外部数据表设置到我的服务器日志文件：https://dba.stackexchange.com/questions/153904/pgadmin-4-server-status-view-log-file

...所以我明天可以提供一些服务器日志。

编辑3：

除了编辑2，我重新启动了服务器。

我今天早上成功创建了错误。与以前完全相同的事情。服务器日志不显示有关vacuum查询的信息：

select * from postgres_log 
where query like '%vacuum%'

然而，就像它一直一样，vacuum和另一个同时出现“错误”的查询仍然出现在pg_stat_activity中：

select pid,query,state,wait_event,* from pg_stat_activity where state <> 'idle'

“错误”我的意思是我在原始问题中得到错误，但查询似乎仍在运行。至少真空确实如此。

最后，如果我检查我的vacuums它完成last_vacuum下的真空。我可以通过此查询中的日期看到这个：

 select relname,last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables order by relname;

所以我认为服务器认为查询没问题。对我来说，它似乎是脚本中的东西。 vacuum现在正在运行，自查询启动以来没有状态更改，但此查询通常完成。

这可能是什么？您还需要哪些其他信息？

此外，我认为这不重要，但在错误发生时，我同时运行来自VBA和VBS的查询。

编辑4：

经过时间调查后：

 select * from postgres_log where session_start_time > '2017-09-29 06:00:00'

我发现5个服务器日志“使用陈旧的统计信息而不是当前的统计信息，因为统计信息收集器没有响应”。

注意：在有问题的错误期间，服务器没有记录任何其他内容。

我快速搜索我发现的错误：https://www.postgresql.org/message-id/1457523467.24545.43.camel%402ndquadrant.com

听起来像我的“I / O系统超载”？

编辑5：

我不确定这是否重要，但此时我们遇到了一些常见的LAN缓慢/消息传递问题。

具体来说，这是一个完全不同的过程，使用与上述原始问题相同的LAN运行。有关详细信息：https://serverfault.com/questions/873296/saving-large-excel-files-to-network-drive-locks-on-saving-progress-bar-popup

这有关系吗？

Answer 1

正如Eelke在评论中提到的那样，问题是缺乏网络可靠性。由于网络中断而中断/中断的连接（在这种情况下通过vbs建立）可能会导致程序中的此类错误（在本例中为vbscript），但不会产生任何直接的服务器端错误：

“服务器意外关闭连接这可能意味着服务器在处理请求之前或处理时异常终止。”

解决方案：使网络更可靠

Answer 2

也许这是设置以下配置参数的解决方案

tcp_keepalives_idle（整数）

指定TCP应向客户端发送keepalive消息之前不活动的秒数。值0使用系统默认值。仅在支持TCP_KEEPIDLE或等效套接字选项的系统上以及Windows上支持此参数;在其他系统上，它必须为零。在通过Unix域套接字连接的会话中，此参数将被忽略，并始终读为零。

tcp_keepalives_interval（整数）

指定应重新传输客户端未确认的TCP keepalive消息的秒数。值0使用系统默认值。仅在支持TCP_KEEPINTVL或等效套接字选项的系统上以及Windows上支持此参数;在其他系统上，它必须为零。在通过Unix域套接字连接的会话中，此参数将被忽略，并始终读为零。

tcp_keepalives_count（整数）

指定在服务器与客户端的连接被视为死亡之前可能丢失的TCP保持活动的数量。值0使用系统默认值。仅在支持TCP_KEEPCNT或等效套接字选项的系统上支持此参数;在其他系统上，它必须为零。在通过Unix域套接字连接的会话中，此参数将被忽略，并始终读为零。

Answer 3

解决这个问题的解决方案对我来说是将ODBC连接中的此设置从默认值1更改为0：

UseServerSidePrepare=0