將特定處理器分配給 SQL Server 2008 R2 集群實例是不是很糟糕？
我有一個帶有被動節點和主動節點的 SQL Server 2008 R2 故障轉移群集。伺服器在物理上是相同的。我有兩個 SQL Server 實例，一個設置使用前 3 個 NUMA 節點中的所有 CPU，另一個設置使用第 4 個 NUMA 節點中的所有 CPU。
這似乎工作正常，即使發生故障轉移，但這是一個壞主意嗎？
如果被動伺服器沒有那麼多處理器，故障轉移會發生什麼？
我不會說這是一個壞主意，但它總是不喜歡在 sql server 上觸及CPU 親和力，除非您確定問題是由於上下文切換過多（這也可能不是實際問題，而只是症狀）。
這似乎工作正常，即使發生故障轉移，但這是一個壞主意嗎？
強制關聯意味著您取消了 sql server 在調度程序之間移動程序的能力。
考慮以下範例：（使用來自 sysinternals 的 coreinfo）在 2 個插槽、12 個 CPU（24 個啟用超執行緒的邏輯 cpu）和 2 個 NUMA 節點機器上，我們每個 NUMA 節點有 12 個 CPU。
Logical to Physical Processor Map: **---------------------- Physical Processor 0 (Hyperthreaded) --**-------------------- Physical Processor 1 (Hyperthreaded) ----**------------------ Physical Processor 2 (Hyperthreaded) ------**---------------- Physical Processor 3 (Hyperthreaded) --------**-------------- Physical Processor 4 (Hyperthreaded) ----------**------------ Physical Processor 5 (Hyperthreaded) ------------**---------- Physical Processor 6 (Hyperthreaded) --------------**-------- Physical Processor 7 (Hyperthreaded) ----------------**------ Physical Processor 8 (Hyperthreaded) ------------------**---- Physical Processor 9 (Hyperthreaded) --------------------**-- Physical Processor 10 (Hyperthreaded) ----------------------** Physical Processor 11 (Hyperthreaded) Logical Processor to Socket Map: ************------------ Socket 0 ------------************ Socket 1 Logical Processor to NUMA Node Map: ************------------ NUMA Node 0 ------------************ NUMA Node 1請記住，調度程序不綁定到核心，SQL Server 執行自己的執行緒調度。出於某種原因，如果一個非 SQL 程序將 CPU 1 最大化，而該 CPU 1 正在調度程序 1 上執行一個執行緒，則 SQL Server 能夠將該調度程序放到任何可用的 CPU 上，例如 CPU 4。SQL Server 有自己的負載均衡器，它將移動從一個 CPU 到另一個 CPU 的執行緒。
如果您設置處理器關聯，那麼您將刪除 sql server 切換調度程序的能力。所以調度程序 1 綁定到 CPU 1，它只能在那裡執行。
我的圖書館的一些摘錄…
來自 SQL Server Professional Internals and Troubleshooting Book ：
軟 NUMA 的一個常見用途是當 SQL Server 託管一個應用程序時，該應用程序具有多個具有不同查詢要求的不同使用者組。在為軟 NUMA 配置理論上的 16 處理器伺服器後，將 2 × 4 個 CPU 節點和一個 8-CPU 節點分配給第三個 NUMA 節點，接下來將三個節點的連接親和性配置到不同的埠，然後更改連接為每一類工作負載設置，使工作負載 A “關聯”到埠 x，該埠連接到第一個 NUMA 節點；工作負載 B 關聯到埠 y，該埠連接到第二個 NUMA 節點，所有其他工作負載關聯到埠 z，該埠設置為連接到第三個 NUMA 節點。
來自 Microsoft SQL Server 2008 內部書：
在某些情況下，您可能希望限制可用 CPU 的數量但不將特定調度程序綁定到單個 CPU — 例如，如果您使用多 CPU 電腦進行伺服器整合。假設您有一台執行 8 個 SQL Server 實例的 64 處理器電腦，並且您希望每個實例使用其中的 8 個處理器。每個實例都有一個不同的關聯遮罩，它指定 64 個處理器的不同子集，因此您可能有關聯遮罩值 255 (0xFF)、65280 (0xFF00)、16711680 (0xFF0000) 和 4278190080 (0xFF000000)。因為設置了關聯遮罩，所以每個實例都有調度程序與 CPU 的硬綁定。如果您想限制 CPU 的數量但仍不限制特定調度程序在特定 CPU 上執行，您可以使用以下命令啟動 SQL Server跟踪標誌 8002。這使您可以將 CPU 映射到實例，但在實例中，調度程序不綁定到 CPU。
如果要限制 SQL 實例在伺服器上使用的 CPU，請改用Windows 系統資源管理器。
如果您決定使用“CPU Affinity”，一如既往地測試、測試和測試您的整個工作負載以避免任何嚴重的性能問題**。**
建議：將其保留為預設值 - 如果您弄錯了，事情會變得更糟，故障排除會更加困難！
如果被動伺服器沒有那麼多處理器，故障轉移會發生什麼？
參考 ：
- 親和遮罩伺服器配置選項
“不要碰那個按鈕！” SQL Server 中的四個危險設置（影片已存檔 - 因此不再可用）- SQL Server 2008 R2 的關聯設置更改
- SQL Server 和軟 NUMA
- 在 SQL Server 中設置處理器關聯——（不需要的）副作用