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，所以我认为查询正在写入磁盘。我们正在讨论升级我们的服务器，但我想了解并能够诊断。）有没有办法确定根目录？

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

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

PS - 我会把这个问题移到SO 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从Windows 7笔记本电脑运行。

我有什么不对吗？

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

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

编辑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个服务器日志“使用过时的统计信息而非当前的统计信息，因为统计信息收集器没有响应”。

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

我快速搜索我发现的错误： 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），但不会产生任何直接的服务器端错误：

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

解决方案：使网络更可靠

Answer 2

也许设置以下配置参数是一种解决方案

tcp_keepalives_idle（整数）

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

tcp_keepalives_interval（整数）

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

tcp_keepalives_count（整数）

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

Answer 3

为我解决的解决方案是将ODBC连接中的此设置从默认值1更改为0：

UseServerSidePrepare=0