我正在安装 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
设置,但数据库本身告诉我没有。
就其值(value)而言,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% 正在使用中。我如何找出导致此错误的原因?
最佳答案
这是由于 Spark 使用 JDBC 读取/写入数据的方式造成的。 Spark 尝试打开多个与数据库的并发连接,以便并行读取/写入多个数据分区。
我在文档中找不到它,但我认为默认情况下连接数等于要写入数据库表的数据组中的分区数。这解释了您注意到的间歇性。
但是,您可以通过设置 numPartitions
来控制此数字。选项:
The maximum number of partitions that can be used for parallelism in table reading and writing. This also determines the maximum number of concurrent JDBC connections. If the number of partitions to write exceeds this limit, we decrease it to this limit by calling
coalesce(numPartitions)
before writing.
示例:
spark.read.format("jdbc") \
.option("numPartitions", "20") \
# ...
关于python - 当我远未达到最大连接数时,为什么 PostgreSQL 会说 FATAL : sorry, 客户端数量过多?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66182302/