Linux程序性能分析工具time+pstrace+grpof

http://www.cnblogs.com/me115/p/4605273.html

背景

使用C++開發了一個Redis數據導入工具 
從oracle中將所有表數據導入到redis中； 
不是單純的數據導入，每條oracle中的原有記錄，需要經過業務邏輯處理， 
並添加索引（redis集合）； 
工具完成後，性能是個瓶頸；

優化效果

使用了2個樣本數據測試： 
樣本數據a表8763 條記錄； 
b表940279 條記錄；

優化前，a表耗時11.417s； 
優化後，a表耗時1.883s；

用到的工具

gprof, pstrace,time

使用time工具查看每次執行的耗時，分別包含用戶時間和系統時間； 
使用pstrace打印實時運行，查詢進程主要的系統調用，發現耗時點； 
使用gprof統計程序的耗時彙總，集中精力優化最耗時的地方； 
使用簡介： 
1.對g++的所有編輯和連接選項都必須要加上-pg（第一天由於沒有在連接處加上-pg選項，導致無法出統計報告）； 
2.執行完程序後，本目錄會產生gmon.out文件； 
3.gprof redistool gmou.out > report,生成可讀文件report，打開report集中優化最耗時的函數；

優化過程

優化前11.417s：

time ./redistool im a a.csv
real    0m11.417s
user    0m6.035s
sys     0m4.782s （發現系統調用時間過長）

文件內存映射

系統調用時間過長，主要是文件讀寫，初步考慮是讀取文件時，調用api次數過於頻繁； 
讀取樣本採用的是文件fgets一行行的讀取，採用文件內存映射mmap後，可直接使用指針操作整個文件內存快；

日誌開關提前

改進了文件讀寫後，發現優化效果比較有限（提高了2s左右）；fgets是C的文件讀取庫函數，相比系統read()，是帶了緩衝區了，應該不會太慢（網上有人測試，文件內存映射相比fgets()能快上一個數量級，感覺場景應該比較特殊）；

之後通過pstrace工具發現log.dat打開次數過多；原來是調試日誌的開關寫到了後面，導致 調試日誌都是會打開日誌文件open("log.dat")； 
將日誌開關提前；改進後，3.53s

time ./redistool im a a.csv
real    0m3.530s
user    0m2.890s
sys     0m0.212s

vector空間預先分配

後續通過gprof分析，某個函數的vector內存分配次數多，並有不少複製次數： 
改進以下這行代碼：

vector <string> vSegment;

使用靜態vector變量，並預先分配內存：

static vector <string> vSegment;
vSegment.clear();
static int nCount = 0;
if( 0 == nCount)
{
    vSegment.reserve(64);
}
++nCount;

優化後，提升至2.286s

real    0m2.286s
user    0m1.601s
sys     0m0.222s

同樣，另外一個類中的成員vector也使用預先分配空間（在構造函數中)：

m_vtPipecmd.reserve(256);

優化後，提升至2.166s;

real    0m2.166s
user    0m1.396s
sys     0m0.204s

函數改寫 && 內聯

繼續執行程序，發現SqToolStrSplitByCh()函數消耗過大，改寫整個函數邏輯，並將改寫後的函數內聯： 
優化後，提升至1.937s

real    0m1.937s
user    0m1.301s
sys     0m0.186s

去除調試符和優化監測符號

最後，去掉debug和pg調試符號後，最終效果爲1.883s；

real    0m1.883s
user    0m1.239s
sys     0m0.191s

滿足生產要求

以上最後幾步看似毫秒級的提升，擴大到全表數據後，效果就很明顯了； 
優化後，生產上a表爲152w，導入耗時大約326s（~6分鐘）； 
b表數據420w，導入耗時大約1103s（~18分鐘）

Posted by: 大CC | 28JUN,2015 
博客：blog.me115.com [訂閱] 
Github：大CC