docker容器环境go程序的GOMAXPROCS问题

最新推荐文章于 2024-03-22 09:36:00 发布
最新推荐文章于 2024-03-22 09:36:00 发布
阅读量627 收藏 1
点赞数
文章标签： docker golang 容器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/NUCEMLS/article/details/132528994
版权

1、前言

随着docker和kubernetes的普及，越来越多的服务选择了容器化部署，这当然包含了一部分go语言程序，而go程序的GOMAXPROCS在容器环境需要特别关注。

2、GOMAXPROCS

2.1 GMP模型

go使用GMP调度模型，其中G对应goroutine，M对应操作系统线程（OS Thread），P是Processor的缩写，代表一个虚拟的处理器。每个P维护一个本地G队列，go调度器也维护了一个全局的G队列，可以通过CAS的方式无锁访问，工作线程M优先使用自己的局部运行队列中的G，只有必要时才会去访问全局G队列，每个G要想真正运行起来，首先需要被分配一个P。P的数量可以通过GOMAXPROCS函数设置。

在这里插入图片描述

2.2 如何设置和获取P的数量？

可以借助runtime包下的GOMAXPROCS函数设置和读取P的数量，以go@v1.17.1为例，GOMAXPROCS函数源码如下：

// go/src/runtime/debug.go
func GOMAXPROCS(n int) int {
    if GOARCH == "wasm" && n > 1 {
        n = 1 // WebAssembly has no threads yet, so only one CPU is possible.
    }

    lock(&sched.lock)
    ret := int(gomaxprocs)
    unlock(&sched.lock)
    if n <= 0 || n == ret {
        return ret
    }

    stopTheWorldGC("GOMAXPROCS")

    // newprocs will be processed by startTheWorld
    newprocs = int32(n)

    startTheWorldGC()
    return ret
}

通过上面代码可以看出，一般情况下，GOMAXPROCS函数入参小于1时，不会修改P的数量，因此可用入参0来获取P的数量；如果想设置P的数量，则传入一个大于或等于1的数即可。

package main

import (
    "fmt"
    "runtime"
)

func main() {
    // 获取当前P的数量
    fmt.Println(runtime.GOMAXPROCS(0))

    // 设置P的数量
    runtime.GOMAXPROCS(4)
    
    // ...
}

2.3 默认P的数量

从v1.5版本起，go程序启动的时候会默认把P的数量设置为CPU数量，例如一个go程序跑在2C4G的虚拟机或者物理机上，则P的数量默认为2。

我们以v1.17.1为例，从go源码上稍微追踪下这段逻辑。在go/src/runtime/proc.go的schedinit调度器初始化函数前有如下注释：

// go/src/runtime/proc.go
// The bootstrap sequence is:
//
//    call osinit
//    call schedinit
//    make & queue new G
//    call runtime·mstart
//
// The new G calls runtime·main.

说明了在main函数前bootstrap会做osinit、schedinit等流程，P的数量也是在这些流程中初始化的。

2.3.1 osinit

假设操作系统是linux，osinit相关流程如下：

// go/src/runtime/runtime2.go
var (
    gomaxprocs int32
    ncpu       int32
    /*...*/
    newprocs   int32
)

// go/src/runtime/os_linux.go
func osinit() {
    ncpu = getproccount()
    /*...*/
}

// go/src/runtime/os_linux.go
func getproccount() int32 {
    // This buffer is huge (8 kB) but we are on the system stack
    // and there should be plenty of space (64 kB).
    // Also this is a leaf, so we're not holding up the memory for long.
    // See golang.org/issue/11823.
    // The suggested behavior here is to keep trying with ever-larger
    // buffers, but we don't have a dynamic memory allocator at the
    // moment, so that's a bit tricky and seems like overkill.
    const maxCPUs = 64 * 1024
    var buf [maxCPUs / 8]byte
    // 核心逻辑是sched_getaffinity函数
    r := sched_getaffinity(0, unsafe.Sizeof(buf), &buf[0])
    if r < 0 {
        return 1
    }
    n := int32(0)
    for _, v := range buf[:r] {
        for v != 0 {
            n += int32(v & 1)
            v >>= 1
        }
    }
    if n == 0 {
        n = 1
    }
    return n
}

//go:noescape
// noescape的作用就是禁止逃逸，指定文件中的下一个声明必须是不带主题的func(意味着该声明的实现不是用Go编写的)，不允许将作为参数传递的任何指针逃逸到堆或函数的返回值上
func sched_getaffinity(pid, len uintptr, buf *byte) int32

sched_getaffinity是【获取操作系统cpu亲和性】的方法 ，该方法的详细信息可在linux上执行man sched_getaffinity查看，一般情况下CPU不会对进程做特殊限制，因此这里也就可以获取操作系统层面的CPU数量。

2.3.2 schedinit

再来看看schedinit相关逻辑：

// go/src/runtime/proc.go
// The bootstrap sequence is:
//
//    call osinit
//    call schedinit
//    make & queue new G
//    call runtime·mstart
//
// The new G calls runtime·main.
func schedinit() {
    /*...*/
    procs := ncpu
    if n, ok := atoi32(gogetenv("GOMAXPROCS")); ok && n > 0 {
        procs = n
    }
    if procresize(procs) != nil {
        throw("unknown runnable goroutine during bootstrap")
    }
    /*...*/
}

// go/src/runtime/proc.go
func procresize(nprocs int32) *p {
    /*...*/
    old := gomaxprocs
    
    /*...*/
    
    // 初始化P的数量
    // initialize new P's
    for i := old; i < nprocs; i++ {
        pp := allp[i]
        if pp == nil {
            pp = new(p)
        }
        pp.init(i)
        atomicstorep(unsafe.Pointer(&allp[i]), unsafe.Pointer(pp))
    }
    
    /*...*/
    
    // 销毁多余的P
    // release resources from unused P's
    for i := nprocs; i < old; i++ {
        p := allp[i]
        p.destroy()
        // can't free P itself because it can be referenced by an M in syscall
    }
    
    /*...*/
    
    var int32p *int32 = &gomaxprocs // make compiler check that gomaxprocs is an int32
    atomic.Store((*uint32)(unsafe.Pointer(int32p)), uint32(nprocs))
    return runnablePs
}

前面提到osinit是在schedinit前执行，而osinit已经把全局变量ncpu设置为了操作系统cpu数，因此上面schedinit代码中通过procresize函数把ncpu的值作为P的数量，并设置到全局变量gomaxprocs中，从而完成了GOMAXPROCS的初始化。

2.4 再看GOMAXPROCS函数

2.4.1 获取P的数量

在上面GOMAXPROCS函数源码中可以看出，当入参传入0时，返回的实际上是一个全局变量gomaxprocs，这个变量就是schedinit设置的ncpu，也就是osinit过程获取到的操作系统层面的cpu数量值。

2.4.2 设置P的数量

假设有机器的cpu是8，程序中有设置P数量为4的代码：

runtime.GOMAXPROCS(4)

经过osinit和schedinit后，全局变量ncpu和gomaxprocs的值都是8，于是GOMAXPROCS函数会走如下逻辑：

// go/src/runtime/debug.go
// n = 4
func GOMAXPROCS(n int) int {
    /*...*/
    
    // n = 4
    newprocs = int32(n)
    
    startTheWorldGC()
    return ret
}

// go/src/runtime/proc.go
func startTheWorldGC() {
    startTheWorld()
    /*...*/
}

// go/src/runtime/proc.go
func startTheWorld() {
    systemstack(func() { startTheWorldWithSema(false) })
    /*...*/
}

// go/src/runtime/proc.go
func startTheWorldWithSema(emitTraceEvent bool) int64 {
    /*...*/
    
    procs := gomaxprocs
    if newprocs != 0 {
        procs = newprocs
        newprocs = 0
    }
    p1 := procresize(procs)
    
    /*...*/
}

procresize函数在schedinit中也有调用，传入的procs = 4，小于之前的8，所以在procresize函数内部会走这段逻辑，从而达到了设置P数量的目的：

// go/src/runtime/proc.go
func procresize(nprocs int32) *p {
    /*...*/
    // 销毁多余的P
    // release resources from unused P's
    for i := nprocs; i < old; i++ {
        p := allp[i]
        p.destroy()
        // can't free P itself because it can be referenced by an M in syscall
    }
    /*...*/

docker容器环境

在2.3.1 osinit章节中，我们强调了 sched_getaffinity是【获取操作系统cpu亲和性】的方法 ，但是对于docker容器，它是共享宿主机操作系统内核的，因此docker容器下的go程序会初始化P的数量为宿主机cpu数量。

但是在kubernetes集群中，通常宿主机的cpu都会比较大，有的甚至有100+c，而go程序业务通常需要很小规格即可，例如2c4g。假设一个go程序pod容器的request配置了2c4g，而部署到了一个120c的宿主机上，go程序默认会起120个P，但是cgroup限制了go程序只有2c4g的资源，这很可能会因P数量过多导致不必要的资源争抢，反而降低性能。

3、docker容器环境中如何正确设置P的数量

通过前面的分析，docker环境go程序P数量设置过大的原因是go初始化时获取的宿主机cpu与cgroup中数值不一致，我们可以用uber的automaxprocs包把GOMAXPROCS设置为cgroup中cpu数：

package main

import _ "go.uber.org/automaxprocs"

func main() {
  /*...*/
}

来看看uber这个包是怎么实现的：

// go.uber.org/automaxprocs/automaxprocs.go
import (
    "log"
    
    "go.uber.org/automaxprocs/maxprocs"
)

func init() {
    maxprocs.Set(maxprocs.Logger(log.Printf))
}

// go.uber.org/automaxprocs/maxprocs/maxprocs.go
func Set(opts ...Option) (func(), error) {
    cfg := &config{
        procs:         iruntime.CPUQuotaToGOMAXPROCS,
        minGOMAXPROCS: 1,
    }
    
    maxProcs, status, err := cfg.procs(cfg.minGOMAXPROCS)
    if err != nil {
        return undoNoop, err
    }
    
    /*...*/
    
    runtime.GOMAXPROCS(maxProcs)
    return undo, nil
}

// go.uber.org/automaxprocs/internal/runtime/cpu_quota_linux.go
func CPUQuotaToGOMAXPROCS(minValue int) (int, CPUQuotaStatus, error) {
    cgroups, err := newQueryer()
    if err != nil {
        return -1, CPUQuotaUndefined, err
    }

    quota, defined, err := cgroups.CPUQuota()
    if !defined || err != nil {
        return -1, CPUQuotaUndefined, err
    }

    maxProcs := int(math.Floor(quota))
    if minValue > 0 && maxProcs < minValue {
        return minValue, CPUQuotaMinUsed, nil
    }
    return maxProcs, CPUQuotaUsed, nil
}

// go.uber.org/automaxprocs/internal/runtime/cpu_quota_linux.go
func newQueryer() (queryer, error) {
    // 先查询cgroup v2
    cgroups, err := _newCgroups2()
    if err == nil {
        return cgroups, nil
    }
    // 再查cgroups v1
    if errors.Is(err, cg.ErrNotV2) {
        return _newCgroups()
    }
    return nil, err
}

// go.uber.org/automaxprocs/internal/cgroup/cgroups2.go
// cgroups v2
func (cg *CGroups2) CPUQuota() (float64, bool, error) {
    cpuMaxParams, err := os.Open(path.Join(cg.mountPoint, cg.groupPath, cg.cpuMaxFile))
    if err != nil {
        if os.IsNotExist(err) {
            return -1, false, nil
        }
        return -1, false, err
    }
    defer cpuMaxParams.Close()

    scanner := bufio.NewScanner(cpuMaxParams)
    if scanner.Scan() {
        fields := strings.Fields(scanner.Text())
        if len(fields) == 0 || len(fields) > 2 {
            return -1, false, fmt.Errorf("invalid format")
        }

        if fields[_cgroupv2CPUMaxQuotaIndex] == _cgroupV2CPUMaxQuotaMax {
            return -1, false, nil
        }

        max, err := strconv.Atoi(fields[_cgroupv2CPUMaxQuotaIndex])
        if err != nil {
            return -1, false, err
        }

        var period int
        if len(fields) == 1 {
            period = _cgroupV2CPUMaxDefaultPeriod
        } else {
            period, err = strconv.Atoi(fields[_cgroupv2CPUMaxPeriodIndex])
            if err != nil {
                return -1, false, err
            }

            if period == 0 {
                return -1, false, errors.New("zero value for period is not allowed")
            }
        }

        return float64(max) / float64(period), true, nil
    }

    if err := scanner.Err(); err != nil {
        return -1, false, err
    }

    return 0, false, io.ErrUnexpectedEOF
}

从代码可以看出，uber的automaxprocs包会去读进程cgroups（先找cgroups v2，如果没找到再找cgroups v1）中cpu相关数据，最后通过runtime.GOMAXPROCS设置P的数量为cgroup中cpu对应值，从而解决docker容器环境go程序默认设置P的数量为宿主机cpu数量的问题。

微信公众号卡巴斯同步发布，欢迎大家关注。

nuczzz
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
docker 容器上编译 go 程序提示找不到文件问题
09-30
主要介绍了docker 容器上编译 go 程序无法运行提示找不到文件问题，解决方法也很简单，感兴趣的朋友跟随脚本之家小编一起看看吧
在容器里设置GOMAXPROCS的正确姿势
kevin_tech的博客，微信搜「网管叨bi叨」
05-30 1624
GOMAXPROCS 是 Go 提供的非常重要的一个环境变量。通过设定 GOMAXPROCS，用户可以调整调度器中 Processor（简称P）的数量。由于每个系统线程必须要绑定 P ，P...
Golang runtime运行时
Tony10010的博客
02-24 492
NumCPU NumGoroutine GOOS func runtimeInfo() { runtime.GOMAXPROCS(1) fmt.Println(runtime.NumCPU()) // 返回当前cpu核心数 fmt.Println(runtime.NumGoroutine()) // 返回正在执行和排队的任务数 fmt.Println(runtime.GOOS) // 返回当前操作系统 } Gosched func runtimeGosched() {
探索 Uber 的 `automaxprocs`：自动调整 Golang 进程数的利器
最新发布
gitblog_00006的博客
03-22 311
探索 Uber 的 automaxprocs：自动调整 Golang 进程数的利器 项目地址:https://gitcode.com/uber-go/automaxprocs 在 Go 语言的世界中，处理并发是其一大特色，而进程（goroutines）的数量管理对性能有着直接影响。Uber 开源了一个名为 automaxprocs 的库，它能自动化地根据系统资源动态调整 Golang 程序中的 G...
automaxprocs：自动设置GOMAXPROCS以匹配Linux容器CPU配额
02-04
automaxprocs 自动设置GOMAXPROCS以匹配Linux容器CPU配额。 安装 go get -u go.uber.org/automaxprocs 快速开始 import _ "go.uber.org/automaxprocs" func main () { // Your application logic here. } 发展状况：稳定 所有API均已定稿，在1.x系列发行版中不会进行重大更改。 支持semver的依赖管理系统的用户应将automaxprocs固定为^1 。 贡献 我们鼓励并支持一个活跃，健康的贡献者社区-包括您在内！ 详细信息在和。 automax
Go语言GOMAXPROCS（调整并发的运行性能）
xyz的专栏
09-05 378
在 Go语言程序运行时（runtime）实现了一个小型的任务调度器。这套调度器的工作原理类似于操作系统调度线程，Go 程序调度器可以高效地将 CPU 资源分配给每一个任务。传统逻辑中，开发者需要维护线程池中线程与 CPU 核心数量的对应关系。同样的，Go 地中也可以通过 runtime.GOMAXPROCS() 函数做到，格式为： runtime.GOMAXPROCS(逻辑CPU数量) 这里的逻辑CPU数量可以有如下几种数值： <1：不修改任何数值。 =1：单核心执行。 >1：多核并发
Go 语言编程 — 性能分析
烟云的计算
07-17 2174
目录 文章目录目录ProfilingruntimeMemStatGCpproftraceDEBUG Profiling Golang 提供了友好的工程化支持，其中之一就是 Profiling（分析）工具。例如：Golang 自带的 runtime 包，就可以轻松获取程序运行期间的各种内存或 CPU 的使用状态信息。 runtime MemStat 查看内存使用情况： package main import ( "fmt" "runtime" ) func main() { var m runtim
GOMAXPROCS含义与用法
pirlo-san的博客
03-04 3454
1 含义 Go调度器（scheduler）用来决定Go例程最多可以在多少个线程上执行，在m:n调度机制里面，GOMAXPROCS就是那个n。 2 默认值 操作系统CPU数 3 哪些任务不需要占用线程 sleeping的Go例程 由于通信阻塞的Go例程 4 哪些任务需要占用线程 阻塞在I/O或其他系统调用的Go例程 调用非Go函数的例程，如CGO 一般的活跃Go例程 其中，前两种任务虽然占用...
关于GOMAXPROCS的设置
马拉松PB
04-01 6301
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队列里获取任务。先前的阻塞的线程会被游离出去了，当他完成阻塞操作后会触发
golang常用库之-go.uber.org/automaxprocs包 | 容器里如何获取真正可使用的CPU核心数
西京刀客
10-03 1825
GOMAXPROCS 在 Go 1.5 版本后的默认值是机器的 CPU 核数 （runtime.NumCPU）。而以 Docker 为代表的容器虚拟化技术，会通过 cgroup 等技术对 CPU 资源进行隔离。这类技术对 CPU 的隔离限制，导致 runtime.NumCPU() 无法正确获取到容器被分配的 CPU 资源数。
Golang之runtime三大函数Gosched、Goexit、GOMAXPROCS使用规则
weixin_52690231的博客
04-22 1191
Golang之runtime三大函数Gosched、Goexit、GOMAXPROCS使用规则
vscode-golang-docker:在Docker容器内进行开发环境
05-12
vscode-golang-docker是Docker容器内的Go开发环境。 它由Visual Studio Code和各种扩展组成，可帮助您编写，构建，测试和调试Go应用程序。 它还将通过使用linters和其他支持工具来帮助您编写自己的shell脚本，...
在宿主机上执行docker容器内部的shell或程序方式
01-20
为了避免反复进入docker容器内部操作，可以将一系列容器内部的指令由宿主机来操作完成。 在宿主机（作者主机为windows7）上执行centos容器（name为centos-1）中/usr目录下的“printer”可执行程序，该程序输出为打印...
生产环境中安全运行Docker容器
09-30
本文是一篇译文，给大家详细介绍如何在生产环境中安全运行Docker容器，有需要的小伙伴可以参考下
Go gomaxprocs 调高引起调度性能损耗
梦醒人间
06-23 479
先前在社区里分享了关于 golang 行情推送[1]的分享，有人针对 ppt 的内容问了我两个问题，一个是在 docker 下 golang 的 gomaxprocs 初始化混乱问题，另一...
go语言学习笔记 — 并发编程 — 轻量级线程goroutine（3）：调整并发的运行性能（GOMAXPROCS）
yjk13703623757的博客
11-16 226
go语言的运行时(runtime)实现了一个小型任务调度器，它类似于操作系统的线程调度，可以高效地把CPU资源分配给每一个任务。通过runtime.GOMAXPROCS()函数，可以指定线程池中线程与CPU核心数量的对应关系，如下： runtime.GOMAXPROCS(主机逻辑CPU数量) 当主机逻辑CPU数量<1时，不修改任何值；主机逻辑CPU数量=1，单核心执行；主机逻辑CPU数量&...
基于Docker镜像部署go项目
青羽的专栏
09-19 7554
依赖知识 Go交叉编译基础 Docker基础 Dockerfile自定义镜像基础 docker-compose编排文件编写基础 当然，一点也不会也可以按照这个步骤部署完成，不过可能中间如果出点小问题，会不知道怎么解决，当然你也可以留言。 我是在mac环境上开发测试的，如果你是在windows上可能有一点出入，但应该不会有啥大问题。 一、依赖环境 Docker 二、编写一个GoLang we...
Golang cpu的使用设置--GOMAXPROCS
热门推荐
翔云
06-27 1万+
以下测试，使用的Go版本是1.8.3 不设置 如果没有调用runtime.GOMAXPROCS 去设置CPU，Golang默认使用所有的cpu核。 测试机器CPU有4个核，测试代码开启4个goroutine，从测试结果看4个核心全部跑满。 测试代码如下： package main func main() { go task() go task() go tas...
Golang runtime 包：runtime.GOMAXPROCS 用于设置同时运行的最大CPU核心数、runtime.Goexit() 退出当前协程、runtime.Gosched() 当前的代
wgchen
08-31 234
Golang runtime 包：runtime.GOMAXPROCS 用于设置同时运行的最大CPU核心数、runtime.Goexit() 退出当前协程、runtime.Gosched() 当前的代
docker容器环境
08-01
Docker容器环境是一种轻量级、可移植的容器，可以为应用程序提供一个独立的运行环境。配置Docker容器环境的步骤如下： 1. 在虚拟机上配置好Docker容器：可以从Docker Hub上拉取所需的环境镜像，例如Python 3.6和PyTorch 1.7。[1] 2. 创建Docker容器：使用命令`docker run -t -i 镜像名:镜像版本 -v 服务器路径:容器路径 /bin/bash`在虚拟机上创建容器。[3] 3. 在容器中安装所需的环境：根据模型源码的requirements.txt文件，使用命令`pip install xxx`安装所需的环境。[3] 4. 将容器压缩到Windows桌面：将容器导出为镜像，并保存为压缩包。然后通过Xftp等文件传输软件将压缩文件传输到服务器上。[1] 5. 在服务器上解压镜像并创建容器：使用命令`docker load -i 路径/镜像名.tar`将镜像导入服务器，然后使用命令`docker run -t -i 镜像名:镜像版本 -v 服务器路径:容器路径 /bin/bash`创建相应的容器。[3] 通过以上步骤，您可以成功配置Docker容器环境。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值