金倉資料庫KingbaseES等待事件之LWLock lock_manager

背景

相信我們不止一次遇到過一個等待事件：LWLock lock_manager。下面我們聊聊這個等待事件的含義，產生原因，以及解決方法。

等待事件含義

當資料庫維護共享鎖的記憶體區域以在無法實現以fastpath lock 模式分配、檢查和解除分配鎖時，會發生此事件。發出SQL語句時，資料庫會記錄有關鎖，以在併發操作期間保護資料庫的記憶體結構、資料和完整性。資料庫可以使用fastpath lock或非fastpath lock方式來實現這一目標。非快速路徑鎖比快速路徑鎖更昂貴，產生更多的開銷。

快速路徑鎖定：為了減少頻繁獲取和釋放鎖，減少發生衝突的鎖的開銷，後端程式可以使用快速路徑鎖定方式。資料庫將此機制用於滿足以下條件的鎖：VXID 鎖 ；“弱”鎖，不應該是（AccessShareLock、RowShareLoc或RowExclusiveLock）;

lock manager 問題示例:
在本例中，一個表儲存多年的資料，按天進行分割槽。每個分割槽有兩個索引。當查詢許多天的資料，這需要資料庫讀取許多分割槽。資料庫為每個分割槽建立一個鎖。如果分割槽索引是最佳化器訪問路徑的一部分，資料庫也會為它們建立一個鎖。

應用程式可能有數百個會話。如果併發會話在沒有分割槽修剪（查詢SQL沒帶分割槽列的條件）的情況下查詢父表，資料庫可能會建立數百甚至數千個非fastpath lock。通常，當此併發性高於CPU的數量時，會出現LWLock:lock_manager等待事件。

注意：LWLock:lock_manager等待事件與資料庫中的分割槽或索引數無關。相反，它與資料庫必須控制的非快速路徑鎖的數量有關。

等待事件LWLock:lock_manager增加的可能原因

當LWLock:lock_manager等待事件發生的頻繁時，表明存在效能問題。導致出現峰值的最可能原因如下：

1. 併發活動會話正在執行但沒有使用快速路徑鎖的查詢。
2. 大量併發活動會話正在訪問很多分割槽的表。每個分割槽都有多個索引。
3. 資料庫遇到連線風暴。預設情況下，某些應用程式或連線池軟體會在資料庫速度較慢時仍然建立更多連線。
4. 大量會話查詢父表而沒使用分割槽修剪。
5. 資料定義語言（DDL）、資料操作語言（DML）命令頻繁訪問或修改的熱表或元組。

等待事件LWLock:lock_manager解決方法：

1. 使用分割槽修剪
   SET enable_partition_pruning=on；
   當查詢的WHERE子句包含用於分割槽的列時，查詢可以利用分割槽修剪。

2. 刪除不必要的索引
   刪除資料庫未使用或很少使用的索引，特別是有大量分割槽的表的索引。

3. 調整查詢以實現快速路徑鎖定
   要查詢是否使用快速路徑鎖定，請查詢sys_locks表中的fastpath列。如果查詢沒有使用快速路徑鎖定，請將每個查詢的表數減少到16個以下。
   fastpath列的含義是，如果鎖透過快速路徑獲得則為真，透過主鎖表獲得則為假.

4. 調整其他等待事件
   如果LWLock:lock_manager在top等待列表中排第一或第二，請檢查等待事件中是否也同時出現以下等待事件：
   Lock:Relation
   Lock:transactionid
   Lock:tuple
   如果前面的事件在等待事件中佔比很高，請首先想辦法降低這些等待事件。這些事件可能導致更多的LWLock:lock_manager。

5. 減少硬體瓶頸
   CPU不足或網路頻寬的最大使用率觸發瓶頸。在這些情況下，考慮以下措施：最佳化消耗大量CPU和記憶體的sql；更改應用程式邏輯；冷熱資料物理分離。

6. 使用連線池
   如果資料庫時常有大量session，請考慮使用或最佳化連線池。避免連線風暴。

7. 升級資料庫版本
   建議升級至KingbaseES最新發布版本