LWLock:lock_manager (LWLock:lockmanager) - Amazon Relational Database Service
支援的引擎版本Context等待變多的可能原因動作

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

LWLock:lock_manager (LWLock:lockmanager)

此事件表示因為無法執行快速路徑鎖定，RDS for PostgreSQL 引擎維護共用鎖定的記憶體區域來配置、檢查和解除配置鎖定。

支援的引擎版本

此等待事件資訊與 RDS for PostgreSQL 9.6 版及更新版本有關。對於比第 13 版舊的 RDS for PostgreSQL 版本，此等待事件的名稱為 LWLock:lock_manager。對於 RDS for PostgreSQL 第 13 版及更新版本，此等待事件的名稱為 LWLock:lockmanager。

Context

當您發出 SQL 陳述式時，RDS for PostgreSQL 會記錄鎖定，在並行操作期間保護資料庫的結構、資料和完整性。引擎可以使用快速路徑鎖定或不快速的路徑鎖定來達成此目標。不快速的路徑鎖定比快速路徑鎖定花更多成本，還會產生更多額外負荷。

快速路徑鎖定

如果鎖定經常取得和釋放但很少衝突，為了減少額外負荷，後端程序可以使用快速路徑鎖定。資料庫使用此機制來處理符合下列條件的鎖定：

  • 使用 DEFAULT 鎖定方法。

  • 代表鎖定資料庫關聯，而不是共用關聯。

  • 弱鎖定，不太可能衝突。

  • 引擎可以快速確認不可能有衝突鎖定。

有下列任一情況時，引擎無法使用快速路徑鎖定：

  • 鎖定不符合上述條件。

  • 已無插槽可供後端程序使用。

若要調整您的查詢以進行快速路徑鎖定，您可以使用下列查詢。

SELECT count(*), pid, mode, fastpath
  FROM pg_locks
 WHERE fastpath IS NOT NULL
 GROUP BY 4,3,2
 ORDER BY pid, mode;
 count | pid  |      mode       | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock   | t

下列查詢只顯示整個資料庫的總計。

SELECT count(*), mode, fastpath
  FROM pg_locks
 WHERE fastpath IS NOT NULL
 GROUP BY 3,2
 ORDER BY mode,1;
count |      mode       | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock   | t
(3 rows)

如需快速路徑鎖定的詳細資訊，請參閱 PostgreSQL 鎖定管理員 README 中的快速路徑和 PostgreSQL 文件中的 pg-locks。

鎖定管理員的擴展問題範例

在此範例中，名為 purchases 的資料表存放五年的資料，並按日分割。每個分割區都有兩個索引。發生下列事件序列：

  1. 您查詢很多天的資料，使得資料庫需要讀取許多分割區。

  2. 資料庫為每個分割區建立鎖定項目。如果分割區索引出現在最佳化工具存取路徑中，則資料庫也為這種索引建立鎖定項目。

  3. 對同一個後端程序所請求的鎖定項目數大於 16 時，即 FP_LOCK_SLOTS_PER_BACKEND 的值，鎖定管理員會使用不快速的路徑鎖定方法。

現代化應用程式可能有數百個工作階段。如果並行工作階段查詢父項，但沒有適當的分割區剔除，則資料庫可能會建立數百甚至數千個不快速的路徑鎖定。當此並行高於 vCPU 數目時，通常會出現 LWLock:lock_manager 等待事件。

注意

LWLock:lock_manager 等待事件與資料庫結構描述中的分割區或索引數目無關。但與資料庫必須控制的不快速路徑鎖定數目有關。

等待變多的可能原因

LWLock:lock_manager 等待事件比平常更常發生時，可能表示有效能問題，突然激增最可能的原因如下：

  • 並行作用中工作階段正在執行的查詢未使用快速路徑鎖定。這些工作階段也超過 vCPU 上限。

  • 大量並行作用中工作階段正在存取高度分割的資料表。每個分割區有多個索引。

  • 資料庫遇到連線風暴。根據預設，當資料庫變慢時，某些應用程式和連線集區軟體會建立更多連線。這種做法使問題變得更糟。請調校連線集區軟體，以免發生連線風暴。

  • 大量工作階段查詢父資料表但未剔除分割區。

  • 資料定義語言 (DDL)、資料處理語言 (DML) 或維護命令獨佔鎖定忙碌關聯，或是經常存取或修改的元組。

動作

發生 CPU 等待事件不見得表示有效能問題。只有在效能下降且此等待事件主宰資料庫負載時，才需要因應此事件。

使用分割區剔除

剔除分割區是一種宣告式分割資料表的查詢最佳化策略，可將不需要的分割區排除在資料表掃描外，進而改善效能。分割區剔除預設為啟用。如果已停用，請如下啟用。

SET enable_partition_pruning = on;

當 WHERE 子句包含用於分割的資料欄時，查詢可以利用分割區剔除。如需詳細資訊，請參閱 PostgreSQL 文件中的分割區剔除。

移除不必要的索引

資料庫可能包含未使用或很少使用的索引。若是如此，請考慮刪除這些索引。執行下列任何一項：

  • 請參閱 PostgreSQL Wiki 中的未使用的索引，以了解如何尋找不必要的索引。

  • 執行 PG Collector。此 SQL 指令碼會收集資料庫資訊，並顯示在合併的 HTML 報告中。請檢查「Unused indexes (未使用的索引)」區段。如需詳細資訊，請參閱 AWS Labs GitHub 儲存庫中的 pg-collector。

調校查詢以使用快速路徑鎖定

若要查明查詢是否使用快速路徑鎖定，請查詢 pg_locks 資料表的 fastpath 資料欄。如果查詢未使用快速路徑鎖定，請嘗試將每個查詢的關聯數量減少到 16 以下。

調校其他等待事件

如果 LWLock:lock_manager 在最常等待名單中排行前兩名，請檢查下列等待事件是否也出現在名單中：

  • Lock:Relation

  • Lock:transactionid

  • Lock:tuple

如果上述事件在名單中排行前幾名，請考慮先調校這些等待事件。這些事件可能引發 LWLock:lock_manager。

降低硬體瓶頸

您可能遇到硬體瓶頸，例如 CPU 不足或 Amazon EBS 頻寬耗盡。在這些情況下，請考慮降低硬體瓶頸。考慮下列動作：

  • 擴充執行個體類別的規模。

  • 將耗用大量 CPU 和記憶體的查詢最佳化。

  • 變更應用程式邏輯。

  • 封存資料。

如需 CPU、記憶體和 EBS 網路頻寬的詳細資訊，請參閱 Amazon RDS 執行個體類型。

使用連線集區

如果作用中連線總數超過 vCPU 上限，表示需要 CPU 的作業系統程序超過執行個體類型可支援的數量。在此情況下，請考慮使用或調校連線集區。關於執行個體類型的 vCPU，如需詳細資訊，請參閱 Amazon RDS 執行個體類型。

如需連線集區的詳細資訊，請參閱下列資源：

升級 RDS for PostgreSQL 版本

如果您目前的 RDS for PostgreSQL 版本低於 12，請升級至第 12 版或更新版本。PostgreSQL 第 12 版和更新版本已改善分割機制。如需第 12 版的詳細資訊，請參閱 PostgreSQL 12.0 版本備註。如需升級 RDS for PostgreSQL 的詳細資訊，請參閱RDS 適用於 PostgreSQL 資料庫引擎的 升級。