虽然昨天的第一招失败了，但是从失败中我们学到了与多核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个核上。

【参考资料】

CPU Settings for an Application Pool