本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
LWLock:buffer_content (BufferContent)
LWLock:buffer_content
事件表示工作階段正等待在記憶體中讀取或寫入資料分頁,但另一個工作階段已鎖定該分頁來寫入。在 Aurora PostgreSQL 13 及更新版本中,此等待事件稱為 BufferContent
。
支援的引擎版本
所有版本的 Aurora PostgreSQL 都支援此等待事件資訊。
Context
為了讀取或操作資料,PostgreSQL 透過共用記憶體緩衝區來存取資料。為了讀取緩衝區,程序以共用模式在緩衝區內容上取得輕量級鎖定 (LWLock)。為了寫入緩衝區,程序以獨佔模式取得該鎖定。共用鎖定允許其他程序同時在該內容上取得共用鎖定。獨佔鎖定阻止其他程序在該內容上得得任何類型的鎖定。
LWLock:buffer_content
(BufferContent
) 事件表示多個程序正在嘗試在特定緩衝區的內容上取得輕量鎖定 LWLocks)。
等待時間增加的可能原因
LWLock:buffer_content
(BufferContent
) 事件比平時更常出現時,可能表示有效能問題,典型原因包括:
- 更常並行更新相同資料
-
以查詢來更新相同緩衝區內容的並行工作階段可能變多。在有大量索引的資料表上,這種爭用可能更明顯。
- 工作負載資料不在記憶體中
-
當作用中工作負載處理的資料不在記憶體中時,這些等待事件可能增加。這是因為程序在執行磁碟輸入/輸出操作時持有鎖定更久。
- 過度使用外部索引鍵限制
-
外部索引鍵限制會延長程序持有緩衝區內容鎖定的時間。這是因為讀取操作在更新參考的索引鍵時,在該索引鍵上需要共用緩衝區內容鎖定。
動作
根據等待事件的原因,我們會建議不同的動作。您可以使用 Amazon RDS 績效詳情或查詢 LWLock:buffer_content
檢視表來識別 BufferContent
(pg_stat_activity
) 事件。
改善記憶體內效率
若要讓作用中工作負載資料更有機會留在記憶體中,請分割資料表或擴充執行個體類別的規模。如需資料庫執行個體類別的相關資訊,請參閱 Amazon Aurora 資料庫執行個體類別。
監控 BufferCacheHitRatio
指標,以測量資料庫叢集中資料庫執行個體的緩衝區快取所提供的請求百分比。此指標可讓您深入了解從記憶體提供的資料量。高命中率表示您的資料庫執行個體有足夠的記憶體可供您的工作資料集使用,而低比率則表示您的查詢經常從儲存體存取資料。
PG 收集器
減少使用外部索引鍵限制
調查遇到大量 LWLock:buffer_content
(BufferContent
)等待事件的工作負載如何使用外部引索鍵限制。刪除不必要的外部索引鍵限制。
移除未使用的索引
對於遇到大量 LWLock:buffer_content
(BufferContent
) 等待事件的工作負載,請識別未使用的索引並移除。
PG 收集器
移除重複的索引
識別重複的索引並將其移除。
PG 收集器
捨棄或 REINDEX 無效索引
使用 CREATE INDEX CONCURRENTLY
或 時通常會發生無效的索引,REINDEX CONCURRENTLY
且命令失敗或中止。
無效的索引無法用於查詢,但仍會更新並佔用磁碟空間。
PG 收集器
使用部分索引
您可以利用部分索引來增強查詢效能並減少索引大小。部分索引是建置在資料表子集上的索引,子集由條件式表達式定義。如部分索引
移除資料表和索引膨脹
資料表和索引膨脹過多可能會對資料庫效能造成負面影響。膨脹的資料表和索引會增加作用中的工作集大小,降低記憶體內效率。此外,膨脹會增加儲存成本並減慢查詢執行速度。若要診斷膨脹,請參閱 診斷資料表和索引膨脹。此外,PG 收集器
若要處理資料表和索引膨脹,有幾個選項:
- VACUUM FULL
-
VACUUM FULL
會建立新的資料表複本,僅複製即時元組,然後以新的資料表取代舊資料表,同時保留ACCESS EXCLUSIVE
鎖定。這可防止讀取或寫入資料表,這可能會導致中斷。此外,如果資料表很大,VACUUM FULL
將需要更長的時間。 - pg_repack
-
在
VACUUM FULL
可能不適合的情況下pg_repack
, 很有用。它會建立新的資料表,其中包含膨脹資料表的資料、追蹤原始資料表的變更,然後將原始資料表取代為新的資料表。在建立新資料表時,它不會鎖定原始資料表以進行讀取或寫入操作。如需如何使用 的詳細資訊pg_repack
,請參閱使用 pg_repack 和 pg_repack 移除膨脹。 https://reorg.github.io/pg_repack/ - REINDEX
-
此
REINDEX
命令可用來解決索引膨脹問題。 會REINDEX
撰寫索引的新版本,而不會有無效頁面或空白或幾乎空白的頁面,進而減少索引的空間耗用。如需REINDEX
命令的詳細資訊,請參閱 REINDEX 文件。
從資料表和索引移除膨脹後,可能需要增加這些資料表的自動清空頻率。在資料表層級實作積極的自動清空設定,有助於防止未來發生膨脹。如需詳細資訊,請參閱 上的文件Vacuuming and analyzing tables automatically
。