约束 GOMAXPROCS 带来的收益

The Go Programming Language

› http://golang.org/

› Go Playground

Go Projects

› Revel Web Framework

This topic created in 1211 days ago, the information mentioned may be changed or developed.

最近看了一遍 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%

Supplement 1 · Jan 18, 2023

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

Supplement 2 · Jan 18, 2023

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

23 replies • 2023-02-09 10:30:38 +08:00

julyclyde

Jan 18, 2023

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

kiwi95

Jan 18, 2023 via Android

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

drealism

Jan 18, 2023

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

simple2025

Jan 18, 2023

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

GopherDaily

Jan 18, 2023

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

julyclyde

Jan 18, 2023

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

Maboroshii

Jan 18, 2023

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

GopherDaily

Jan 18, 2023

@loveuer 典型的 web 服务呗

GopherDaily

Jan 18, 2023

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

Aoang

Jan 18, 2023 via iPhone

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

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

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

Dreamacro

Jan 18, 2023 via iPad

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

GopherDaily

Jan 18, 2023

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

GopherDaily

Jan 18, 2023

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

hopingtop

Jan 19, 2023

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

hopingtop

Jan 19, 2023

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

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

GopherDaily

Jan 19, 2023

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

liuxu

Jan 19, 2023

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

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

GopherDaily

Jan 19, 2023

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

liuxu

Jan 19, 2023

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

GopherDaily

Jan 19, 2023

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

eudore

Jan 22, 2023

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

paceewang1

Feb 9, 2023

op 这用的是什么监控呢？

GopherDaily

Feb 9, 2023

@paceewang1 prometheus+grafana