V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
zwh8800
V2EX  ›  Go 编程语言

在项目中的一些思考:线程池里究竟该放多少线程?

  •  
  •   zwh8800 · 2016-07-09 13:32:23 +08:00 · 2566 次点击
    这是一个创建于 2849 天前的主题,其中的信息可能已经有所发展或是发生改变。

    在最近的使用 golang 开发中,发现 goroutine 实际上解决的只是线程资源的调度,避免大量线程带来的资源瓶颈。

    而在实际开发中,更多遇到的问题是其他的资源瓶颈带来的。比如 tcp 连接、数据库连接、带锁的资源等。并不只是一个简单的线程资源的问题,当使用这些资源时,还是需要要用到使用传统线程时的一些思想/技术。

    所以说感觉并发这个问题是个大坑,软件工程没有银弹。

    当然了, golang 能合理调度线程资源已经是语言的一个很大进步了,不用让程序员自己费心调度线程。

    具体的思考我写到博客里了,这里贴代码和图不太方便,我放个链接吧:

    并发难 | 池里究竟该放多少线程?https://lengzzz.com/note/concurrency-roadblock-how-many-threads-should-be-in-pool

    只是个人观点,抛砖引玉,大家多多讨论一下。

    软件工程没有银弹,路漫漫其修远兮,吾将上下而求索。

    24 条回复    2016-07-11 11:45:11 +08:00
    des
        1
    des  
       2016-07-09 13:39:58 +08:00 via Android
    一般性而言, CPU 密集运算,和 CPU 核数相等就行了
    tiancaiamao
        2
    tiancaiamao  
       2016-07-09 13:44:37 +08:00
    最佳线程数量 = (线程等待时间 + 线程 CPU 时间) / 线程 CPU 时间 * CPU 数量
    平均响应时间 = 并发线程数 / 最佳线程数 * 最佳线程响应时间

    最后, LZ 研究的东西跟线程池半毛钱关系都没有
    zwh8800
        3
    zwh8800  
    OP
       2016-07-09 13:45:32 +08:00
    @des 是的,运算密集型的应用应该是最可控的。但实际中都是复杂到不行的 IO 密集型应用😳
    zwh8800
        4
    zwh8800  
    OP
       2016-07-09 13:53:56 +08:00
    @tiancaiamao

    这个公式也并没有考虑到 IO 资源的瓶颈问题。我在实际中首先使用单线程做了 pprof 。总执行时间 130s ,卡在 Syscall 上的时间是 90s 。

    那么按道理来说应该是 130 / (130 - 90) * 核数 = 52 。

    但实际上,开 32 个线程,数据库就崩了。这是 IO 资源有瓶颈导致的。

    好吧,确实和有没有线程池关系不大,重点在线程数量上。
    kamikat
        5
    kamikat  
       2016-07-09 14:24:45 +08:00
    IO 密集优化的线程池大小把平均 IO 等待时间和 CPU 时间的比值乘到 CPU 核心数就可以了(好像和 @tiancaiamao 回复里的公式差不多… )。
    开 32 个线程数据库就崩了这种事情… 是数据库的瓶颈。
    mengzhuo
        6
    mengzhuo  
       2016-07-09 14:28:52 +08:00 via iPhone
    goroutine 和一般线程不是一个东西 基本不需要计算这些量
    zwh8800
        7
    zwh8800  
    OP
       2016-07-09 14:33:53 +08:00
    @kamikat 嗯嗯,确实是数据库的,但有时更复杂,并发高了之后 connect 函数也会莫名其妙超时。

    @mengzhuo 我以前也是你这种想法,直到发现 goroutine 只解决了线程资源瓶颈的问题。其他 IO 资源的瓶颈问题还是需要自行解决的。
    kamikat
        8
    kamikat  
       2016-07-09 14:46:11 +08:00
    @zwh8800 LZ 想问的大概是数据库的连接池开多大,我自己倾向认为数据库是 CPU 密集型的(数据库对 IO 什么的有各种的优化来着),所以一般是连接数=核心数。榨干机器性能的任务就交给数据库来处理了,比较不赞同增加连接数逼迫数据库榨干机器性能的方法。
    mengzhuo
        10
    mengzhuo  
       2016-07-09 15:07:31 +08:00 via iPhone
    @zwh8800 数据库的连接肯定得限制的,还有文件加锁都属于常识啦。楼主你这个吐槽的对象都不是同一个好么
    reus
        11
    reus  
       2016-07-09 17:18:14 +08:00
    数据库崩,就去调数据库参数
    connect 超时,就加网络带宽
    和 golang 其实没什么关系
    而且,把 goroutine 看成线程就对了,性质基本一致
    shyling
        12
    shyling  
       2016-07-09 18:48:44 +08:00
    是问线程池的大小吧= =
    zwh8800
        13
    zwh8800  
    OP
       2016-07-09 19:33:19 +08:00
    @mengzhuo

    我的意思是,各种对并发支持的好的语言,也只是在 “平衡线程资源” 这一点上做到了优化。对于实际中更常见的 IO 资源瓶颈引来的问题,还是得自己动手调。

    @reus

    调并发量本身就是调并发程序必不可少的一步,数据库参数再怎么调也架不住程序瞎搞啊。


    @shyling 对的
    wizardforcel
        14
    wizardforcel  
       2016-07-09 20:10:32 +08:00
    这个就需要你手动调啊,我的电脑虽然是四核,但以前写爬虫的时候发现 10 个左右更快一点。
    louk78
        15
    louk78  
       2016-07-09 21:56:24 +08:00
    和线程池有个一毛钱关系吗?线程不就是时间片,不装逼就不能活了
    Comdex
        16
    Comdex  
       2016-07-09 23:01:50 +08:00
    这个时候又要推一下 goroutine pool lib 了 https://github.com/Comdex/octopus
    wander2008
        17
    wander2008  
       2016-07-10 09:19:13 +08:00 via iPhone
    这时候就应该去了解一下 java
    zwh8800
        18
    zwh8800  
    OP
       2016-07-10 12:26:20 +08:00
    @louk78 手动黑人问号

    @Comdex 嗯嗯,我也用了一个 goroutine pool https://github.com/go-playground/pool 才 100 多行,很轻量

    @wander2008 java 转的 golang ,以前写 java 和 c#
    wander2008
        19
    wander2008  
       2016-07-10 14:38:53 +08:00 via iPhone
    @zwh8800 你用 java 多久了?
    zwh8800
        20
    zwh8800  
    OP
       2016-07-10 18:35:31 +08:00 via iPhone
    @wander2008 上家公司用 java , spring mvc 什么的。在那里工作了 7 个月。之前在学校也有做过。
    wander2008
        21
    wander2008  
       2016-07-10 19:43:52 +08:00 via iPhone
    @zwh8800 😓还是多去看看吧
    zwh8800
        22
    zwh8800  
    OP
       2016-07-10 20:54:20 +08:00
    @wander2008 有话就说,吞吞吐吐的真是烦
    wander2008
        23
    wander2008  
       2016-07-10 22:26:43 +08:00 via iPhone
    @zwh8800 你以为你谁啊。没兴趣义务多说。 sb
    zwh8800
        24
    zwh8800  
    OP
       2016-07-11 11:45:11 +08:00
    @wander2008 大家都是做技术的,说话直来直去就行了,如果您觉得我哪里说得不对的就直说,没想明白怎么说就**闭嘴**。不用您费心回复这三条。

    @louk78 还有楼上这位,不知道我的主题哪句话戳到您可怜的**玻璃自尊心**了,让您感觉我在**装逼**。手动呵呵。

    以前感觉在 v2 的都是同行,姿势水平都是比较高一些的人,没想到也能碰上这种垃圾。

    两位我已 block 。早上刚上班说话比较冲,如果您二位感觉有啥不爽的,您就憋着吧。

    最后 at 一下站长,这种直接说脏话的,应该封号的吧。 @Livid
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2982 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 13:28 · PVG 21:28 · LAX 06:28 · JFK 09:28
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.