Load高,CPU idle很高,这情况太诡异了
Load很高,CPU使用率很低的诡异情况
第一次碰到这种Case:物理机的Load很高,CPU使用率很低
先看CPU、Load情况如图一:
vmstat显示很有多任务等待排队执行(r)top都能看到Load很高,但是CPU idle 95%以上
这个现象不太合乎常规,也许是在等磁盘IO、也许在等网络返回会导致CPU利用率很低而Load很高
贴个vmstat 说明文档(图片来源于网络N年了,找不到出处)
所以分析到此,可以得出:Load高跟磁盘、网络、压力都没啥关系
物理机上是跑的Docker,分析了一下CPUSet情况:发现基本上所有容器都绑定在CPU1上(感谢 @辺客 发现这个问题)
进而检查top每个核的状态,果然CPU1 的idle一直为0看到这里大致明白了,虽然CPU整体很闲但是因为很多进程都绑定在CPU1上,导致CPU1上排队很长,看前面tsar的--load负载截图的 等待运行进程排队长度(runq)确实也很长。
物理机有32个核,如果100个任务同时进来,Load大概是3,这是正常的。如果这100个任务都跑在CPU1上,Load还是3(因为Load是所有核的平均值)。但是如果有源源不断的100个任务进来,前面100个还没完后面又来了100个,这个时候CPU1前面队列很长,其它31个核没事做,这个时候整体Load就是6了,时间一长很快Load就能到几百。
这是典型的瓶颈导致积压进而高Load。
为什么会出现这种情况检查Docker系统日志,发现同一时间点所有物理机同时批量执行docker update 把几百个容器都绑定到CPU1上,导致这个核忙死了,其它核闲得要死(所以看到整体CPU不忙,最忙的那个核被平均掩盖掉了),但是Load高(CPU1上排队太长,即使平均到32个核,这个队列还是长,这就是瓶颈啊)。
如下Docker日志,Load飙升的那个时间点有人批量调docker update 把所有容器都绑定到CPU1上:
检查Docker集群Swarm的日志,发现Swarm没有发起这样的update操作,似乎是每个Docker Daemon自己的行为,谁触发了这个CPU的绑定过程的原因还没找到,求指点。
手动执行docker update, 把容器打散到不同的cpu核上,恢复正常: 技术拓展商业边界,同样技能、熟练能力能拓展解决问题的能力。 开始我注意到了Swarm集群显示的CPU绑定过多,同时也发现有些容器绑定在CPU1上。所以我尝试通过API: GET /containers/json 拿到了所有容器的参数,然后搜索里面的CPUSet,结果这个API返回来的参数不包含CPUSet,那我只能挨个 GET /containers/id/json, 要写个循环,偷懒没写,所以没发现这个问题。 这种多个进程绑定到同一个核然后导致Load过高的情况确实很少见,也算是个教训 自己观察top 单核的时候不够仔细,只是看到CPU1 的US 60%,没留意idle,同时以为这个60%就是偶尔一个进程在跑,耐心不够(主要也是没意识到这种极端情况,疏忽了)相关文章
- c# 获取某个进程的CPU使用百分百(类似任务管理器中显示CPU)
- 科技云报道:ARM十年磨一剑,v9新架构会重构CPU市场吗?
- 4月9日,每天30秒,昨夜今晨一览无余/龙芯在河南鹤壁发布3D5000服务器CPU/国家能源集团与法国电力集团签署扩展合作协议
- 摆脱不必要的节流,同时实现高 CPU 利用率和高应用程序性能
- 编程获取Linux的内存占用和CPU使用率
- cuda-z/gpu-z/cpu-z工具分析GPU显卡和CPU算力信息
- 检测cpu、主板、内存
- wipefs进程是啥,占用了百分之90多的cpu
- 利用 FPGA 设计五段流水 CPU【100010244】
- Bus error (core dumped) 我重启了下superviser 资源cpu占用高
- 【Quark RISC-V】流水线CPU设计(5)控制冒险的处理
- 存储初创企业OpenIO力推ARM CPU与Kinetic驱动器
- mysql CPU太高排查办法
- Linux服务器对cpu、memory、IO、disk以及web服务(CPU、内存、磁盘、网络等)进行压力测试