服务器意外地通过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，所以我认为查询正在写入磁盘。我们正在讨论升级我们的服务器，但我想了解并能够进行诊断。)是否有一种确定根目录的方法？

我认为解决方案是对查询进行不同的计时，这样它们就不会同时运行。问题是，由于我们缺乏资源，一切都在缓慢进行，而且每天的日程安排都已经排满了，我需要偷偷地加入一些vacuum。是否有更好的方法从脚本的角度(或DBA的立场)，而不深入实际查询的细节？

为什么postgres不只是放慢或锁定查询而不是终止它们呢？还是别的什么事不行了？

如果这个问题更合适的话，我会把这个问题移到所以DBA站点，但是我想我应该先从脚本的角度来问这个问题。

EDIT1:我正在运行的内容：

来自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是从Windows7笔记本电脑上运行的。

我有什么问题吗？

EDIT2:

我在这里更新了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

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

编辑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'

我所说的“错误”是指我在最初的问题中得到了错误，但是这些查询似乎仍然在运行。至少真空是可以肯定的。

最后，如果我检查我的vacuum，它就完成了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个服务器日志“使用陈旧的统计信息而不是当前的统计信息，因为stats收集器没有响应”。

注意:在发生错误期间，服务器没有记录任何其他内容。

我快速搜索了这个错误--我发现了以下内容：https://www.postgresql.org/message-id/1457523467.24545.43.camel%402ndquadrant.com

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

编辑5:

我不确定这是否重要，但大约在这个时候，我们遇到了一些一般的局域网慢/消息传递问题。

具体来说，这是一个完全不同的过程，它使用相同的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应在此之后向客户端发送保持活动消息的不活动秒数。值0使用系统默认值。此参数仅在支持TCP_KEEPIDLE或等效套接字选项的系统和Windows上支持；在其他系统中，必须为零。在通过Unix域套接字连接的会话中，此参数将被忽略，并且始终以零的形式读取.

tcp_keepalives_interval (整数)

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

tcp_keepalives_count (整数)

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

Answer 3

​

​

解决这一问题的解决方案是将ODBC连接中的此设置从默认的1更改为0：

UseServerSidePrepare=0