不要完全相信Linux Top:超线程(Hyperthreading)深入浅出

Posted by 云谷计算 on January 17, 2018

超线程的技术原理

超线程技术在一个物理核上模拟两个逻辑核,两个逻辑核具有各自独立的寄存器(eax、ebx、ecx、msr等等)和APIC,但会共享使用物理核的执行资源,包括执行引擎、L1/L2缓存、TLB和系统总线等等。

超线程对性能的影响分析

可以看出,超线程技术仅仅是在一个物理核心上使用了两个物理任务描述符,物理计算能力并没有增加。现在很多程序如web application, 都采用多worker设计,在超线程的帮助下,两个被调度到同一核心不同超线程的worker,通过共享cache, TLB,大幅降低了任务切换的开销。另外,在某个worker不忙的时候,超线程允许其它的worker也能使用物理计算资源,有助于提升物理核整体的吞吐量。但由于超线程对物理核执行资源的争抢,业务的执行时延也会相应增加。

从Intel和VMware对外宣称的资料看:

  1. 开启超线程后,物理核总计算能力是否提升以及提升的幅度和业务模型相关,平均提升在20%-30%左右

  2. 当超线程相互竞争时,超线程的计算能力相比不开超线程时的物理核会下降30%左右

超线程对性能影响的验证

测试环境 CPU: E5645 2.40GHZ, 2个Socket,每个Socket 6个核,每个核两个超线程 内存: 46G L3 Cache: 12M 操作系统:CentOS 7.2 测试方法 负载:C++编译任务,CPU密集型任务,通过编译任务的编译时长评估性能 存储:编译任务涉及的源文件放置到RAMFS上,避免存储的影响 CPU隔离:启动OS时,通过isolcpus参数将Socket1对应的所有超线程进行隔离,避免操作系统其它线程调度到这些超线程上 运行负载:通过taskset对负载进行绑核运行 测试结果 下图对比的是仅运行一个负载和同时在一个核的两个超线程上运行负载的时间对比,可以看出在存在超线程竞争时,单超线程计算能力大概是物理核的60%左右:

下图是不同数量负载同时运行时的平均编译时间,此时没有两个负载运行在同一个核的两个超线程上。可以看出,不存在超线程竞争时,负载平均运行时间基本不变:

下图表明运行在同一个核两个超线程上的负载,其运行时间大幅增加:

节点CPU负载的衡量

在Linux下每个超线程会被当作一个核,通过Top等常用的工具只能采集到超线程的负载,并不能真正反映出超线程所在物理核的负载,也不能反映出真实的计算能力。比如如下两种情况,Top命令均会认为节点CPU平均占用率已经达到50%,但实际上,两者对外提供的计算能力是不同的,前者的计算能力是两个物理核的能力,后者的计算能力是一个物理核的120%左右。

Top 显示CPU负载50%, 实际物理CPU负载100%

Top 显示CPU负载50%, 实际物理CPU负载50%

在这方面,VMWare的vSphere中包含的esxtop工具,CPU相关的指标有如下三个:

  1. PCPU USED(%):超线程实际所消耗的物理核计算能力的百分比,计算时将同一物理核两个超线程同时运行的时间折半计算
  2. PCPU UTIL(%):超线程处于运行状态的百分比,所谓的运行状态是指超线程处于unhalted状态
  3. CORE UTIL(%):物理核处于运行状态的百分比

在vSphere的ESXi主机上运行两个1U的虚拟机,分别绑定到一个核的两个超线程上,在虚拟机内部运行计算任务,确保虚拟机内部CPU占用率在50%左右,可以看到,ESXi主机上两个超线程使用率在45%左右,物理核负载已经达到80%:

Linux下TOP命令查询到的超线程占用率基本等同于vSphere的PCPU UTIL(%)指标,缺少PCPU USED(%)和CORE UTIL(%)对应的指标。

何时应该开启/关闭超线程

超线程应该关闭还是开启,主要还是取决于应用模型:

  1. 对于时延敏感性任务,比如用户需要及时等待任务运行结果的,在节点负载过高,引发超线程竞争时,任务的执行时长会显著增加,影响用户体验
  2. 对于后台计算型任务,比如超算中心上运行的后台计算型任务(一般要运行数小时或数天),建议开启超线程提高整个节点的吞吐量