SQL Server數(shù)據(jù)庫Processor Affinity概述
以下的文章主要介紹的是SQL Server數(shù)據(jù)庫的知識之Processor Affinity，我們大家都知道SQL Server數(shù)據(jù)庫一般的情況下都是在多處理器的服務器上運行，這一點在現(xiàn)在尤為普遍。原因是多內核的處理器越來越普及。
那么，在多處理器環(huán)境下，Windows操作系統(tǒng)(事實上是從2000開始的)通常都會將進程任務放在一個隊伍里面，然后讓這些處理任務依次去占有處理器進行計算。
這樣做的好處就是每個計算任務都可以獲得近似于平均的處理資源，盡管無法保證一個處理任務每次都能拿到同一個處理器。這就像嘉年華我們重復排隊參加一個刺激的項目(比如說自由落體，事實上我從來不參加這種項目)，每個人上去一輪，并不能保證每次都能做同一張位置。
不過回到SQL Server上面來，SQL Server數(shù)據(jù)庫可不喜歡這樣的處理機制。
大家可能都知道處理器中有個東西叫片內緩存，片內緩存有1級、2級、3級之分。
0vJ o9E4\ I?,g3v _8o14943301我們假設處理器要計算A、B、C三個任務，處理器先運算A任務，A任務還沒有結束的時候它的游戲時間就結束了，因此處理器在接受B的時候會將計算B所需的數(shù)據(jù)加載到1級片內緩存中，而將A任務(我們假設處理器還沒有完成它的計算任務)的數(shù)據(jù)挪到2級片內緩存中，或者3級。
當那個A任務回來的計算的時候，處理器會從2級片內緩存中恢復計算所需的數(shù)據(jù)，當然這要取決于是不是那些數(shù)據(jù)還在2級緩存中，因為有很多因素可以讓它不在那兒，比如說A任務回來的時候發(fā)現(xiàn)接待它的已經(jīng)不是原來那個處理器了，當然A任務就不能指望面前這個處理器有它的計算數(shù)據(jù)了(當然計算A任務回到同一顆處理器，也可能因為其他任務占用了這個處理器的2級片內緩存而導致它原來存入的數(shù)據(jù)被替換掉了)。
如果處理器發(fā)現(xiàn)A任務數(shù)據(jù)還在2級片內緩存中，操作系統(tǒng)就認為這次命中了2級緩存，如果不在了，就說這次沒有命中2級緩存。因此我們可以知道操作系統(tǒng)是非?？释看味济?級緩存的，因為這樣就可以節(jié)省不少時間重新從內存中將數(shù)據(jù)加載到片內緩存中。
大多數(shù)操作系統(tǒng)要面對的任務都不會有太多的計算數(shù)據(jù)，因此這些任務不需要太多關心片內緩存的問題。同時多數(shù)低端的服務器也沒有很大的片內緩存，因此它們也不太關心這個問題。不過對于運行在有較大片內緩存的服務器上的SQL Server數(shù)據(jù)庫來說，這個問題就要嚴肅一些了。
在中高端的PC服務器(為什么說是PC服務器呢，因為Windows現(xiàn)在還可以運行在一些廠商的小型機平臺上，例如HP的SuperDome)中，通常單個處理器的片內緩存都在2M-4M，而且這些服務器可以擁有8個甚至更多一些的處理器，同時SQL Server數(shù)據(jù)庫的計算任務都是依賴于大量數(shù)據(jù)的，因此SQL Server的一個任務可不希望它重新拿回處理器的時候發(fā)現(xiàn)自己的數(shù)據(jù)不在了。
為了解決這個問題，SQL Server就有了這個處理器親和度(Processor Affinity)的配置項，啟用這個選項后，SQL Server中的任務就會記著自己原來在那個處理器上工作的，當它們再次有機會回到處理器工作的時候它們會認準回家的路——只用原來的那顆處理器。(事實上這個過程要復雜一些，有興趣的朋友可以進一步了解SQL Server數(shù)據(jù)庫中調度這個概念)。
【編輯推薦】
