TSINGSEE青犀視頻接到的許多客戶的專案場景都很龐大，一臺服務器可能接入幾百路甚至上千路攝像頭，這種情況就可能就會導致服務器壓力大，CPU很容易被占滿，
例如，TSINGSEE青犀視頻有個專案現場使用的是8核服務器，接入500路攝像頭，程式運行幾分鐘CPU就被占滿了，接下來就和大家分享下，我們是如何解決該問題的，
1、首先我們懷疑接入攝像頭路數太多了，于是減少接入攝像頭路數進行排查，減少到200路、100路、50路，依然會出現CPU占滿的情況，于是排除機器性能達不到要求，
2、外部可能排除，于是排查代碼，通過golang的pprof（pprof 是用于可視化和分析性能分析資料的工具）工具進行分析排查，
3、在routers的Init方法中添加 pprof.Register(Router)，接下來就可以是用pprof工具了，
4、pprof工具有兩種使用方式：
（1）第一種通過 Web 界面：http://ip:port/debug/pprof/，
profiles:
0 block
5 goroutine
3 heap
0 mutex
9 threadcreate
這個頁面中有許多子頁面：
cpu（CPU Profiling）: HOST/debug/pprof/profile，默認進行 30s 的 CPU Profiling，得到一個分析用的 profile 檔案 block（Block Profiling）：HOST/debug/pprof/block，查看導致阻塞同步的堆疊跟蹤
goroutine：$HOST/debug/pprof/goroutine，查看當前所有運行的 goroutines 堆疊跟蹤
heap（Memory Profiling）: HOST/debug/pprof/heap，查看活動物件的記憶體分配情況 mutex（Mutex Profiling）：HOST/debug/pprof/mutex，查看導致互斥鎖的競爭持有者的堆疊跟蹤
threadcreate：$HOST/debug/pprof/threadcreate，查看創建新OS執行緒的堆疊跟蹤
（2）通過互動式終端使用：
go tool pprof http://ip:port/debug/pprof/profile
flat：給定函式上運行耗時
flat%：同上的 CPU 運行耗時總比例
sum%：給定函式累積使用 CPU 總比例
cum：當前函式加上它之上的呼叫運行總耗時
cum%：同上的 CPU 運行耗時總比例
最后一列為函式名稱，在大多數的情況下，我們可以通過這五列得出一個應用程式的運行情況，加以優化，
5、EasyNVR使用pprof工具進行排查后，分析代碼發現EasyNVR在專案啟動成功，一個開啟的通道就是起一個執行緒一直跑，這個執行緒一直堵塞著，里面有個定時器，定時獲取該通道的快照，現在就相當于有多少路通道就會有多少執行緒同時跑，而且這個定時獲取通道快照涉及到cgo代碼，比較耗時和耗費CPU，于是將這一塊代碼修改為一個定時任務，在這個定時任務里面從所有已開啟的通道串列中去獲取快照，
6、解決代碼
在專案啟動時初始化一個資源池
在每個通道開啟時將其添加到執行緒池里面去，修改前開啟多少個通道就有多少個執行緒去獲取快照，現在是定時任務里面開啟一個執行緒去獲取快照，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/261815.html
標籤：其他
上一篇：單點登錄（SSO）認識和實踐