golang中定時器cpu使用率高的現(xiàn)象詳析

前言:

廢話少說，上線一個用golang寫的高頻的任務(wù)派發(fā)系統(tǒng)，上線跑著很穩(wěn)定，但有個缺點就是當(dāng)沒有任務(wù)的時候，cpu的消耗也在幾個百分點。 平均值在3%左右的cpu使用率。你沒有任務(wù)的時候，cpu還跑到3%，這個說不過去呀。通過查看進(jìn)程pidstat捕獲得知，system系統(tǒng)的cpu消耗也不少。

sys的cpu占用率高一般是由于大量的syscall系統(tǒng)調(diào)用引起的….

下面的截圖是用strace統(tǒng)計出來的系統(tǒng)調(diào)用…. 我們發(fā)現(xiàn)  futex 和 pselect6 的syscall非常的多….  futex 是鎖的調(diào)用，pselect6可以理解為select的加強(qiáng)版，除了我們不關(guān)心的信號掩碼外，他是支持納秒級別的定時器。

那我們知道，在golang里很多的鎖操作，比如sync.Mutex 已經(jīng)被抽象成 標(biāo)志位及waitQueue，加runtime調(diào)度的模式。這也是所有協(xié)程框架會做的事情，抽象鎖的操作，避免陷入內(nèi)核上下文切換，使用協(xié)程內(nèi)置的調(diào)度器，golang是通過runtime來做使這些Goroutine排隊的喚醒和拿鎖。  我們用戶層除了cgo之外，是不容易調(diào)用futex syscall….  

有人說了，channel是有鎖的，對的，channel的底層數(shù)據(jù)結(jié)構(gòu)是有鎖對象的，但是他的鎖操作正如我上面說的那樣，已經(jīng)被抽象成atomic cas了, 不可能這么多futex的。

下面是火焰圖的表現(xiàn).

那我們先放棄futex的追查，先來排查下 pselect6為毛這么多？ 整個系統(tǒng)里看起來會用到超時邏輯的只有select了。  為了避免channel讀寫長時間阻塞，我們通常都會加一個定時器，比如使用 time.After, time.NewTicker, time.NewTimer …. 

測試定時器與futex及pselect6的關(guān)系

既然確定是 定時器的問題，那么我們來做測試下各種的組合，把協(xié)程數(shù)和定時器時間的精度提高來看。

下面是 300個協(xié)程，sleep 100ms 的cpu占用比.

下面是 800個協(xié)程，sleep 100ms的cpu占用比 .

下面是800個協(xié)程，sleep加長到1s 之后的cpu表現(xiàn).

通過測試來看，只要把定時器的時間精度放到1秒，cpu占用率還是降低了不少….   所以說，有用 …

那么回到問題，前面說的 futex 怎么一回事？  跟定時器是否有聯(lián)系？   答案是有聯(lián)系的 .  定時器精度小的時候，futex鎖操作次數(shù)相對應(yīng)的變高。  反之，定時器提升到大幾秒，futex邊的更少了…  

那么問題又來了，定時器為什么會產(chǎn)生鎖？ 定時器不外乎就那幾個方法，小頂堆呀，紅黑樹呀…. golang使用堆來構(gòu)建全局定時器，既然是堆，那么肯定就要有鎖，開了幾百個協(xié)程，如果有N個P，那么幾百個協(xié)程會分派在不同的P上。 協(xié)程需要跑在線程上，那么這么多的線程去操作heap堆，自然就會有更多的鎖沖突，鎖操作了。

先前的cpu占用率高的代碼樣例:

# xiaorui.cc
 var ticker = time.NewTicker(100 * time.Millisecond)
 defer ticker.Stop()
 var counter = 0
 for {
  select {
  case -serverDone:
   return
  case -ticker.C:
   counter += 1
  }
 }
}

如何解決上面說的問題?

要么就不要用定時器

如果非要使用，可以把時間精度放大，或者 自定義定時器，比如開發(fā)一個時間輪，時間輪的刻度可以配置成一毫秒，這樣可以收斂很多的定時任務(wù)。 時間輪也是各大公司推薦的方案。

可以參考下面時間輪的實現(xiàn)…

END

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。