Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime.GOMAXPROCS(int) #1

Closed
joostshao opened this issue Oct 30, 2014 · 11 comments
Closed

runtime.GOMAXPROCS(int) #1

joostshao opened this issue Oct 30, 2014 · 11 comments

Comments

@joostshao
Copy link

多核的能不能设置一下? 应该还能提升不少
纯粹菜鸟建议

@xiaojiaqi
Copy link
Owner

谢谢,我试试看。

@xiaojiaqi
Copy link
Owner

草草 测试了一下 在 Go1.3 的版本里面 没有明显变化,似乎CPU更高了一些。

@parkghost
Copy link

大量 goroutine 的使用情境下,改用 Go1.4 可以省下不少記憶體用量

http://tip.golang.org/doc/go1.4#runtime

The use of contiguous stacks means that stacks can start smaller without triggering performance issues, so the default starting size for a goroutine's stack in 1.4 has been reduced to 2048 bytes from 8192 bytes.

@xiaojiaqi xiaojiaqi reopened this Nov 8, 2014
@xiaojiaqi
Copy link
Owner

screen shot 2014-11-07 at 6 09 47 pm

screen shot 2014-11-07 at 6 11 05 pm

我也认为自动的使用多核是golang的一个基本能力,所以昨天草草测试的结果,看到CPU变化并不明显,我认为可以接受。 但是昨天我发现了Go 的一个明显的问题。

测试环境为 70万连接, 第一张图为 刚开始时候的流量和CPU 情况, 第二张为 过了一段时间的 流量和CPU图, 从图里你可以发现一个很有意思的现象,一开始 Go的吐流数据 是不稳定的,可以说是有明显峰值峰谷。 但是过了一段时间,流量变得很平缓。

按照设计的要求,每10秒要求回送500字节,假设Go的实现是稳定的,因为客户端都是在某个时间点瞬间大量地连上服务器的,所以也会在某些时间点发生大量数据回吐,那么此时流量就应该是不稳定的 (正如图一所示),这种“不稳定的”这种样式还应该不断重复。但是结果却不是这样,到了最后流量开始平缓了,我认为是因为某种的原因,导致原来应该在某个时间点密集发生的事件,因为调度或者定时器的缘故慢慢的稀疏了。这可以认为是Go的问题吗?

@parkghost
Copy link

send欄位的資料單位是什麼? 看不出來有每10秒送出 333MB(700000*500bytes/1024/1024)的資料量數據

@xiaojiaqi
Copy link
Owner

截图使用dstat ,send 的单位 如果是绿色的 就是 MB, 平均到10秒就是 33MB , 粗略的算
38 + 53+60+63+72+54 + = 341, 可以粗略的认为是符合条件的。 当然科学的方法 是在客户端利用抓包软件,精确的统计,但是这个超出了我的条件范围。

@parkghost
Copy link

謝謝你的說明,我了解了

對於流量逐漸平緩,大概是scheduler延遲了 goroutine 的執行時間,直接也延遲了time.Sleep(10s)的設置, 導致 goroutine 執行觸發點逐漸分散; 使用 time.ticker 可以產生一致的時間間隔

func Handler(conn net.Conn) {
    ticker := time.NewTicker(time.Duration(10 * time.Second))
    for {
        _, err := conn.Write(array)
        if err != nil {
            return
        }
        <-ticker.C
    }
}

@xiaojiaqi
Copy link
Owner

这个说明GO的调度是不精准的,按照设计的原意,应该保持不断波峰波谷的样子才对。正如你所说时间点发生了偏移

@parkghost
Copy link

GO的调度是不精准的 不太清楚你指的是什麼? scheduling 使 goroutine 執行點延遲是正常現象

流量波峰消弭主因是go{for{sleep(duration)}}的方式, 會使各別 goroutine 執行觸發點累加scheduling latency,導致各別的 goroutine 執行觸發點逐漸擴散

timeAt(n) = timeAt(n-1) + 10s + scheduling latency

func Handler(conn net.Conn) {
    for {
        _, err := conn.Write(array)
        if err != nil {
            return
        }
        time.Sleep(10 * time.Second)
    }
}

time.Ticker 的方式不會累加 scheduling latency ,各別 goroutine 執行觸發點能有固定時間間隔

timeAt(n) = n * 10s + scheduling latency

func Handler(conn net.Conn) {
    ticker := time.NewTicker(time.Duration(10 * time.Second))
    for {
        _, err := conn.Write(array)
        if err != nil {
            return
        }
        <-ticker.C
    }
}

@xiaojiaqi
Copy link
Owner

谢谢指点

@xiaojiaqi
Copy link
Owner

close it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants