雖然昨天的第一招失敗了，但是從失敗中我們學到了與多核CPU相關的Processor Affinity(處理器關聯)的知識。
既然我們可以讓.NET程序的不同線程運行於指定的CPU核，那是不是也可以讓IIS應用程序池的進程w3wp運行於指定的CPU核？
雖然看起來“黑色n秒”似乎與w3wp運行於哪些CPU核沒有什么關系，但是我們既然把懷疑對象鎖定在CPU，那么任何與CPU相關的線索都不能放過。即使失敗，也會滿載而歸，因為如果沒有“黑色n秒”這個問題的驅動，我們根本不會有心思去研究Processor Affinity，以前在IIS應用程序池的高級設置中看到這個設置，都搞沒明白是干嗎的。
Google之后，才知道在IIS應用程序池的高級設置“CPU”中有3個設置，通過這3個設置，就可以給w3wp進程關聯指定的CPU核。這三個設置分別是：
a) Processor Affinity Enabled（已啟用處理器關聯）：默認值是False，w3wp進程會使用所有CPU核。
b) Processor Affinity Mask（處理器關聯掩碼）：默認值是4294967295，通過這個掩碼可以指定CPU核。
c) Processor Affinity Mask(64-bit options)（處理器關聯掩碼64位選項）：默認值也是4294967295，這是針對64位計算機的設置。
之前我們一直用的是默認設置，CPU的8個核通常被使用的是前4個，第1個核的負載始終最高，而后面3個核的負載會依次降低。
我們不禁產生了這樣的疑問：為什么總是優先使用前4個核，難道排名分先后？為什么不均勻地分配負載，難道排在前面的處理能力更強些？
既然我們遇到的問題如此不尋常，那我們的解決方法也應該不走尋常路，我們偏偏就用后面的4個核！
於是，我們在IIS應用程序池中進行了這樣的設置：Processor Affinity Enabled設置為True，Processor Affinity Mask設置為240（二進制數11110000轉換為十進制就是240）。
這樣設置好，驚喜地發現CPU后4個核上的負載分配更均勻了。
從早上10:16這樣設置后到目前還沒出現“黑色1秒”，而同一個負載均衡中的另外一台服務器沒有進行這樣的設置，已經出現過多次“黑色1秒”。
雖然還需要進一步觀察一段時間才能確認“黑色1秒”問題是否真正解決，但是今天的這一招讓我們看到了希望的田野。
【補充】
如果Processor Affinity Mask設置為252(11111100)，也就是分配后6個核，結果負載會集中在第3個核上。
【最終結果】
后來的觀察數據顯示，這一招也失敗了。。。
【參考資料】