云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对“黑色n秒”问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段——出招。

今天出第一招——用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU
idle引起的“黑色n秒”。

在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity。通过给ProcessorAffinity设置一个掩码,就可以指定当前线程运行于哪个CPU核上。

如上图,用哪个核就把那个核对应的二进制位置1,其他位保持0。

所以对于我们所用的8核CPU,从第1核到第8核对应的ProcessorAffinity分别是:1, 2, 4, 8, 16, 32, 64,
128。

需要注意的地方是ProcessThread.ProcessorAffinity针对的是Windows操作系统线程,而.NET线程并不是与操作系统线程一一对应的,一个.NET线程可以运行于多个操作系统线程。所以,如果仅仅指定ProcessThread.ProcessorAffinity,并不能保证.NET线程运行于指定的CPU核上。那怎么办呢?

微软提供了解决方案,在设置ProcessThread.ProcessorAffinity之前需要通过下面的代码将.NET线程固定在操作系统线程上:


Thread.BeginThreadAffinity();

还有一个需要解决的问题是如何让一个线程一直处于执行状态,从而不让其所在的CPU核进入idle状态。微软也提供了解决方案,调用非托管方法SetThreadExecutionState(),代码如下:


NativeMethods.SetThreadExecutionState(NativeMethods.ES_CONTINUOUS | NativeMethods.ES_SYSTEM_REQUIRED);

下面请看招式:

代码第1部分:


class Program
{
static void Main(string[] args)
{
var threads = new Thread[Environment.ProcessorCount];
Console.WriteLine("Processor Count:" + Environment.ProcessorCount);
for (int i = 0; i < threads.Length; i++)
{
var coreNumber = i + 1;
var threaName = "ThreadOnCPU" + coreNumber;
var start = new ThreadStart(() =>
{
Console.WriteLine(threaName + " is working...");
NativeMethods.SetThreadExecutionState(
NativeMethods.ES_CONTINUOUS | NativeMethods.ES_SYSTEM_REQUIRED);
});
var thread = new DistributedThread(start);
thread.ProcessorAffinity = (int)Math.Pow(2, i);
thread.ManagedThread.Name = threaName;
thread.Start();
}
Console.ReadKey();
}
}

internal static class NativeMethods
{
[DllImport("kernel32.dll")]
public static extern uint SetThreadExecutionState(uint esFlags);
public const uint ES_CONTINUOUS = 0x80000000;
public const uint ES_SYSTEM_REQUIRED = 0x00000001;
}

代码第2部分(来自Running .NET threads on selected processor cores):

class DistributedThread
{
[DllImport("kernel32.dll")]
public static extern int GetCurrentThreadId();

[DllImport("kernel32.dll")]
public static extern int GetCurrentProcessorNumber();

private ThreadStart threadStart;

private ParameterizedThreadStart parameterizedThreadStart;

private Thread thread;

public int ProcessorAffinity { get; set; }

public Thread ManagedThread
{
get
{
return thread;
}
}

private DistributedThread()
{
thread = new Thread(DistributedThreadStart);
}

public DistributedThread(ThreadStart threadStart)
: this()
{
this.threadStart = threadStart;
}

public DistributedThread(ParameterizedThreadStart threadStart)
: this()
{
this.parameterizedThreadStart = threadStart;
}

public void Start()
{
if (this.threadStart == null) throw new InvalidOperationException();

thread.Start(null);
}

public void Start(object parameter)
{
if (this.parameterizedThreadStart == null) throw new InvalidOperationException();

thread.Start(parameter);
}

private void DistributedThreadStart(object parameter)
{
try
{
// fix to OS thread
Thread.BeginThreadAffinity();

// set affinity
if (ProcessorAffinity != 0)
{
CurrentThread.ProcessorAffinity = new IntPtr(ProcessorAffinity);
}

// call real thread
if (this.threadStart != null)
{
this.threadStart();
}
else if (this.parameterizedThreadStart != null)
{
this.parameterizedThreadStart(parameter);
}
else
{
throw new InvalidOperationException();
}
}
finally
{
// reset affinity
CurrentThread.ProcessorAffinity = new IntPtr(0xFFFF);
Thread.EndThreadAffinity();
}
}

private ProcessThread CurrentThread
{
get
{
int id = GetCurrentThreadId();
return
(from ProcessThread th in Process.GetCurrentProcess().Threads
where th.Id == id
select th).Single();
}
}
}

DistributedThread

接下来,出招——KeepAllCpuCoresAlive!

结果。。。这一招以失败告终!

(上图是“黑色1秒”发生时性能监视器监测到的ASP.NET Requests/Sec为0的情况)

失败又如何,就如同代码编译不通过一般不值一提。那为什么还要写博客出来呢?分享的就是过程!

接下来呢?准备第二招。。。

【参考资料】

Running .NET threads on selected processor cores

Threading in
C#

Keep Alive the Machine - No Sleep

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲,布布扣,bubuko.com

时间: 2024-10-13 15:57:47

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲的相关文章

云计算之路-阿里云上:“黑色1秒”问题与2009年Xen一个补丁的故事

在之前对"黑色1秒"问题的分析博文中,我们将最大嫌疑对象锁定在了Xen,在这篇博文我们将从Xen的角度进行分析.也许有人会问,为什么不知道天多高地多厚地去研究不属于自己范围的问题?只因我们对一个问题的强烈好奇心--究竟是不是我们用Windows的错? 2009年3月20日,来自Intel的Yu Ke通过Xen-dev Mailing List给来自Citrix的Keir Fraser(负责的Xen开发者之一)发了一封邮件,提交了Xen的一个patch--cpuidle: suspend

云计算之路-阿里云上:“黑色1秒”最新线索——w3tp与w3dt

向大家分享一下最近排查"黑色1秒"问题的进展,"黑色1秒"的问题表现详见什么是黑色1秒. 1. 发生在w3wp进程内 判断依据:"黑色1秒"期间,http.sys的HTTP Service Request Queues\ArriveRate正常,W3SVC_W3WP\Requests/Sec正常. 2. 请求未进入.NET线程池 判断依据:"黑色1秒"期间静态文件的请求也不能被处理,如果"黑色1秒"发生在.

云计算之路-阿里云上:黑色1秒,微软的问题还是阿里云的问题?

"黑色1秒"问题经过一个多月的艰苦奋战,今天终于取得了重要进展!我们终于有了足够的数据证明不是微软IIS的问题,就是阿里云Xen虚拟机的问题. 这篇博文分享的是我们如何进行证明的,而且这次证明连Window性能监视器都不需要. 下面我们来分析一下今天10:37:35出现的"黑色1秒"(下面所用的IIS日志分析工具是Log Parser Studio,这是我们在排查"黑色1秒"问题期间对我们帮助最大的一个工具). 1. 先从IIS日志中找出哪些时间

云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上:消灭“黑色n秒”第三招——禁用网卡的TCP/IP Offload

程咬金有三板斧,我们有三招.在这篇博文中我们要出第三招,同时也意味着昨天在"希望的田野"上的第二招失败了. 前两招打头(CPU)不凑效,这一招要换一个部位,但依然要坚持攻击敌人最弱(最忙最累)部位的原则.那除了CPU,最忙最累的部位是哪里呢?对于Web服务器来说,毫无悬念,当然是网卡.而且阿里云的云服务器,所有的网络负载都集中在一块内网网卡上,SLB(负载均衡)用它,OCS(缓存服务)用它,RDS(数据库服务)也用它.所以,就对它出招! 招式受这篇博文(XenServer – Wind

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为

云计算之路-阿里云上:读取缓存时的“黑色0.1秒”

看到标题中的"0.1秒",你也许会呲之以鼻:不会吧,0.1秒也要计较,不是吃饱撑着,是没吃饱也撑着. 依然没撑着!在memcached应用场景中,响应速度是处于1ms级别的,0.1s可是比1ms慢了100倍啊. 如果你不相信1ms级别,请看这篇文章(微博CacheService架构浅析)中的一段话: 目前微博平台部分业务子系统的Cache服务已经迁移到了CacheService之上,它在实际的运行过程中也取得了良好的性能表现,目前整个集群在线上每天支撑着超过300W的QPS,平均响应耗