sys.dm_xtp_gc_queue_stats (Transact-SQL)
適用於:SQL ServerAzure SQL DatabaseAzure SQL 受控執行個體
輸出伺服器上每個垃圾收集背景工作佇列的相關資訊,以及每個佇列的各種統計資料。 每個邏輯 CPU 有一個佇列。
主要垃圾收集執行緒 (Idle thread) 會追蹤自上次叫用主要垃圾收集執行緒之後完成之所有交易的更新、刪除和插入資料列。 當垃圾收集執行緒喚醒時,它會判斷最舊作用中交易的時間戳記是否已變更。 如果最舊的使用中交易已變更,則不再需要寫入集的交易,閒置執行緒會將工作專案排入佇列(以 16 個數據列的區塊為單位)。 例如,如果您刪除 1,024 個數據列,您最終會看到 64 個已排入佇列的垃圾收集工作專案,每個專案都包含 16 個已刪除的資料列。 在使用者交易認可之後,它會在其排程器上選取所有排入佇列的專案。 如果排程器上沒有排入佇列的專案,則使用者交易會在目前 NUMA 節點的任何佇列上搜尋。
您可以執行sys.dm_xtp_gc_queue_stats來判斷垃圾收集是否會釋放已刪除資料列的記憶體,以查看是否正在處理排入佇列的工作。 如果未處理current_queue_depth中的專案,或未將任何新的工作專案新增至current_queue_depth,表示垃圾收集不會釋放記憶體。 例如,如果有長時間執行的交易,就無法進行垃圾收集。
如需詳細資訊,請參閱 In-Memory OLTP (記憶體中最佳化)。
資料行名稱 | 類型 | 描述 |
---|---|---|
queue_id | int | 佇列的唯一識別碼。 |
total_enqueues | bigint | 自伺服器啟動後排入佇列的垃圾收集工作專案總數。 |
total_dequeues | bigint | 自伺服器啟動後,從這個佇列清除佇列的垃圾收集工作專案總數。 |
current_queue_depth | bigint | 此佇列上目前存在的垃圾收集工作專案數目。 此專案可能暗示要進行一或多個垃圾收集。 |
maximum_queue_depth | bigint | 此佇列所見的最大深度。 |
last_service_ticks | bigint | 佇列上次服務時 CPU 刻度。 |
權限
需要 VIEW SERVER STATE 權限。
SQL Server 2022 和更新版本的權限
需要伺服器上的 VIEW SERVER PERFORMANCE STATE 權限。
使用者案例
此輸出顯示 SQL Server 是在 4 個核心上執行,或 SQL Server 實例已親和化為 4 個核心:
此輸出顯示佇列中沒有要處理的工作專案。 針對佇列 0,自 SQL 啟動為 15625 之後,已取消排入佇列的工作專案總數,且佇列深度上限為 15625。
queue_id total_enqueues total_dequeues current_queue_depth maximum_queue_depth last_service_ticks
----------------------------------------------------------------------------------------------------
0 15625 15625 0 15625 1233573168347
1 15625 15625 0 15625 1234123295566
2 15625 15625 0 15625 1233569418146
3 15625 15625 0 15625 1233571605761
另請參閱
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應