你的CPU被谁偷了
当你输入TOP命令的时候,会在第三列出现一个cpu使用率的实时统计。
具体这些值的含义,可以参考之前的文章TOP命令之任务和CPU状态
本文就集中讨论一下CPU使用率中的steal部分
CPU使用率中的steal部分是什么
根据红帽官方文档的介绍,Steal Time是虚拟机(guest)所需,但是宿主机(host)未提供的CPU时间。
需要但是未提供,说明cpu是出于非自愿等待的情况下
st%部分只会出现在虚拟化实例中
steal time 可以在/proc/stat中的CPU时间字段中找到相关信息,以st%为字段名出现。
大量的steal time 说明存在CPU争用,这会降低客户机性能。
CPU steal time 出现的原因
进程需要的CPU数量超过分配的CPU数量
当虚拟机上运行负载繁重的进程时,分配给它的 CPU 周期可能不足以处理工作负载。典型的例子就是高并发下的高负载场景。
物理服务器因虚拟机而超载
在这种情况下,云服务器提供商超额订购了带有虚拟机的物理服务器,导致物理 CPU 无法处理进程。通俗讲就是一台物理机上有过多的虚拟机征用资源导致的超载。
作为客户机本身,是意识不到自己到底是因为那种原因导致的steal time过高,但是如果在集群化设备中,不同的宿主机上运行着相同的客户机和服务,则可以很轻松的判断steal time出现的原因。
CPU steal time 过长会导致的问题
在具有高窃取时间的虚拟机上运行程序,可能会导致以下严重的问题
I/O 缓慢
页面的加载(换入)缓慢
数据库查询缓慢
由于无法快速处理异步任务,导致任务队列变长
被盗的 CPU 会降低机器速度,甚至在极端情况下导致机器完全停止运行。所以,对steal time要高度警惕。
Steal time的警戒线
如果 CPU steal time低于 10%,则无需担心,应用程序应该可以顺利运行。
但是,如果窃取时间的值大于 10%(即高于正常值约 20-30 分钟),则 VM 的运行速度可能会比预期慢。
如果窃取时间仍然很高,则表明存在 CPU 争用,这会降低应用程序的性能。
如何处理steal time过高的问题
迁移至物理机。
相信这也是许多数据库实例,尤其是大型数据库所经历的。诟病云上性能差的一个主要原因就是虚拟化在高负载场景下的尴尬表现。
当然,单独的物理机成本更高,而且需要有专业团队维护,还需要提供机房场地,如果这些暂时无法满足,可以退而求其次的考虑升级虚拟机,如果虚拟机的实例尺寸也已经是最大的,那单纯从硬件层面考虑,就只能下云了。
限制同一宿主机下的每个虚拟机的使用
这也是最常见的情况,追求成本和产出比,服务器提供商会尽量的将同一宿主机上放置更多的客户机(超售 over-sold ),而忽略了因业务产生的增量部分,这是限制每个虚拟机的处理能力,防止CPU争用长时间存在。
评论区