丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
压测信息：压测工具是jmeter，压测的并发数都是1并发，压测的URL固定。
资源信息：ACK集群的ECS是32C，ingresspod无limit限制,业务pod采用绑核处理8c或12c
链路：客户端->nginx（同VPC下的ECS）->SLB>ingresspod->业务pod
客户压测时候，采用slo-manager对业务pod采用绑核处理，表明业务pod上的ECS设置的limit核数，业务pod独占，不与其他进程共享。客户遇到一个奇怪现象是采用12c绑核的。可以看到采用12C时候，，CPU使用率达到100%时候，qps、rt和P99指标相对于8c指标反而并没有提高。
压测结果
4.12核心pod部署在cn-beijing.xxxx节点上，pod绑定的CPU核心是16-31这16个CPU中
5.12核pod查看slo是工作的，cgroup显示动态绑核是成功的
6.但是通过cpu.stat，可以看到依然存在CPUthrottle
7.promethes监控显示在同样绑核情况下，8c的pod没有CPUthrottled，12c的pod，CPU使用率相比于8C并没有100%趋势下，反而遇到了CPUthrottled，明显不符合预期。但是前面的步骤已经验证了绑核是成功的，由此怀疑到应该是系统层面对于cfs调度存在的未知的非预期的行为.
12核
8核
容器内跑一些压力时（使用while:;do:;done模拟）
复现情况如下：
1、Cenos7.9，对应3.10内核，很容易复现
发生CPUThrottling比例～1%
2、alinux2，对于4.19内核，
发生CPUThrottling比例～千分之一
这个时候查看该容器路径下的cpugroup的cpu.stat，其中throttled_time会被限制了240ms（对于每100毫秒的周期，应用程序只能运行40ms，并被限制60ms。4个周期，因此4*60=240ms。）
容器环境中，一个关键指标是throttling，这表明容器被限制的次数。我们发现很多容器无论CPU使用率是否接近极限都会受到限制。如下一个案例：
在动画中可以看到CPU限制设置为800m（0.8个核心，80%的核心），峰值使用率最高为200m（20%的核心）。看到之后，我们可能会认为我们有足够的CPU让服务在它节流之前运行，但是依然会遇到cpu限流，这就意味着延迟增高和性能下降。
在10毫秒：
在17毫秒：
Worker1需要精确到需要5毫秒来响应请求，并完全用完这5毫秒是不现实的。如果很快就完成请求会发生什么呢？
在30毫秒：
在36毫秒：
在41毫秒：
在49毫秒：
-if(cfs_rq->runtime_expires!=cfs_b->runtime_expires){+if(cfs_rq->expires_seq==cfs_b->expires_seq){/*延长本地期限，漂移以2个滴答为界*/cfs_rq->runtime_expires+=TICK_NSEC;}else{/*全局截止日期提前，过期已过*/cfs_rq->runtime_remaining=0;}
修改问题5.4+主线内核的一部分。它们已被反向移植到许多可用的内核中：
如果使用的Linux发行版的内核版本低于4.19，建议使用aliyun2最新版或升级到最新版本的内核