1

我正在安装 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 日志中上述消息支持的客户端过多。

绝对我可以在 Internet 上找到的所有问题都表明该错误意味着您已超出max_connections设置，但数据库本身告诉我我没有。

值得一提的是，pyspark 是唯一触发此错误的数据库客户端，并且仅当它从数据帧写入表时。使用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% 正在使用中。如何找出导致此错误的原因？

4

2 回答 2

1

三种可能：

  1. 这些联系非常短暂，在您查看时它们已经消失了。

  2. 您对该数据库的连接限制较低。

  3. 您对数据库用户的连接限制较低。

但是选项 2 和 3 会导致不同的错误消息，因此它必须是短期连接。

不管是什么，您的问题的答案将是一个配置良好的连接池。

于 2021-02-13T16:54:41.187 回答
1

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

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

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

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

例子：

spark.read.format("jdbc") \
          .option("numPartitions", "20") \
# ...
于 2021-02-15T22:24:19.587 回答