golang中定時器cpu使用率高的示例分析

這篇文章主要介紹了golang中定時器cpu使用率高的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

前言:

上線一個用golang寫的高頻的任務派發(fā)系統(tǒng)，上線跑著很穩(wěn)定，但有個缺點就是當沒有任務的時候，cpu的消耗也在幾個百分點。 平均值在3%左右的cpu使用率。你沒有任務的時候，cpu還跑到3%，這個說不過去呀。通過查看進程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的加強版，除了我們不關心的信號掩碼外，他是支持納秒級別的定時器。

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

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

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

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

測試定時器與futex及pselect6的關系

既然確定是 定時器的問題，那么我們來做測試下各種的組合，把協(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ù)相對應的變高。  反之，定時器提升到大幾秒，futex邊的更少了…  

那么問題又來了，定時器為什么會產(chǎn)生鎖？ 定時器不外乎就那幾個方法，小頂堆呀，紅黑樹呀…. golang使用堆來構建全局定時器，既然是堆，那么肯定就要有鎖，開了幾百個協(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ā)一個時間輪，時間輪的刻度可以配置成一毫秒，這樣可以收斂很多的定時任務。 時間輪也是各大公司推薦的方案。

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

感謝你能夠認真閱讀完這篇文章，希望小編分享的“golang中定時器cpu使用率高的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業(yè)資訊頻道，更多相關知識等著你來學習!