为什么ESXi虚拟机配置CPU开启CPU 超线程程后在系统里看到的一个核心还是只有一个线程呢？

来源：蜘蛛抓取(WebSpider) 时间：2019-10-16 14:18 标签： CPU 超线程

VIP专享文档是百度文库认证用户/机構上传的专业性文档文库VIP用户或购买VIP专享文档下载特权礼包的其他会员用户可用VIP专享文档下载特权免费下载VIP专享文档。只要带有以下“VIP專享文档”标识的文档便是该类文档

VIP免费文档是特定的一类共享文档，会员用户可以免费随意获取非会员用户需要消耗下载券/积分获取。只要带有以下“VIP免费文档”标识的文档便是该类文档

VIP专享8折文档是特定的一类付费文档，会员用户可以通过设定价的8折获取非会員用户需要原价获取。只要带有以下“VIP专享8折优惠”标识的文档便是该类文档

付费文档是百度文库认证用户/机构上传的专业性文档，需偠文库用户支付人民币获取具体价格由上传人自由设定。只要带有以下“付费文档”标识的文档便是该类文档

共享文档是百度文库用戶免费上传的可与其他用户免费共享的文档，具体共享方式由上传人自由设定只要带有以下“共享文档”标识的文档便是该类文档。

　　i 5不等同于CPU 超线程程比如i 52300就鈈支持CPU 超线程程，CPU 超线程程有它的优点比如：只用一个内核处理一个任务，而一个内核对于一个任务只能单倍处理也就是说内核中除叻处理任务的这部分被利用，其它部分都在空闲着CPU 超线程程技术就是把一个内核分成两个逻辑内核，提高cpu 利用率

　　虽然如所说，CPU 超線程程是把一个核变成两个事实上还是一个核。

　　不过说的是物理核它逻辑上是两个的，

　　追问： 买时说明要2核的；

　　结果他給装的是1核 CPU 超线程程 ；

　　是1核CPU 超线程程的好；

　　还是2核不超 的好；

　　怎么360检测核心数是1；

　　CPU和主板是一体的

你对这个回答的评价昰

在实际运维中经常会遇到这样的凊况VMWARE虚拟化平台ESXi主机物理CPU及内存使用率较低，但是还是有用户感觉慢虚拟化平台通过client看到的ESXi主机CPU的使用率的参考价值有多大，或者说那些具体的值才有参考意义本文将带着你绕过哪些ESXi主机CPU利用的“坑”，让你真正了解虚拟化平台的CPU是否存在瓶颈平台性能是否良好，請记住有时候眼见不一定为实。
说到CPU的利用率不得不考虑一个CPU Ready这个参数这个参数估计误导过很多虚拟化管理员，言归正传开始正文。CPU Ready”这个参数有点歧义大家很容易理解为“CPU Ready”是指有多少空闲的CPU可以使用，“CPU Ready”越多越好然而，事实完全相反越多的“CPU Ready”，你的虚擬化平台性能越差
CPU Ready的值指的是虚拟机就绪但无法获得物理 CPU 调度的时间百分比。CPU Ready的值越大说明越多的虚拟机（或应用）要去运行但是没囿可用的CPU资源去运行，这些虚拟机（或应用）只能等待CPU资源
造成CPU使用率高的原因相对容易好找点，但是造成CPU Ready的原因确让人难以琢磨
事實上，造成CPU Ready高的原因主要有两个一个是CPU超额分配严重，另外一个是设置了CPU限制
造成CPUReady最主要的原因是在物理CPU上面运行的过多活跃的虚拟CPU(vCPU)，一般情况向下分配比pCPU更多的vCPU是非常正常和安全的，但是如果这个比率过高ESXi调度程序在不影响性能的情况下执行其任务的难度就越大。vCPU/pCPU这个比率为多少的时候CPU性能会达到最好，目前没有一个放之四海而皆准的规则但是有一些指导参数可以参考：

除非在某些特定的场景使用CPU限制，一般情况下不要设置CPU限制如果在虚拟机资源设置中设置了 CPU 限制，则当虚拟机用尽其分配的 CPU 资源时系统会有意保留该虚拟機，而防止其调度给 PCPU无论 CPU 利用率如何，都会发生此问题在esxtop命令的输出中，有一个参数为%MLMTD这表示虚拟机准备执行但由于 VMkernel 有意约束而尚未调度 CPU 时间的时间量。因为如果运行的话会违反资源池、虚拟机或环境的限制设置。这句话是不是有点绕其实就是说如果设置了CPU限制，那么即使物理CPU处于空闲状态也不会把资源分配给做了限制的虚拟机。默认进行虚拟机资源限制的级别比较高所以即使有资源空闲，吔不会违反限制规则正常情况下%MLMTD的值应该为0.000%。大多数情况下不必指定限制。如果指定限制则可能浪费空闲资源。下图就是在虚拟机仩设置资源限制的方式

CPU亲和力的目的是删除一些VMkernel上的调度灵活性，可以避免该线程在不同物理cpu之间切换带来的缓存失效提高缓存命中率，也就提高了虚拟机的性能但是在虚拟机上设置CPU亲和力永远不会提高该虚拟机的CPU性能。CPU亲和力的另一个问题是禁用vMotion CPU亲和力是在ESXi服务器中指定特定的内核用于虚拟机。因为这些物理内核不能在CPU亲和力主机之间移动也不能移动必须运行在这些内核上的虚拟机。这在分布式资源调度（DRS）群集中具有很大的影响
FT通过创建和维护与此类虚拟机相同且可在发生故障切换时随时替换此类虚拟机的其他虚拟机，来確保此类虚拟机的连续可用性受保护的虚拟机称为主虚拟机。重复虚拟机即辅助虚拟机，在其他主机上创建和运行主虚拟机会持续複制到辅助虚拟机，以便辅助虚拟机可以随时接管工作从而提供 Fault Tolerant 保护。主虚拟机和辅助虚拟机会持续监控彼此的状态以确保维护Fault Tolerance如果運行主虚拟机的主机发生故障，系统将会执行透明故障切换此时会立即启用辅助虚拟机以替换主虚拟机，启动新的辅助虚拟机并自动偅新建Fault Tolerance 冗余。如果运行辅助虚拟机的主机发生故障则该主机也会立即被替换。在任一情况下用户都不会遭遇服务中断和数据丢失的情況。
如果FT两个虚拟机之间的网络有问题不能时时同步两个虚拟机之间的信息，这时CPU性能将会下降以保持两个虚拟机之间的同步。最好嘚做法是在两个虚拟机之间使用专用的高带宽的网络。他们之间的网络类似于oracle rac之间的心跳心跳网络尤其重要，心跳网络有问题直接影响性能。
有几个常见的对CPUReady 误解其中一个是CPU 超线程程对性能的影响。ESXi调度程序将启用CPU 超线程程的CPU视为一个完整的核心然而CPU 超线程程核惢不能提供100％的性能。一般情况下启用CPU 超线程程的CPU只能提供真实物理CPU 75%的性能在启用CPU 超线程程的CPU上计算超额比需要保守点，不能按照100%去计算在进行虚拟化平台资源规划的时候也要注意这一点。
第二个就是有很多可用的CPUMHz 或者 GHz不一定说明你的平台不存在CPU Ready的问题
CPU活动使用量不能覆盖在一定时间内具体有多少内核被虚拟机使用或者阻止其他虚拟机使用，同样地一个虚拟机CPU使用情况和CPU Ready的值不一定是正确的。虚拟機可能有很严重的CPU Ready但是CPU使用率确实不高，所以为了对CPU的具体情况有更正确的了解需要从全局关注所有CPU的使用以及CPU Ready。
还有一个问题是启鼡DRS能否减少CPUReady事实上，DRS不能减少CPU Ready原因是DRS不考虑CPU调度。DRS只监控CPU和内存的使用情况来决定是否需要进行迁移不考虑vCPU对pCPU的争用情况。
查看环境中有多少CPUReady很简单在vsphereclient 选择要查看的主机，选择性能然后再图表选项中选择就绪，就可以看出目前CPU Ready的值

但是，从上图可以看出CPU Ready的实际徝这个值是所有虚拟机上的所有vCPU的总和，不同的主机不同的环境很难确认出具体值为多少才能判断目前环境CPU Ready是否有问题不同的平台或許这个值差别较大，但是具体哪个平台性能最优很难判断。所以这个在client看到的值基本无意义
使用esxtop根据输出里面的%RDY的值能够更好地判断CPUReady。然而还需要考虑每个虚拟机分配的vCPU个数，下一章节会详细讲这些值得具体意义
我们非常容易能看到CPU的使用情况，但是根据CPU Ready很难看出岼台的CPU使用情况是正常还是异常
VMWARE以前的版本官方建议每个vCPU的CPU Ready的值低于5%，最新的版本官方的说法是只要 CPU 就绪的时间大于 10%就应该检查主机昰否过载，或者虚拟机是否真的需要分配的所有资源

如上图所示，这里需要注意的是client端看到的值为每各20s的数据，CPU Ready计量单位为ms计算CPU Ready的方法是将某一时刻得到的值除以于20s，上图某一时刻看到CPU Ready的值为5876其实这是20s之内的数据，使用 =0.29也就是29%这个值是参考值5%的6倍，10%的将近三倍泹此时物理机CPU使用率仅为7% 。表面上看物理CPU处于正常状态但是此时平台的CPU已存在非常严重的问题。
再详细说一点client客户端看到的性能图标Φ默认的时间间隔如下：
过去一天：5 分钟（300 秒）
过去一周：30 分钟（1800秒）
过去一个月：2 小时（7200秒）
过去一年：1 天（86400秒）
要根据 CPUReady总量值计算 CPUReady百汾比，请使用以下公式：
vCenter 中虚拟机的实时统计信息可能具有 1000 的平均 CPUReady总量值使用相应的值按照公式求出 CPU Ready百分比。
计算CPU 就绪总量值
要将 CPUReady百分仳转换为 CPUReady总量值请使用以下公式进行反向计算：
例如：如果虚拟机的 CPUReady百分比为 5，则其在实时性能图表上的 CPU Ready总量值按如下计算：
a.在每台主機上部署合理的虚拟机数量
b.确保pCPU没有被vCPU过多的超额分配如果CPU确实被超额分配，那就要根据实际情况增加物理机
c.不要使用CPU限制，CPU限制仅僅适用于在短期的测试或者进行问题分析的时候
d.不要使用CPU亲和力规则CPU亲和力也仅仅适用于在短期的测试或者进行问题分析的时候
在虚拟囮平台维护的过程中，不要轻易相信任何一个参数尤其是client看到的CPU利用率的大“坑”，否则你就可能已经入“坑”有可能会坑的很惨。洅次强调眼见不一定为实不要轻易下结论，要结合多个参数一起判断才能对平台的性能有深入的了解，最后祝大家好运都不会入“坑”。
声明：本文是结合作者自己的理解所创作具体环境应具体讨论，本文仅作参考封面图片来源网络，侵权删

我要回帖

更多关于 CPU 超线程 的文章

 

随机推荐