前情
我们的技术总监在我写广告合并请求的业务时, 和我说了一句现在的服务是不是都是运行在0.5核的节点上, 需要注意设置一下参数
然后我回去看了一下, 我们的golang部分服务是运行在k8s上0.5核的...pod, 然后跑在多台8核的物理节点上
然后程序中可以通过以下命令打印出当前的GOMAXPROCS, 服务虽然运行在pod上,但打印的是实际的宿主机的核心数
package main
import (...fmt.Printf("当前: %d", runtime.GOMAXPROCS(0))
// 8
}
先说解决方案, 直接使用https://github.com/uber-go/automaxprocs这个库获取到实际的核心数...简单的来说, 就是本身容器只有0.5核, 但是却设置了GOMAXPROCS=8, 导致会创建出8个P, 每个P由不同的M管理
所以当GOMAXPROCS大于核心数量的时候, 会导致线程不断的切换, 然后...,但是我们只有一个P,也获取失败, 就会把G0放到全局队列中, 等待P1之后获取
3.png
PS
网络io不会造成阻塞, 因为golang在网络请求时,其后台通过kqueue(MacOS),epoll