本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# LWLock:lock\$1manager
此事件表示因為無法執行快速路徑鎖定，Aurora PostgreSQL 引擎維護共用鎖定的記憶體區域來配置、檢查和解除配置鎖定。
**Topics**
+ [支援的引擎版本](#apg-waits.lw-lock-manager.context.supported)
+ [Context](#apg-waits.lw-lock-manager.context)
+ [等待變多的可能原因](#apg-waits.lw-lock-manager.causes)
+ [動作](#apg-waits.lw-lock-manager.actions)
## 支援的引擎版本
此等待事件資訊與 Aurora PostgreSQL 9.6 版及更新版本有關。
## Context
當您發出 SQL 陳述式時，Aurora PostgreSQL 會記錄鎖定，在並行操作期間保護資料庫的結構、資料和完整性。引擎可以使用快速路徑鎖定或不快速的路徑鎖定來達成此目標。不快速的路徑鎖定比快速路徑鎖定花更多成本，還會產生更多額外負荷。
### 快速路徑鎖定
如果鎖定經常取得和釋放但很少衝突，為了減少額外負荷，後端程序可以使用快速路徑鎖定。資料庫使用此機制來處理符合下列條件的鎖定：
+ 使用 DEFAULT 鎖定方法。
+ 代表鎖定資料庫關聯，而不是共用關聯。
+ 弱鎖定，不太可能衝突。
+ 引擎可以快速確認不可能有衝突鎖定。
有下列任一情況時，引擎無法使用快速路徑鎖定：
+ 鎖定不符合上述條件。
+ 已無插槽可供後端程序使用。
如需快速路徑鎖定的詳細資訊，請參閱 PostgreSQL 鎖定管理員 README 中的[快速路徑](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76)和 PostgreSQL 文件中的 [pg-locks](https://www.postgresql.org/docs/15/view-pg-locks.html)。
### 鎖定管理員的擴展問題範例
在此範例中，名為 `purchases` 的資料表存放五年的資料，並按日分割。每個分割區都有兩個索引。發生下列事件序列：
1. 您查詢很多天的資料，使得資料庫需要讀取許多分割區。
1. 資料庫為每個分割區建立鎖定項目。如果分割區索引出現在最佳化工具存取路徑中，則資料庫也為這種索引建立鎖定項目。
1. 對同一個後端程序所請求的鎖定項目數大於 16 時，即 `FP_LOCK_SLOTS_PER_BACKEND` 的值，鎖定管理員會使用不快速的路徑鎖定方法。
現代化應用程式可能有數百個工作階段。如果並行工作階段查詢父項，但沒有適當的分割區剔除，則資料庫可能會建立數百甚至數千個不快速的路徑鎖定。當此並行高於 vCPU 數目時，通常會出現 `LWLock:lock_manager` 等待事件。
**注意**
`LWLock:lock_manager` 等待事件與資料庫結構描述中的分割區或索引數目無關。但與資料庫必須控制的不快速路徑鎖定數目有關。
## 等待變多的可能原因
`LWLock:lock_manager` 等待事件比平常更常發生時，可能表示有效能問題，突然激增最可能的原因如下：
+ 並行作用中工作階段正在執行的查詢未使用快速路徑鎖定。這些工作階段也超過 vCPU 上限。
+ 大量並行作用中工作階段正在存取高度分割的資料表。每個分割區有多個索引。
+ 資料庫遇到連線風暴。根據預設，當資料庫變慢時，某些應用程式和連線集區軟體會建立更多連線。這種做法使問題變得更糟。請調校連線集區軟體，以免發生連線風暴。
+ 大量工作階段查詢父資料表但未剔除分割區。
+ 資料定義語言 (DDL)、資料處理語言 (DML) 或維護命令獨佔鎖定忙碌關聯，或是經常存取或修改的元組。
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [使用分割區剔除](#apg-waits.lw-lock-manager.actions.pruning)
+ [移除不必要的索引](#apg-waits.lw-lock-manager.actions.indexes)
+ [調校查詢以使用快速路徑鎖定](#apg-waits.lw-lock-manager.actions.tuning)
+ [調校其他等待事件](#apg-waits.lw-lock-manager.actions.other-waits)
+ [降低硬體瓶頸](#apg-waits.lw-lock-manager.actions.hw-bottlenecks)
+ [使用連線集區](#apg-waits.lw-lock-manager.actions.pooler)
+ [升級 Aurora PostgreSQL 版本](#apg-waits.lw-lock-manager.actions.pg-version)
### 使用分割區剔除
*剔除分割區*是一種查詢最佳化策略，可將不需要的分割區排除在資料表掃描外，進而改善效能。分割區剔除預設為啟用。如果已停用，請如下啟用。
```
SET enable_partition_pruning = on;
```
當 `WHERE` 子句包含用於分割的資料欄時，查詢可以利用分割區剔除。如需詳細資訊，請參閱 PostgreSQL 文件中的[分割區剔除](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING)。
### 移除不必要的索引
資料庫可能包含未使用或很少使用的索引。若是如此，請考慮刪除這些索引。執行下列任何一項：
+ 請參閱 PostgreSQL Wiki 中的[未使用的索引](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes)，以了解如何尋找不必要的索引。
+ 執行 PG Collector。此 SQL 指令碼會收集資料庫資訊，並顯示在合併的 HTML 報告中。請檢查「Unused indexes (未使用的索引)」區段。如需詳細資訊，請參閱 AWS Labs GitHub 儲存庫中的 [pg-collector](https://github.com/awslabs/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 執行個體類型](https://aws.amazon.com/rds/instance-types/)。
### 使用連線集區
如果作用中連線總數超過 vCPU 上限，表示需要 CPU 的作業系統程序超過執行個體類型可支援的數量。在此情況下，請考慮使用或調校連線集區。關於執行個體類型的 vCPU，如需詳細資訊，請參閱 [Amazon RDS 執行個體類型](https://aws.amazon.com/rds/instance-types/)。
如需連線集區的詳細資訊，請參閱下列資源：
+ [Amazon RDS Proxy for Aurora](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ 《PostgreSQL 文件》**中的[連線集區和資料來源](https://www.postgresql.org/docs/7.4/jdbc-datasource.html)
### 升級 Aurora PostgreSQL 版本
如果您目前的 Aurora PostgreSQL 版本低於 12，請升級至第 12 版或更新版本。PostgreSQL 版本 12 和 13 已改善分割機制。如需第 12 版的詳細資訊，請參閱 [PostgreSQL 12.0 版本備註]( https://www.postgresql.org/docs/release/12.0/)。如需升級 Aurora PostgreSQL 的詳細資訊，請參閱 [Amazon Aurora PostgreSQL 的資料庫引擎更新](AuroraPostgreSQL.Updates.md)。