这是一个创建于 709 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近看了一遍 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%
第 1 条附言 · 2023-01-18 17:12:00 +08:00
GMP 中的 M 和 P 数量多了之后，主要的成本在于：
- go scheduler 的调度成本
- go gc 的成本
- os thread 切换的成本，默认 GOMAXPROCS 等同于 CPU 就是为了尽量一个 M 一个 C ，避免上下文切换
- go scheduler 的调度成本
- go gc 的成本
- os thread 切换的成本，默认 GOMAXPROCS 等同于 CPU 就是为了尽量一个 M 一个 C ，避免上下文切换
第 2 条附言 · 2023-01-18 17:18:11 +08:00
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 下的默认行为是否合理, 我们很难直接从代码中得出一个结论. 通过控制变量的方式来观察结果似一个不错的选择
GOMAXPROCS 限制了用来并发执行代码的系统线程数量, 默认等于 CPU 的数量. 使用 CPU 做为 GOMAXPROCS 的默认值, 是为了平衡执行效率和调度成本. 我们即希望有尽可能多的线程来提高并行程度, 又不希望系统线程被频繁的切换. 所以在假设基本独占机器资源的前提下, 我们选择 CPU 的数量做为默认的线程数量.
当我们的代码运行在 k8s 中, 基本面发生了一些改变. 一方面, 几十个应用共享一个宿主机(Node); 另一方面 Go 直接使用宿主机的 CPU 数量做为 GOMAXPROCS 的默认值. 于是出现了一些类似, 应用假设的 CPU 数量是 1, 但是默认创建了 64 个线程的情况.
这种 k8s 下的默认行为是否合理, 我们很难直接从代码中得出一个结论. 通过控制变量的方式来观察结果似一个不错的选择
23 条回复 • 2023-02-09 10:30:38 +08:00
 |
1
julyclyde 2023-01-18 16:48:13 +08:00
那就需要分析一下原因了
降低并发度之后反而提高了处理能力，说明并发的时候内耗比较大？ |
 |
2
kiwi95 2023-01-18 16:51:41 +08:00 via Android
说明当前场景下并发调度开销比较大？
|
 |
3
loveuer 2023-01-18 16:52:12 +08:00
可以细说一下主要啥类型的业务么🧐
|
 |
4
chenqh 2023-01-18 16:55:33 +08:00
你这是 k8s 吧,golang 这种不应该是一个进程吃满的吗,又不是 python 那种
|
 |
5
GopherDaily OP @julyclyde go scheduler 调度的成本，和 os thread 上下文切换的成本
|
|
6
julyclyde 2023-01-18 17:13:52 +08:00
是容器运行吗？
runtime.NumCPU()和容器的核数是否一致？ |
 |
7
Maboroshii 2023-01-18 17:15:06 +08:00
k8s node 上还有其他 pod 吧，都想吃满机器 ，肯定有反效果
|
|
8
GopherDaily OP @loveuer 典型的 web 服务呗
|
|
9
GopherDaily OP @Maboroshii pod 是坑定有的，吃满不至于，我们一般是控制实际使用率在 40%以内，突然的情况下会到 60%
|
 |
10
Aoang 2023-01-18 21:24:25 +08:00 via iPhone
要压榨单机性能最好就别用 k8s (:
个人实践，丢在 k8s 上的东西都是无状态的应用，开了自动扩缩容其他的就不需要操心了。 对于有状态或者需要压榨单机性能的，例如数据库都不在 k8s 内。 另，试着升下版本，GOGC 和 GOMEMLIMIT 还能对程序有进一步的提升。 |
 |
11
Dreamacro 2023-01-18 22:47:31 +08:00 via iPad
|
|
12
GopherDaily OP @Aoang 自然，但是资源能节约要节约，成本核算都是 OKR
|
|
13
GopherDaily OP @Dreamacro CI/CD 里面直接注入环境变量也行，可控性更高
|
 |
14
hopingtop 2023-01-19 09:39:27 +08:00
针对 Docker 运行 Go 确实有取宿主机的 CPU 来设置 MAXPROCS.
当使用 Pod 限制资源的配置时，就不建议手动去调整 MAXPROCS ， 这样做不好运维，所以可以选择 Uber 的一个库 |
|
15
hopingtop 2023-01-19 09:43:21 +08:00
@hopingtop
https://github.com/uber-go/automaxprocs 这库的原理就是取读取 容器里 /sys/fs/cgroup/cpu 里面的值，然后计算出一个合理的 MAXPROCS 在你 main 函数执行之前通过 import 这个过程去初始化 MAXPROCS |
|
16
GopherDaily OP @hopingtop 你是站在业务开发的角度来看
|
 |
17
liuxu 2023-01-19 12:07:03 +08:00
嗯，k8s 里面进程数是要手动设置下，除非单 pod ，不然 pod 自动扩展物理机进程数 X^n 上升
物理机和 k8s 还是有很多细微的差别要处理 |
|
18
GopherDaily OP @liuxu 一直还没去关注，k8s/vm 分配 cpu 时间片的时候会不会主动尽量将单个 pod 聚集到某个 物理 c 上
|
|
19
liuxu 2023-01-19 14:24:47 +08:00
@GopherDaily 物理 C 是物理 node 还是物理 cpu core ，前者可以用 statefulset 、node selector 和 affility 处理，后者 k8s 没有这个能力也不应该有这个能力
|
|
20
GopherDaily OP @liuxu 真实的、物理的 CPU
情理上我也觉得 k8s 没有这个能力，但是 resources limit 也在 pod spec 中，所以可能还是可以揣测下 |
 |
21
eudore 2023-01-22 23:34:39 +08:00
没配置对，uber 有个库就可以根据 limit 去设置 maxprocs ，jvm 也有相识的内置参数。
|
 |
22
paceewang1 2023-02-09 09:50:35 +08:00
op 这用的是什么监控呢？
|
|
23
GopherDaily OP @paceewang1 prometheus+grafana
|
Select Language