为什么PostgreSQL说“致命”：对不起，当我无法达到最大连接时，已经有太多的客户端了？

Question

我正在处理PostgreSQL 11.2的安装，它会定期在系统日志中进行抱怨。

FATAL:  sorry, too many clients already

尽管是无-哪里接近其配置的连接限制。此查询：

SELECT current_setting('max_connections') AS max,
       COUNT(*) AS total
FROM pg_stat_activity

告诉我，数据库配置为最多100个连接。我从未见过使用此查询连接到数据库的大约45个连接，甚至在运行中的程序收到数据库错误之前，在Postgres日志中显示了太多由上述消息支持的客户端。

当然，我在互联网上发现的所有问题--这意味着错误意味着您已经超过了max_connections设置，但是数据库本身告诉我，我没有。

就其价值而言，pyspark是唯一触发此错误的数据库客户端，并且只有当它从dataframes写入表时才会触发此错误。使用psycopg2 (即主要客户端)的常规python代码从不触发它(即使是在以相同的方式从Pandas写入表时)，pgAdmin之类的管理工具也从不触发它。如果我没有直接看到数据库日志中的错误，我会认为Spark在错误方面对我撒谎。大多数情况下，如果我使用这样的查询：

SELECT pg_terminate_backend(pid) FROM pg_stat_activity 
WHERE pid <> pg_backend_pid() AND application_name LIKE 'pgAdmin%';

然后这个问题就消失了好几天。但是就像我说的，根据数据库本身，我从来没有见过在使用的100个连接中，有50%的连接在使用中。如何找出导致此错误的原因？

Answer 1

这是由Spark使用JDBC读写数据的方式造成的。Spark试图打开几个到数据库的并发连接，以便并行地读取/写入多个数据分区。

我在文档中找不到它，但我认为默认情况下，连接的数量等于要写入db表的datafame中的分区数。这解释了你注意到的间歇性。

但是，可以通过设置numPartitions选项来控制该数字：

表读取和写入中可用于并行处理的最大分区数。这也决定了并发JDBC连接的最大数量。如果要写入的分区数超过此限制，则在写入之前调用coalesce(numPartitions)将其减少到此限制。

示例：

spark.read.format("jdbc") \
          .option("numPartitions", "20") \
# ...

Answer 2

有三种可能性：

1. 这些联系非常短暂，当你看的时候它们已经消失了。--

1. 数据库的连接限制较低。

1. 数据库用户的连接限制较低.

但是选项2和3会产生不同的错误消息，所以它必须是短暂的连接。

不管是什么，解决问题的方法都是配置良好的连接池。