程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> 更多數據庫知識 >> 簡單介紹SQL Server中的自旋鎖,sql自旋

簡單介紹SQL Server中的自旋鎖,sql自旋

編輯:更多數據庫知識

簡單介紹SQL Server中的自旋鎖,sql自旋


為什麼我們需要自旋鎖?
用闩鎖同步多個線程間數據結構訪問,在每個共享數據結構前都放置一個闩鎖沒有意義的。闩鎖與此緊密關聯:當你不能獲得闩鎖(因為其他人已經有一個不兼容的闩鎖拿到),查詢就會強制等待,並進入掛起(SUSPENDED)狀態。查詢在掛起狀態等待直到可以拿到闩鎖,然後就會進入可執行(RUNNABLE)狀態。對於查詢執行只要沒有可用的CPU,查詢就一直在可執行(RUNNABLE)狀態。一旦CPU有空閒,查詢會進入運行(RUNNING)狀態,最後成功獲取到闩鎖,用它來保護訪問的共享數據結構。下圖展示了SQLOS對協調線程調度實現的狀態機。

因為太多關聯的闩鎖,對“忙碌”數據結構使用闩鎖保護沒有意義。因此SQL Server實現所謂自旋鎖(Spinlocks)。自旋鎖就像一個闩鎖,存儲引擎使用的一個輕量級同步對象,用來同步對共享數據結構線程訪問。和闩鎖的主要區別是你積極等待自旋鎖——不離開CPU。在自旋鎖上的“等待”總會發生在運行(RUNNING)狀態的CPU。在你閉合循環裡旋轉直到獲得自旋鎖。這就是所謂的忙碌等待(busy wait)。自旋鎖的最大優點是當查詢在自旋鎖上等待時,不會涉及到上下文切換。另一方面忙碌等待浪費CPU周期,其他查詢也許能對它們更有效的使用。

為了避免太多的CPU周期浪費,SQL Server 2008 R2及後續版本實現所謂的指數補償機制(exponential backoff mechanism),那裡在CPU上一些時間的休眠後,線程停止旋轉。在線程進入休眠期間,增加了嘗試獲得自旋鎖的超時。這個行為可以降低對CPU性能的影響。

(補充說明:Spinlock中文可以稱為自旋鎖。它是一個輕量級的,用戶態的同步對象,和critical section類似,但是粒度比前者小多了。它主要用來保護某些特定的內存對象的多線程並發訪問。Spinlock是排他性的。一次只能一個線程擁有。

Spinlock的設計目標是非常快和高效率。Spinlock內部如何工作呢?它首先試圖獲得某個對象的鎖,如果目標被其它線程占有,就在那裡輪詢(spin)一定時間。如果還得不到鎖,就sleep一小會,然後繼續spin。反復這個過程直到得到對象的占有權。)

自旋鎖與故障排除
對自旋鎖故障排除的主要DMV是 sys.dm_os_spinlock_stats。這個DMV裡返回的每一行都代表SQL Server裡的一個自旋鎖。SQL Server 2014實現了262個不同自旋鎖。我們來詳細看下這個DMV裡的各個列:

name:自旋鎖名稱
collision:當嘗試訪問保護的數據結構時,被自旋鎖阻塞的線程次數
spins:在循環裡嘗試獲得自旋鎖的自旋鎖線程次數
spins_per_collision:旋轉和碰撞之間的比率
sleep_time:因為退避線程休眠時間
backoffs:為了其他線程在CPU上繼續,線程退避次數
在這個DMV裡最重要的列是backoffs,對於特定的自旋鎖類型,這列告訴你退避發生頻率。高頻率的退避會屈服於CPU消耗引起SQL Server裡的自旋鎖競爭(Spinlock Contention)。我就見過一個32核的SQL Server服務器,CPU運行在100%而不進行任何工作——典型的自旋鎖競爭症狀。

對自旋鎖問題進行故障排除你可以使用擴展事件提供的sqlos.spinlock_backoff。當退避(backoff)發生時,就會觸發這個擴展事件。如果你捕獲了這個事件,你還要保證你使用非常好的選擇性謂語,因為在SQL Server裡退避會經常發生。一個好的謂語可以是特定的自旋鎖類型,通過剛才提到的DMV你已經看到。下列代碼給你展示了如何創建這樣的擴展事件會話。


 -- Retrieve the type value for the LOCK_HASH spinlock.
 -- That value is used by the next XEvent session
 SELECT * FROM sys.dm_xe_map_values
 WHERE name = 'spinlock_types'
 AND map_value = 'LOCK_HASH'
 GO
 
 -- Tracks the spinlock_backoff event
 CREATE EVENT SESSION SpinlockContention ON SERVER 
 ADD EVENT sqlos.spinlock_backoff
(
 ACTION
 (
  package0.callstack
 )
  WHERE
 (
  [type] = 129 -- <<< Value from the previous query
 )
) 
ADD TARGET package0.histogram
 (
  SET source = 'package0.callstack', source_type = 1
 )
 GO

從代碼裡可以看到,這裡我在調用堆棧(callstack)上使用了直方圖(histogram)目標來bucktize。因此對於特定的自旋鎖,你可以可能到SQL Serve裡生成的最高退避(backoffs)代碼路徑。你甚至可以通過啟用3656跟蹤標記(trace flag)來標識調用堆棧。這裡你可以看到來自這個擴展會話的輸出:

sqldk.dll!XeSosPkg::spinlock_backoff::Publish+0x138
sqldk.dll!SpinlockBase::Sleep+0xc5
sqlmin.dll!Spinlock<129,7,1>::SpinToAcquireWithExponentialBackoff+0x169
sqlmin.dll!lck_lockInternal+0x841
sqlmin.dll!XactWorkspaceImp::GetSharedDBLockFromLockManager+0x18d
sqlmin.dll!XactWorkspaceImp::GetDBLockLocal+0x15b
sqlmin.dll!XactWorkspaceImp::GetDBLock+0x5a
sqlmin.dll!lockdb+0x4a sqlmin.dll!DBMgr::OpenDB+0x1ec
sqlmin.dll!sqlusedb+0xeb
sqllang.dll!usedb+0xb3
sqllang.dll!LoginUseDbHelper::UseByMDDatabaseId+0x93
sqllang.dll!LoginUseDbHelper::FDetermineSessionDb+0x3e1
sqllang.dll!FRedoLoginImpl+0xa1b
sqllang.dll!FRedoLogin+0x1c1
sqllang.dll!process_request+0x3ec
sqllang.dll!process_commands+0x4a3
sqldk.dll!SOS_Task::Param::Execute+0x21e
sqldk.dll!SOS_Scheduler::RunTask+0xa8
sqldk.dll!SOS_Scheduler::ProcessTasks+0x279
sqldk.dll!SchedulerManager::WorkerEntryPoint+0x24c
sqldk.dll!SystemThread::RunWorker+0x8f
sqldk.dll!SystemThreadDispatcher::ProcessWorker+0x3ab
sqldk.dll!SchedulerManager::ThreadEntryPoint+0x226

使用提供調用堆棧,不難找出自旋鎖競爭發生的地方。在那個指定的笤俑堆棧裡競爭發生在LOCK_HASH自旋鎖類型裡,它是保護鎖管理器的哈希表。每次在鎖管理器裡加鎖或解鎖被執行時,自旋鎖必須在對應的哈希桶裡獲得。如你所見,在調用堆棧裡,當從XactWorkspacelmp類調用GetSharedDBLockFromLockManager函數時,自旋鎖被獲得。這表示當競爭到數據庫時,共享數據庫鎖被嘗試獲取。最後在用很高的退避(backoffs)的LOCK_HASH自旋鎖裡,這屈服於自旋鎖競爭。

以上就是本文的全部內容,希望對大家的學習有所幫助。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved