我們知道SQL Server所能檢測到的CPU是邏輯CPU個數。而不是物理CPU個數。雙核CPU對於SQL Server來講，是兩個邏輯CPU,如果有超執行緒的話，CPU個數還要翻一倍。邏輯CPU個數，通常能在Windows 的Task Manager裡顯示出來, 在CPU Usage History裡，有多少個框，就有多少個邏輯CPU

【問題】

但是在有一些很高階的機器上，我們會發現一些比較有趣的現象。SQL Server所能檢測到的CPU個數，竟然和邏輯CPU個數不符合。

如下面的機器配置，有4個物理CPU, 每個CPU上有10個Cores, 而且也enable了超執行緒。所以這臺機器上，總共有80個邏輯CPU,按道理，SQL Server應該能檢測到80個CPU才對。

但我們檢視SQL Server的錯誤日誌，SQL Server 竟然只能檢測到40個CPU.

在另外一臺相同配置的機器上，SQL Server 重啟後，有時候能檢測到20個CPU, 有時候能檢測到60個CPU。

SQL Server能檢測到的CPU個數竟然會隨著SQL Server重啟，而有所變化。本來SQL Server效能很好，重啟後，SQL Server能使用的CPU變成20了，效能就會變得很差。這對於很高階的應用來講，是不能接受的。

【調查】

對於這個非常奇怪的現象，我們似乎是無從下手，難道是SQL Server的版本限制？但是我們的SQL Server版本已經是Enterprise了, 好像是SQL Server的一個Bug, 但是又不能確定。

調查一

我們做了進一步的研究。我們知道，SQL Server所檢測到的CPU個數，是通過呼叫下面的函式所得到的:

SYSTEM_INFO siSysInfo;

GetSystemInfo(&siSysInfo);

printf("  Number of processors: %u\n", siSysInfo.dwNumberOfProcessors);

我們寫了一個repro程式，完整的程式碼如下：

// SystemInfo.cpp : Defines the entry point for the console application.

#include "stdafx.h"

#include <windows.h>

#include <stdio.h>

#pragma comment(lib, "user32.lib")

int _tmain(int argc, _TCHAR* argv[])

{

   SYSTEM_INFO siSysInfo;

   // Copy the hardware information to the SYSTEM_INFO structure.

   GetSystemInfo(&siSysInfo);

   // Display the contents of the SYSTEM_INFO structure.

   printf("Hardware information: \n"); 

   printf("  OEM ID: %u\n", siSysInfo.dwOemId);

   printf("  Number of processors: %u\n", siSysInfo.dwNumberOfProcessors);

       return 0;

}

編譯執行上述程式碼，問題能夠重現:

D:\TEMP>systeminfo_x64.exe

Hardware information:

  OEM ID: 9

  Number of processors: 60

D:\TEMP>systeminfo_x64.exe

Hardware information:

  OEM ID: 9

  Number of processors: 20

D:\TEMP>systeminfo_x64.exe

Hardware information:

  OEM ID: 9

  Number of processors: 20

D:\TEMP>systeminfo_x64.exe

Hardware information:

  OEM ID: 9

  Number of processors: 60

所以，到了這一步，我們可以判定，問題跟SQL Server無關。但是為什麼GetSystemInfo() 得到的CPU個數會變來變去呢？難道是GetSystemInfo() 這個API的Bug?

調查二

我們仔細研究了GetSystemInfo這個API, 其中，_SYSTEM_INFO 這個結構描述在:

dwNumberOfProcessors: The number of logical processors in the current group

這裡，”current group” 這個詞引起了我們的注意。

調查三

我們做了進一步研究，發現在Windows 7和Windows Server 2008 R2 裡，我們引入了Processor Group 這個概念， 具體描述在http://msdn.microsoft.com/en-us/library/dd405503(v=vs.85).aspx  簡單的講，64位的Windows7和Windows Server 2008 R2為了能夠在一臺機器上，支援超過64個邏輯CPU, 引入了Processor Group這個概念。Processor Group會把一些邏輯CPU編成一個組，但是一個組內的邏輯CPU總數不能超過64個。超過64個的話，要編入另外一個組。

所以，對於我們的系統，有80個邏輯CPU, 那麼就會編成兩個組。是不是每個組均勻的分配CPU呢，不是的。作業系統會在重啟的時候，根據邏輯CPU之間的物理遠近，自動進行編組。所以，在有的系統上，我們會看到40-40分配，在另外系統上，我們會看到20-60分配。

那麼，每當一個程序執行的時候，它會在哪個Processor Group上執行呢？ 作業系統會按照Round-robin方式，給每個程序分派Processor Group, 一旦一個進行分配到了一個Processor Group, 就會一直在這個Processor Group裡執行，直到該程序結束為止。

【解釋】

所以，這就解釋了，為什麼SQL Server 2008 有時候能檢查到20個CPU, 有時候能檢查到60個CPU, 這完全是因為Processor Group在起作用。每次SQL Server 重新啟動後，有可能被分配到另外一個Processor Group, 而導致能檢查到的CPU個數出現變化。

我們可能會問，為什麼SQL Server 2008 會通過呼叫GetSystemInfo(&siSysInfo); 的辦法來獲取邏輯CPU個數呢？難道不能用其他API麼？這是因為，Processor  Group這個概念是在Windows Server 2008 才引入的。當開發SQL Server 2008的時候，並沒有做相應的變化。當然，這個問題在SQL Server 2008 R2得以解決。SQL Server 2008 R2能最多同時檢測到256個邏輯CPU.

【解決方案】

最好的解決方案是把SQL Server 2008 升級到SQL Server 2008 R2. 如果短期內不可行的話，我們可以把超執行緒禁用。這樣系統上邏輯CPU的個數會變成40個。小於64個，所有的CPU會被編入一個組。雖然SQL Server能檢測到的CPU只有40個，但至少系統是穩定的。

我們可能還會問，是否有辦法，能否人工干預Processor Group的編組，一個組有64個CPU, 另外一個組有16個CPU?  對於NUMA架構的話，我們可以做一些適當的調整，具體可參考: http://support.microsoft.com/kb/2506384

另外，如果我們碰到Processor Group按20-60分配的情況，對系統整體效能是有影響的。建議打一個作業系統的補丁:

Performance issues when more than 64 logical processors are used in Windows Server 2008 R2

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2510206