管理連線
與 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-connection 限制,則新連線會失敗並傳回錯誤。
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';
終止連線
您的 Admin 使用者具有 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 使用者的抄寫連線,因為它會干擾部署的高可用性。
端部連接
如果您的部署達到連線限制,或者您在連接至部署時遇到問題,並且懷疑有大量連線是問題,請中斷與部署的所有連線。
在使用者介面的 設定 標籤上,您的部署有一個 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具有用於處理應用程式中的連接池的類別。 Java PostgreSQL JDBC驅動程式具有 在應用程式和應用程式伺服器層級進行連接池的方法。
或者,您可以使用協力廠商工具 (例如 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 keepalive 設定
如果發生網路連線或失效接手,則在達到 TCP 保持作用中逾時之前,中斷的 TCP/IP 連線可能會保持半開啟/關閉狀態。 若要避免此實務範例,也請在特定應用程式驅動程式中設定 socket_timeout 及 connection_timeout 設定。 正確的設定 會根據特定工作量而有所不同,而且在進入正式作業之前執行負載測試非常重要。 connection_timeout 的良好起點是
2-5 秒。 對於 socket_timeout,良好的起點是 30-60 秒。
此外,在伺服器端,會使用下列 保留作用中配置 作為預設值。
tcp_keepalives_idle設為 5 分鐘tcp_keepalives_interval探測間隔設為 10 秒tcp_keepalives_count設為 6
若要防止連線嘗試中的半開啟/關閉連線或激增導致部署過於龐大,請將 Postgres 的 max_connections 參數 設為至少兩倍的預期連線計數。
如果達到連線限制,您可以立即 結束所有連線。