约束 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%

GMP 中的 M 和 P 数量多了之后，主要的成本在于：
- go scheduler 的调度成本
- go gc 的成本
- os thread 切换的成本，默认 GOMAXPROCS 等同于 CPU 就是为了尽量一个 M 一个 C ，避免上下文切换

https://github.com/j2gg0s/j2gg0s/blob/main/20230118_go_%E7%BA%A6%E6%9D%9FGOMAXPROCS%E5%B8%A6%E6%9D%A5%E7%9A%84%E6%94%B6%E7%9B%8A.md

GOMAXPROCS 限制了用来并发执行代码的系统线程数量, 默认等于 CPU 的数量. 使用 CPU 做为 GOMAXPROCS 的默认值, 是为了平衡执行效率和调度成本. 我们即希望有尽可能多的线程来提高并行程度, 又不希望系统线程被频繁的切换. 所以在假设基本独占机器资源的前提下, 我们选择 CPU 的数量做为默认的线程数量.

当我们的代码运行在 k8s 中, 基本面发生了一些改变. 一方面, 几十个应用共享一个宿主机(Node); 另一方面 Go 直接使用宿主机的 CPU 数量做为 GOMAXPROCS 的默认值. 于是出现了一些类似, 应用假设的 CPU 数量是 1, 但是默认创建了 64 个线程的情况.

这种 k8s 下的默认行为是否合理, 我们很难直接从代码中得出一个结论. 通过控制变量的方式来观察结果似一个不错的选择

[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 中，所以可能还是可以揣测下

[eudore]

没配置对，uber 有个库就可以根据 limit 去设置 maxprocs ，jvm 也有相识的内置参数。

[paceewang1]

op 这用的是什么监控呢？

[GopherDaily]

@paceewang1 prometheus+grafana