管理连接
与 Databases for PostgreSQL 部署的连接使用资源,因此考虑调整部署性能所需的连接数很重要。 PostgreSQL 使用 max_connections
设置来限制连接数 (以及连接所使用的资源),以防止失控连接行为压倒部署的资源。
您可以使用 管理用户 和 psql
来检查 max_connections
的值。
ibmclouddb=> SHOW max_connections;
max_connections
-----------------
115
(1 row)
连接限制
在供应时,Databases for PostgreSQL 将 PostgreSQL 数据库的最大连接数设置为 115。将为超级用户保留 15 个连接以保持数据库的状态和完整性,并且 100 个连接可供您和应用程序使用。 如果与数据库的连接数超过 100 个连接限制,那么新连接将失败并返回错误。
FATAL: remaining connection slots are reserved for
non-replication superuser connections
超过部署的连接限制可能会导致应用程序无法访问数据库。
您可以使用管理用户 psql
和 pg_stat_database
来检查与部署的连接数。
SELECT count(distinct(numbackends)) FROM pg_stat_database;
如果您需要确定连接的位置,那么可以按数据库对连接进行细分。
SELECT datname, numbackends FROM pg_stat_database;
要进一步调查与特定数据库的连接,请查询 pg_stat_activity
。
SELECT * FROM pg_stat_activity WHERE datname='ibmclouddb';
终止连接
您的管理员用户具有 pg_signal_backend
角色。 如果发现需要重置或关闭的连接,那么管理员用户可以同时使用 pg_cancel_backend
和 pg_terminate_backend
。
从 pg_stat_activity
表中找到进程的 pid
。
-
pg_cancel_backend
将取消连接的当前查询,而不终止该连接,也不停止它可能正在运行的任何其他查询。SELECT pg_cancel_backend(pid);
-
pg_terminate_backend
停止整个进程并关闭连接。SELECT pg_terminate_backend(pid);
管理员用户有权重置或关闭部署上任何用户 (超级用户除外) 的连接。 请注意,不要终止来自 ibm-replication
用户的复制连接,因为这会干扰部署的高可用性。
端接
如果您的部署达到连接限制,或者您在连接到部署时迂到问题,并且怀疑存在大量连接问题,请断开与部署的所有连接。
在 UI 中的 设置 选项卡上,有一个按钮用于 End connections
到您的部署。 请谨慎操作,因为这会中断与部署连接的任何内容。
用于结束与部署的连接的 CLI 命令为:
ibmcloud cdb deployment-kill-connections <DEPLOYMENT_NAME_OR_CRN>
您还可以使用 Cloud Databases API 来执行结束所有连接操作。
连接池 (connection pooling)
防止超过连接限制并确保高效处理来自应用程序的连接的一种方法是通过连接池。 如果您发现自己将 IBM Cloud® Databases for PostgreSQL 连接限制设置为超过 500 个连接,那么应认真考虑使用连接池或重新评估如何更有效地使用和维护连接。 PostgreSQL 社区中的性能基准评测建议使用 500 个或更少的连接来实现最佳数据库性能。
许多 PostgreSQL 驱动程序库都有连接池类和函数。 您需要查阅驱动程序的文档,以实现最适合您用例的连接池。 例如,Python驱动程序Psycopg2中的类可在应用程序中处理连接池。 JavaPostgreSQLJDBC驱动程序在应用程序和应用程序服务器级别都有 连接池的方法。
或者,可以使用第三方工具 (例如 PgBouncer ) 来管理应用程序的连接。
提高连接上限
PostgreSQL 在每个连接的基础上分配一些内存量,通常在每个连接的 5-10 MB 左右。 在增加连接限制之前,请务必考虑可供部署使用的内存总量。 要提高连接限制,首先可能需要 缩放部署 以确保有足够的内存来容纳更多连接。
接下来,更改部署上 max_connections
的值。 要对 PostgreSQL 配置 进行永久更改,您要使用 Cloud Databases cli-plugin 或 API 将更改写入部署的配置文件。
例如,要将 max_connections
提升到 215,最好将部署扩展到每个数据成员至少 2 GB RAM,总共 4 GB RAM 用于部署。 完成缩放操作后,请设置连接限制。
- 在调整
max_connections
之前,请务必使用类似命令来定位您的首选区域:
ibmcloud target -r <REGION>
- 接下来,使用类似如下的命令来增加可供部署组使用的内存量:
ibmcloud cdb deployment-groups-set deployment-example member --memory 4096
- 最后,使用如下命令调整
max_connections
:
ibmcloud cdb deployment-configuration <DEPLOYMENT_NAME_OR_CRN> '{"configuration":{"max_connections":215}}'
要通过 API 进行更改,请使用以下命令:
curl -X PATCH `https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"memory": {
"allocation_mb": 4096
}
}'
curl -X PATCH 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/configuration' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"configuration":{
"max_connections":215
}
}'
连接限制和 TCP/IP 保持设置
在发生网络连接或故障转移时,中断的 TCP/IP 连接可能保持半打开/关闭状态,直到达到 TCP 保持活动超时为止。 要避免此场景,还请在特定应用程序驱动程序中设置 socket_timeout
和 connection_timeout
设置。 正确的设置 因特定工作负载而异,在转至生产环境之前运行负载测试很重要。 connection_timeout
的良好起点是 2-5 秒。
对于 socket_timeout
,良好的起点是 30 到 60 秒。
此外,在服务器端,以下 keepalive 配置 用作缺省值。
tcp_keepalives_idle
设置为 5 分钟tcp_keepalives_interval
探测器时间间隔设置为 10 秒tcp_keepalives_count
设置为 6
要防止半打开/关闭连接或连接尝试中断部署,请将 Postgres 的 max_connections
参数 设置为至少将预期连接计数增加一倍。
如果达到连接限制,那么可以立即 结束所有连接。