关于GOMAXPROCS的设置

G-P-M模型

我们知道在Go scheduler中,G代表goroutine, P代表Logical Processor, M是操作系统线程。在绝大多数时候,其实P的数量和M的数量是相等。 每创建一个p, 就会创建一个对应的M
只有少数情况下,M的数量会大于P

golang runtime是有个sysmon的协程,他会轮询的检测所有的P上下文队列,只要 G-M 的线程长时间在阻塞状态,那么就重新创建一个线程去从runtime P队列里获取任务。先前的阻塞的线程会被游离出去了,当他完成阻塞操作后会触发相关的callback回调,并加入回线程组里。简单说,如果你没有特意配置runtime.SetMaxThreads,那么在没有可复用的线程的情况下,会一直创建新线程。

GOMAXPROCS的取值

我们知道可以通过runtime.GOMAXPROCS()来了设定P的值

Go 1.5开始, Go的GOMAXPROCS默认值已经设置为 CPU的核数, 这允许我们的Go程序充分使用机器的每一个CPU,最大程度的提高我们程序的并发性能。

但其实对于IO密集型的场景,我们可以把GOMAXPROCS的值超过CPU核数,在笔者维护的某个服务中,将GOMAXPROCS设为CPU核数的2倍,压测结果表明,吞吐能力大概能提升10%

容器中

在容器中,Golang程序获取的是宿主机的CPU核数导致GOMAXPROCS设置的过大。比如在笔者的服务中,宿主机是48cores,而实际container只有4cores。
线程过多,会增加上线文切换的负担,白白浪费CPU。
uber-go/automaxprocs 可以解决这个问题

package main

import (
    "fmt"
    _ "go.uber.org/automaxprocs"
    "runtime"
)

func main() {
    fmt.Println("real GOMAXPROCS", runtime.GOMAXPROCS(-1))
}

go build出的二进制文件,在docker中启动后,会报如下DEBUG信息。

maxprocs: Leaving GOMAXPROCS=12: CPU quota undefined

解决办法:

在项目中引用go.uber.org/automaxprocs,同时在docker run设置启动参数–cpu=1。

另外也可以通过设置环境变量GOMAXPROCS来改变Golang程序的GOMAXPROCS默认值

你可能感兴趣的:(Golang,docker,开发语言)