c 伺服器開發之效能優化

為什麼要寫這篇文章？

聊技術的時候，談到記憶體問題、cpu問題、效率問題的時候，無疑是考量乙個工程師的實戰水平，作為c++開發工程師，沒有自己解決以上問題的專業手段，或許就是缺陷。我之所以寫這個文章，主要是為了記錄、分享我的辦法。我之前寫過記憶體洩漏的一篇文章（其實也是一種手段，如果為你所用，聊技術的時候絕對可以加分。

在這裡我很準確的說，記憶體洩漏沒辦法跟蹤，只能靠日誌、**走查、提前避免、猜測等手段處理。

在寫完**，自測期間，除了使用gdb單步除錯，這裡介紹兩種工具：

1、valgrind

valgrind本身的cpu消耗比較大，大部分記憶體問題都能解決，常用命令是

valgrind --leak-check=yes ./a.out

2、strace

strace主要跟蹤系統呼叫的情況，說實話，不是很常用，但有時候不能不用，因為誰也不知道系統是不是因為「系統呼叫」的開銷造成的問題。常用命令如下：

strace -o output.txt -t -tt -e trace=all -p 12345

當然，linux核心還實現了很多探針。dstrace就是一種。

3、mstrace

這個函式主要跟蹤malloc與free的對應情況，需要程式設計，加入**，linux提供mtrace和muntrace兩個函式。在查詢記憶體問題上，能知道個寫洩漏情況的大概。

4、addresssanitizer

是乙個快速的記憶體錯誤檢測工具。它非常快，只拖慢程式兩倍左右（比起valgrind快多了）。它包括乙個編譯器instrumentation模組和乙個提供malloc()/free()替代項的執行時庫。具體使用命令在官網能查到。

關於cpu的使用情況。很多時候不知道怎麼去定位，線上cpu 百分之百的時候顯得很棘手，其實是有工具的。

perf、火焰圖

perf是linux 2.6+核心中的工具，在linux原始碼的 tools/perf裡，編譯安裝就行.

perf利用linux的trace特性，可以用於實時跟蹤，統計event計數(perf stat)；或者使用取樣(perf record)，報告(perfreport|script|annotate)的使用方式進行診斷。

火焰圖看起來就像一團跳動的火焰，燃燒在火苗尖部的就是 cpu 正在執行的操作，不過需要說明的是顏色是隨機的，本身並沒有特殊的含義。

縱向表示呼叫棧的深度，橫向表示消耗的時間。因為呼叫棧在橫向會按照字母排序，並且同樣的呼叫棧會做合併，所以，乙個格仔的寬度越大越說明其可能是瓶頸。

綜上所述，主要就是看那些比較寬大的火苗，特別留意那些類似平頂山的火苗。

其實這個問題特別廣，效率也就是程式快慢問題。

同步與非同步的問題一直的很重要的，linux中沒有很有好的非同步支援，但是強大的epoll讓我們很輕鬆的實現非阻塞，reactor設計模式，讓效能不再受多執行緒亦或多程序的弊端限制。

其實我們很難繞開多執行緒和多程序，因為要實現併發，像現在c++引入協程庫，其實也是為了解決效率問題和高併發的瓶頸。伺服器開發目前很多能用golang語言解決的，絕對不會使用c++，因為golang已經解決了多執行緒的弊端，自帶協程框架。

聊效率問題，本人大致總結以下幾點

1、**設計

redis與memcached的對比，就是單執行緒的reactor與多執行緒的的對比。所以說程式的架構特別重要。實戰中一定要結合業務。

除了**架構，開源庫的選擇也很重要啊，高效能中介軟體（如redis、nginx、memcached、libevent、zmq），使用c/c++編寫。選擇開源庫，也是要看程式語言屬性的。

2、記憶體問題

高效能的服務，一定要基於記憶體去考慮，redis完全基於記憶體，所以單執行緒模式也很快呀。

記憶體也有瓶頸的，4g的ram,能開多少執行緒（單個10m）？那用個記憶體池怎麼樣？我認為nginx的記憶體池可以一學。

3、伺服器的耦合性

所有服務部署到一台機器？高耦合，必然對日誌、維護、問題排查造成影響，不知道哪天宕機，恐怖如斯，還是乙個服務一台機器吧。