百度一下Go语言优势,几乎所有文章都包含并发性好,作为一名老PHPer,一番学习实践下来,真香。
在当今这个多核时代,并发编程的意义不言而喻。当然,很多语言都支持多线程、多进程编程,但遗憾的是,实现和控制起来并不是那么令人感觉轻松和愉悦。Golang不同的是,语言级别支持协程(goroutine)并发(协程又称微线程,比线程更轻量、开销更小,性能更高),操作起来非常简单,语言级别提供关键字(go)用于启动协程,并且在同一台机器上可以启动成千上万个协程。
不管作为初学者还是久经沙场的老Gopher,Golang的协程调度器原理及 GMP 设计思想都是有必要去掌握的,而且面试必问:),推荐阅读丹冰大佬的 Golang修养之路GMP章节,图文并茂非常Nice。想深入学习的推荐欧神的 并发调度,结合源码和流程图讲解,膜拜。本文结束?Too young too simple,真正的重头戏才刚刚开始。
G 的数量:
无限制,理论上受内存的影响,创建一个 G 的初始栈大小为2-4K,配置一般的机器也能简简单单开启数十万个 Goroutine ,而且Go语言在 G 退出的时候还会把 G 清理之后放到 P 本地或者全局的闲置列表 gFree 中以便复用。
那是不是为了提高“并发能力”,就可以为所欲为的开启 Goroutine 呢,答案是否定的。
如果 Goroutine 中只有简单的逻辑,比如输出Hello world:),那肯定是没什么问题,但是如果Goroutine 中存在频繁请求 HTTP,MySQL,打开文件等,那假设短时间内有几十万个协程在跑,那肯定就不大合理了(可能会导致 too many files open)。常见的 Goroutine 泄露所导致的 CPU、Memory 上涨等,所以还是得看你的 Goroutine 里具体在跑什么东西。
一开始写 GO ,不管多大数据处理全部丢进去进行循环,认为全部都并发使用 Goroutine 去做一件事情,效率比较高,但这样的话,噩梦般的事情就开始了,服务器系统资源利用率不断上涨,到最后程序自动killed。这里比较好的解决方案是,引入线程池,限制 Goroutine 的数量,复用资源,保障系统稳定的同时提高处理能力。避免重复造轮子,推荐使用 ants,源码也不多可以学习学习,亲测好用- -
M 的数量:
限制10000,Go语言运行时初始化的时候在runtime.schedinit()中通过下面代码设置了 M 的最大数。
sched.maxmcount = 10000
通过debug.SetMaxThreads(n),可以调整。如果超出(手动调成10)会panic:
runtime: program exceeds 10-thread limit
fatal error: thread exhaustion
因为 M 必须持有 P 才能运行 G,通常情况 P 的数量很有限,如果 M 还超过 10000,基本上就是程序写的有问题。
P 的数量:
有限制,默认是CPU核心数,由启动时环境变量$GOMAXPROCS或者是由runtime.GOMAXPROCS()决定,runtime初始化建议阅读煎鱼大佬的 详解 Go 程序的启动流程,你知道 g0,m0 是什么吗?,以及 Go语言调度器之创建main goroutine
func schedinit() {
...
procs := ncpu // osinit 中获取 CPU 核心数
if n, ok := atoi32(gogetenv("GOMAXPROCS")); ok && n > 0 {
procs = n
}
// P 初始化
if procresize(procs) != nil {
throw("unknown runnable goroutine during bootstrap")
}
...
}
func GOMAXPROCS(n int) int {
...
stopTheWorldGC("GOMAXPROCS")
// newprocs will be processed by startTheWorld
newprocs = int32(n) // 重新设置的 P 数量
startTheWorldGC()
return ret
}
startTheWorldGC() -> startTheWorld() -> startTheWorldWithSema()
func startTheWorldWithSema(emitTraceEvent bool) int64 {
...
procs := gomaxprocs
if newprocs != 0 {
procs = newprocs
newprocs = 0
}
// 扩容或者缩容全局的处理器
p1 := procresize(procs)
...
}
在任何情况下,Go运行时并行执行(注意,不是并发)的 goroutines 数量是小于等于 P 的数量的。为了提高系统的性能,P 的数量肯定不是越小越好,所以官方默认值就是 CPU 的核心数,设置的过小的话,如果一个持有 P 的 M,由于 P 当前执行的 G 调用了 syscall 而导致 M 被阻塞,那么此时关键点:GO 的调度器是迟钝的,它很可能什么都没做,直到 M 阻塞了相当长时间以后,才会发现有一个 P/M 被 syscall 阻塞了。然后,才会用空闲的 M 来强这个 P。通过 sysmon 监控实现的抢占式调度,最快在20us,最慢在10-20ms才会发现有一个 M 持有 P 并阻塞了。操作系统在 1ms 内可以完成很多次线程调度(一般情况1ms可以完成几十次线程调度),Go 发起 IO/syscall 的时候执行该 G 的 M 会阻塞然后被OS调度走,P什么也不干,sysmon 最慢要10-20ms才能发现这个阻塞,说不定那时候阻塞已经结束了,宝贵的P资源就这么被阻塞的M浪费了。
补充说明:调度器迟钝不是 M 迟钝,M 也就是操作系统线程,是非常的敏感的,只要阻塞就会被操作系统调度(除了极少数自旋的情况)。但是 GO 的调度器会等待一个时间间隔才会行动,这也是为了减少调度器干预的次数。也就是说,如果一个 M 调用了什么 API 导致了操作系统线程阻塞了,操作系统立刻会把这个线程M调度走,挂起等阻塞解除。这时候,Go 调度器不会马上把这个 M 持有的 P 抢走。这就会导致一定的 P 被浪费了。
开源数据库项目https://github.com/dgraph-io/dgraph中,特意将 GOMAXPROCS 调整到 128 增加 IO 处理能力,提高吞吐量。
https://github.com/dgraph-io/dgraph/blob/master/dgraph/main.go
func main() {
rand.Seed(time.Now().UnixNano())
// Setting a higher number here allows more disk I/O calls to be scheduled, hence considerably
// improving throughput. The extra CPU overhead is almost negligible in comparison. The
// benchmark notes are located in badger-bench/randread.
runtime.GOMAXPROCS(128)
}
那 P 的数量太大会有什么影响呢?
一个runtime findrunnable 时产生的损耗,另一个是线程引起的上下文切换。如果是cpu密集的业务,增加多个processor也没用,毕竟cpu计算资源就这些,来回切换反而拖慢程序。
runtime的 findrunnable 方法是解决 M 找可用的协程的函数,当从绑定 P 本地runq上找不到可执行的goroutine后,尝试从全局链表中拿,再拿不到从 netpoll 和事件池里拿,最后会从别的 P 里偷任务。全局 runq 是有锁操作,其他偷任务使用了atomic 原子操作来规避futex竞争下陷入切换等待问题,但 lock free 在竞争下也会有忙轮询的状态,比如不断的尝试(自旋)。
随着调多 runtime processor 数量,相关的 M 线程自然也就跟着多了起来。linux 内核为了保证可执行的线程在调度上雨露均沾,按照内核调度算法来切换就绪状态的线程,切换又引起上下文切换。上下文切换也是性能的一大杀手。findrunnable 的某些锁竞争也会触发上下文切换。
结论:常规项目直接使用默认的核心数就好了,GOMAXPROCS 开太多的时候,针对计算密集型的处理性能提升反而没那么大,IO 密集(或者 syscall 较多)的 Go 程序,至少应该配置到CPU核心数目的5倍以上, 最大1024。
个人学习笔记,方便自己复习,有不对的地方欢迎评论哈!
参考资料:
Golang修养之路GMP章节
并发调度
详解 Go 程序的启动流程,你知道 g0,m0 是什么吗?
Go语言调度器之创建main goroutine
Go 群友提问:Goroutine 数量控制在多少合适,会影响 GC 和调度?
Go开发中,如何有效控制Goroutine的并发数量
golang gomaxprocs调高引起调度性能损耗
[GO语言]合理配置GOMAXPROCS提升一倍以上的性能