PostgreSQL+Node v12.22.9+systemd服务出现ECONNREFUSED连接问题求助

1. 关于将localhost替换为127.0.0.1的有效性 #

这个改动可能解决单次连接失败的问题，但未必能根治“几小时后复发”的核心故障，原因如下：

• localhost在系统中可能解析为IPv6地址::1，如果PostgreSQL的listen_addresses配置未包含IPv6地址，就会导致连接失败；换成127.0.0.1会强制使用IPv4连接，避开解析差异。
• 但你的问题是PostgreSQL服务会自行停止或无法处理连接（重启后临时恢复），而非单纯的地址解析问题。所以这个改动可以作为排查步骤之一，但不要指望它解决复发问题。

2. 升级Node版本能否解决问题？ #

大概率不能。除非你当前使用的Node版本存在与pg-promise模块兼容的已知连接泄漏bug，但这种情况极少。优先检查pg-promise模块的版本，升级到最新稳定版（执行npm update pg-promise）更有针对性。

3. 核心故障排查与解决步骤 #

你的问题核心是PostgreSQL服务频繁无法响应连接，重启后短期恢复，结合“问题出现前在客户端Mac设备安装Webroot”的线索，建议按以下步骤排查：

步骤1：检查PostgreSQL崩溃日志 #

查看PostgreSQL的日志文件（通常路径为/var/log/postgresql/postgresql-<版本>-main.log），重点找服务停止或拒绝连接前的错误信息：

• 是否有out of memory（内存耗尽）记录？
• 是否有文件权限错误（比如Webroot误修改了数据库文件权限）？
• 是否有进程被强制终止的日志？

步骤2：检查系统级进程终止记录 #

查看系统日志（/var/log/syslog或/var/log/messages），搜索postgresql相关条目：

• 确认是否是系统的OOM Killer（内存不足时自动杀进程）终止了PostgreSQL进程。如果是，需要优化数据库内存配置（比如降低shared_buffers）或升级服务器内存。
• 检查是否有客户端异常连接导致数据库连接池耗尽的迹象。

步骤3：验证数据库连接数是否耗尽 #

登录PostgreSQL执行以下命令：

-- 查看最大连接数配置
SHOW max_connections;
-- 查看当前活跃连接数
SELECT count(*) FROM pg_stat_activity;

如果当前连接数接近或达到最大值，说明客户端（比如装了Webroot的Mac）可能在发起大量异常连接，或者Node应用存在连接泄漏（未正确释放数据库连接）。

步骤4：优化Node应用的连接池配置 #

检查pg-promise的连接池设置，确保连接数合理且能自动回收：

• 可以在初始化时显式配置连接池参数，比如：

  const db = pgp({
    connectionString: "postgres://readonlyuser:whatever2@127.0.0.1:5432/gisdb",
    pool: {
      max: 20, // 根据服务器配置调整，不要超过PostgreSQL的max_connections
      idleTimeoutMillis: 30000 // 闲置连接自动回收时间
    }
  });
  

步骤5：排查Webroot的影响 #

由于问题出现在客户端安装Webroot之后，建议：

• 临时在一台Mac上禁用Webroot，观察数据库连接是否恢复正常，排除客户端扫描导致的异常连接。
• 检查Webroot的防火墙规则，是否限制了对服务器5432端口的连接，或者频繁重置连接导致数据库连接池积压。

步骤6：确认PostgreSQL的自动重启配置 #

虽然你在.service文件中配置了Restart=always，但需要确保服务文件的其他配置正确：

• 检查ExecStart路径是否正确，User和Group是否有足够权限访问数据库文件。
• 执行systemctl status postgresql查看服务状态，确认重启机制是否正常触发（比如服务崩溃后是否自动重启）。

内容的提问来源于stack exchange，提问作者williamh