关于go协程池的疑问

fichtner · 2022-08-03 15:58:30 · 1925 次点击 · 大约8小时之前 开始浏览    置顶
这是一个创建于 2022-08-03 15:58:30 的主题,其中的信息可能已经有所发展或是发生改变。

遇到个问题,使用go关键字直接开协程快还是使用go协程池快。

我自己在千万任务(模拟任务执行都是10微秒)测了下,发现协程池要慢很多。

请问大家有没有测过呢?协程池会在时间上效率会降低这个结论对吗

实验一:使用go1.13版本,对比无协程池和Ants协程池(n=1千万)

func TestNoPool(t *testing.T) {                //花费时间 150.829s
    var wg sync.WaitGroup
    wg.Add(n)
    for i := 0; i < n; i++ {
        go func() {
            time.Sleep(10 * time.Microsecond)
            wg.Done()
        }()
    }
    wg.Wait()
}
func TestAntsPool(t *testing.T) {            //花费时间 6.899s
    defer Release()
    var wg sync.WaitGroup
    wg.Add(n)
    for i := 0; i < n; i++ {
        _ = Submit(func() {
            time.Sleep(10 * time.Microsecond)
            wg.Done()
        })
    }
    wg.Wait()
}

实验二:改变wg.Add()的位置:

func TestNoPool(t *testing.T) {                //花费时间 3.387s
    var wg sync.WaitGroup

    for i := 0; i < n; i++ {
        wg.Add(1)
        go func() {
            time.Sleep(10 * time.Microsecond)
            wg.Done()
        }()
    }
    wg.Wait()
}
func TestAntsPool(t *testing.T) {            //花费时间 6.159s
    defer Release()
    var wg sync.WaitGroup

    for i := 0; i < n; i++ {
        wg.Add(1)
        _ = Submit(func() {
            time.Sleep(10 * time.Microsecond)
            wg.Done()
        })
    }
    wg.Wait()
}
  • 之前,我猜测,协程池可能在go的旧版本上比如go1.13比直接go一个协程会有执行时间上的优势。而新版本的go,如1.18。走协程池远不如直接go一个协程快。所以我就做了如上面实验一,并查询文档自go1.14起goroutine支持异步抢占式调度,认为自己的猜测是对的。
  • 但是,昨天改变了下wg.Add()的位置,测的数据完全不一样,这就让我很困惑。因为之前的结果很可能是wg.Add()放在for外导致耗费了大量时间,而不是直接go协程所造成的消耗。
  • 当然,我在go1.18上做如上的两个实验,wg.Add()放哪里时间花费都一样,结果都是直接开协程更快。协程池在时间上完全没优势。

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1925 次点击  
加入收藏 微博
11 回复  |  直到 2022-08-04 20:03:02
fginter
fginter · #1 · 3年之前

Go的协程那么简单好用,还用的着什么Ants协程池么?直接创建协程,然后通过channel传递数据,在协程中处理即可,这种方式是语言级别推荐,效率应该也是最高的。

saberlong
saberlong · #2 · 3年之前

协程池一方面是为了控制资源占用,另一方面在特定情况下提高效率,这种提高主要体现在复用。比如避免新开的协程经常发生栈扩展等。因为创建协程相比创建线程代价低太多,所以相比线程池,在这一方面不见得有提升。在硬件条件充足时,新建协程速度更快很正常。使用协程池,工作协程数量少,反而处理慢。

但看文章内容,可变因素多不好判定。建议协程池通过压测测试最合适的工作协程数量,以及最高内存占用。再做统一资源限制后(比如限制内存使用),测试不使用协程的情况。

fichtner
fichtner · #3 · 3年之前

嗯嗯,好的,非常感谢大家。最后一个问题,在go1.13版本wg.Add()的位置对时间和内存影响巨大的原因(不使用协程池),大家有了解吗?我下载了go1.14也跑了下。下面是结果:

func TestNoPoolAddN(t *testing.T) {
    fmt.Println("任务总数",n)
    var wg sync.WaitGroup
    wg.Add(n)
    for i := 0; i < n; i++ {

        go func() {
            time.Sleep(10 * time.Microsecond)
            wg.Done()
        }()
    }

    wg.Wait()
    mem := runtime.MemStats{}
    runtime.ReadMemStats(&mem)
    curMem = mem.TotalAlloc/MiB - curMem
    t.Logf("memory usage:%d MB", curMem)
}

func TestNoPoolAdd1(t *testing.T) {
    fmt.Println("任务总数",n)
    var wg sync.WaitGroup
    for i := 0; i < n; i++ {
        wg.Add(1)
        go func() {
            time.Sleep(10 * time.Microsecond)
            wg.Done()
        }()
    }
    wg.Wait()
    mem := runtime.MemStats{}
    runtime.ReadMemStats(&mem)
    curMem = mem.TotalAlloc/MiB - curMem
    t.Logf("memory usage:%d MB", curMem)
}

go1.18 版本结果:

DJ-CE02F28JGEMQQL7H:ants user$  go version
go version go1.18.3 darwin/amd64
DJ-CE02F28JGEMQQL7H:ants user$  go test -run="TestNoPool" -v
=== RUN   TestNoPoolAddN
任务总数 10000000
    ants_test.go:213: memory usage:919 MB
--- PASS: TestNoPoolAddN (3.14s)
=== RUN   TestNoPoolAdd1
任务总数 10000000
    ants_test.go:230: memory usage:917 MB
--- PASS: TestNoPoolAdd1 (3.29s)
PASS
ok      github.com/panjf2000/ants/v2    6.900s

go1.14 版本结果:

DJ-CE02F28JGEMQQL7H:ants user$ go version
go version go1.14.15 darwin/amd64
DJ-CE02F28JGEMQQL7H:ants user$  go test -run="TestNoPool" -v
=== RUN   TestNoPoolAddN
任务总数 10000000
    ants_test.go:213: memory usage:849 MB
--- PASS: TestNoPoolAddN (3.13s)
=== RUN   TestNoPoolAdd1
任务总数 10000000
    ants_test.go:230: memory usage:763 MB
--- PASS: TestNoPoolAdd1 (2.66s)
PASS
ok      github.com/panjf2000/ants/v2    6.152s

go1.13 版本结果:

DJ-CE02F28JGEMQQL7H:ants user$  go version
go version go1.13.15 darwin/amd64
DJ-CE02F28JGEMQQL7H:ants user$  go test -run="TestNoPool" -v
=== RUN   TestNoPoolAddN
任务总数 10000000
--- PASS: TestNoPoolAddN (127.86s)
    ants_test.go:213: memory usage:5084 MB
=== RUN   TestNoPoolAdd1
任务总数 10000000
--- PASS: TestNoPoolAdd1 (3.16s)
    ants_test.go:230: memory usage:611 MB
PASS
ok      github.com/panjf2000/ants/v2    132.974s

可能是go1.14版本更新有性能上的改进或者是bug修复,自己有查go1.14的版本更新,但是不清楚是原因在哪?看着不像是goroutine的异步抢占式调度造成的。

saberlong
saberlong · #4 · 3年之前

这个问题其实就是有了异步抢占后才优化的,与表面的waitgroup无关。具体看这篇 https://studygolang.com/topics/11155

etog
etog · #5 · 3年之前

我用协程池是为了控制并发量,避免协程无限制创建,效率反倒没那么高的要求。

fichtner
fichtner · #6 · 3年之前

@saberlong 非常感谢。

fichtner
fichtner · #7 · 3年之前

另外,请问大家,我用sleep来模拟任务是否有问题?因为我将任务改为递归之后,结果是使用线程池快。【go1.18版本】

saberlong
saberlong · #8 · 3年之前
fichtnerfichtner #7 回复

另外,请问大家,我用sleep来模拟任务是否有问题?因为我将任务改为递归之后,结果是使用线程池快。【go1.18版本】

我不知道sleep改成递归是怎样一种改法。 凭空猜测,单从递归出发,递归层数多的话,会导致栈扩展。栈扩展会开辟新的空间,将旧有的栈复制过去,然后将新值压栈。

fichtner
fichtner · #9 · 3年之前

time.Sleep(10 * time.Microsecond)改为:testFunc() 使用go1.18版本,对比无协程池和Ants协程池(n=1千万),修改前无协程池快,修改后协程池快(且使用协程池与不使用协程池的空间消耗基本一样)

func DoCopyStack(a, b int) int {
    if b < 100 {
        return DoCopyStack(0, b+1)
    }
    return 0
}

func testFunc() {
    DoCopyStack(0, 0)     
}
saberlong
saberlong · #10 · 3年之前
fichtnerfichtner #9 回复

time.Sleep(10 * time.Microsecond)改为:testFunc() 使用go1.18版本,对比无协程池和Ants协程池(n=1千万),修改前无协程池快,修改后协程池快(且使用协程池与不使用协程池的空间消耗基本一样) ``` func DoCopyStack(a, b int) int { if b < 100 { return DoCopyStack(0, b+1) } return 0 } func testFunc() { DoCopyStack(0, 0) } ```

使用GODEBUG进行分析。 比如GODEBUG="schedtrace=1000" go test GODEBUG="scheddetail=1,schedtrace=1000" go test 你会发现使用sleep时,调度压力其实很低的。每个P每次采样时,调度的协程数比较少。sleep期间不需要p去分配时间片。而调用testFunc时,一直在用cpu计算。所以P对协程的调度压力很大。超过一定量后协程,协程的调度损耗就体现出来了。这时候用线程池,限制数量,反而降低了调度损耗。

fichtner
fichtner · #11 · 3年之前
saberlongsaberlong #10 回复

#9楼 @fichtner 使用GODEBUG进行分析。 比如`GODEBUG="schedtrace=1000" go test` `GODEBUG="scheddetail=1,schedtrace=1000" go test` 你会发现使用sleep时,调度压力其实很低的。每个P每次采样时,调度的协程数比较少。sleep期间不需要p去分配时间片。而调用testFunc时,一直在用cpu计算。所以P对协程的调度压力很大。超过一定量后协程,协程的调度损耗就体现出来了。这时候用线程池,限制数量,反而降低了调度损耗。

醍醐灌顶,万分感谢🙏

添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传