约束 GOMAXPROCS 带来的收益

[GopherDaily]

最近看了一遍 runtime ，去尝试了之前遗留的一个工作：调整 k8s 中容器的 GOMAXPROCS ，效果还不错。

在 11:35 左右, 我们将应用的 GOMAXPROCS 从默认的 32/64 主动设置为 4, 对比 14:30 和 11:30 的数据可以看到:

• go version: 1.17
• 线程数量从 49 下降到 13, 符合预期
• 受业务影响, QPS +13%
• 接口平均响应时间 -9%, CPU -5%
• GC 的耗时 -59%, STW(StopTheWorld) 的时间 -12%
• goroutine 在 Runnable 停留的时间 +50%

[julyclyde]

那就需要分析一下原因了
降低并发度之后反而提高了处理能力，说明并发的时候内耗比较大？

[kiwi95]

说明当前场景下并发调度开销比较大？

[loveuer]

可以细说一下主要啥类型的业务么🧐

[chenqh]

你这是 k8s 吧,golang 这种不应该是一个进程吃满的吗,又不是 python 那种

[GopherDaily]

@julyclyde go scheduler 调度的成本，和 os thread 上下文切换的成本

[julyclyde]

是容器运行吗？
runtime.NumCPU()和容器的核数是否一致？

[Maboroshii]

k8s node 上还有其他 pod 吧，都想吃满机器 ，肯定有反效果

[GopherDaily]

@loveuer 典型的 web 服务呗

[GopherDaily]

@Maboroshii pod 是坑定有的，吃满不至于，我们一般是控制实际使用率在 40%以内，突然的情况下会到 60%

[Aoang]

要压榨单机性能最好就别用 k8s (:

个人实践，丢在 k8s 上的东西都是无状态的应用，开了自动扩缩容其他的就不需要操心了。
对于有状态或者需要压榨单机性能的，例如数据库都不在 k8s 内。

另，试着升下版本，GOGC 和 GOMEMLIMIT 还能对程序有进一步的提升。

[Dreamacro]

https://github.com/uber-go/automaxprocs

[GopherDaily]

@Aoang 自然，但是资源能节约要节约，成本核算都是 OKR

[GopherDaily]

@Dreamacro CI/CD 里面直接注入环境变量也行，可控性更高

[hopingtop]

针对 Docker 运行 Go 确实有取宿主机的 CPU 来设置 MAXPROCS.
当使用 Pod 限制资源的配置时，就不建议手动去调整 MAXPROCS ， 这样做不好运维，所以可以选择 Uber 的一个库

[hopingtop]

@hopingtop
https://github.com/uber-go/automaxprocs

这库的原理就是取读取 容器里 /sys/fs/cgroup/cpu 里面的值，然后计算出一个合理的 MAXPROCS
在你 main 函数执行之前通过 import 这个过程去初始化 MAXPROCS

[GopherDaily]

@hopingtop 你是站在业务开发的角度来看

[liuxu]

嗯，k8s 里面进程数是要手动设置下，除非单 pod ，不然 pod 自动扩展物理机进程数 X^n 上升

物理机和 k8s 还是有很多细微的差别要处理

[GopherDaily]

@liuxu 一直还没去关注，k8s/vm 分配 cpu 时间片的时候会不会主动尽量将单个 pod 聚集到某个 物理 c 上

[liuxu]

@GopherDaily 物理 C 是物理 node 还是物理 cpu core ，前者可以用 statefulset 、node selector 和 affility 处理，后者 k8s 没有这个能力也不应该有这个能力

[GopherDaily]

@liuxu 真实的、物理的 CPU
情理上我也觉得 k8s 没有这个能力，但是 resources limit 也在 pod spec 中，所以可能还是可以揣测下