這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)FISCO BCOS工程師常用的性能分析工具有什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

四子王網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),四子王網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為四子王數(shù)千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的四子王做網(wǎng)站的公司定做！

FISCO BCOS是完全開源的聯(lián)盟區(qū)塊鏈底層技術(shù)平臺，由金融區(qū)塊鏈合作聯(lián)盟(深圳)(簡稱金鏈盟)成立開源工作組通力打造。開源工作組成員包括博彥科技、華為、深證通、神州數(shù)碼、四方精創(chuàng)、騰訊、微眾銀行、亦筆科技和越秀金科等金鏈盟成員機(jī)構(gòu)。

前 言

『過早的優(yōu)化是萬惡之源』

說出這句話的計算機(jī)科學(xué)先驅(qū)Donald Knuth并不是反對優(yōu)化，而是強(qiáng)調(diào)要對系統(tǒng)中的關(guān)鍵位置進(jìn)行優(yōu)化。假設(shè)一個for循環(huán)耗時0.01秒，即使使用循環(huán)展開等各種奇技淫巧將其性能提升100倍，把耗時降到0.00001秒，對于用戶而言，也基本無法感知到。對性能問題進(jìn)行量化測試之前，在代碼層面進(jìn)行各種炫技式優(yōu)化，可能不僅提升不了性能，反而會增加代碼維護(hù)難度或引入更多錯誤。

『沒有任何證據(jù)支撐的優(yōu)化是萬惡之源』

在對系統(tǒng)施展優(yōu)化措施前，一定要對系統(tǒng)進(jìn)行詳盡的性能測試，從而找出真正的性能瓶頸。奮戰(zhàn)在FISCO BCOS性能優(yōu)化的前線上，我們對如何使用性能測試工具來精確定位性能熱點這件事積累了些許經(jīng)驗心得。本文將我們在優(yōu)化過程中使用到的工具進(jìn)行了整理匯總，以饗讀者。

1.Poor Man's Profiler

窮人的分析器，簡稱PMP。盡管名字有些讓人摸不著頭腦，但人家真的是一種正經(jīng)的性能分析手段，甚至有自己的官方網(wǎng)站https://poormansprofiler.org/。PMP的原理是Stack Sampling，通過調(diào)用第三方調(diào)試器（比如gdb），反復(fù)獲取進(jìn)程中每個線程的堆棧信息，PMP便可以得到目標(biāo)進(jìn)程的熱點分布。

第一步，獲取一定數(shù)量的線程堆棧快照：

pid=$(pidof fisco-bcos)num=10for x in $(seq 1 $(num))  do    gdb -ex "set pagination 0" -ex "thread apply all bt" -batch -p $pid    sleep 0.5done

第二步，從快照中取出函數(shù)調(diào)用棧信息，按照調(diào)用頻率排序：

awk '  BEGIN { s = ""; }   /^Thread/ { print s; s = ""; }   /^\#/ { if (s != "" ) { s = s "," $4} else { s = $4 } }   END { print s }' | \sort | uniq -c | sort -r -n -k

最后得到輸出，如下圖所示：

從輸出中可以觀察到哪些線程的哪些函數(shù)被頻繁采樣，進(jìn)而可按圖索驥找出可能存在的瓶頸。上述寥寥數(shù)行shell腳本便是PMP全部精華之所在。極度簡單易用是PMP的最大賣點，除了依賴一個隨處可見的調(diào)試器外，PMP不需要安裝任何組件，正如PMP作者在介紹中所言：『盡管存在更高級的分析技術(shù)，但毫無例外它們安裝起來都太麻煩了……Poor man doesn't have time. Poor man needs food.』????。

PMP的缺點也比較明顯：gdb的啟動非常耗時，限制了PMP的采樣頻率不能太高，因此一些重要的函數(shù)調(diào)用事件可能會被遺漏，從而導(dǎo)致最后的profile結(jié)果不夠精確。

但是在某些特殊場合，PMP還是能發(fā)揮作用的，比如在一些中文技術(shù)博客中，就有開發(fā)人員提到使用PMP成功定位出了線上生產(chǎn)環(huán)境中的死鎖問題，PMP作者也稱這項技術(shù)在Facebook、Intel等大廠中有所應(yīng)用。不管怎樣，這種閃爍著程序員小智慧又帶點小幽默的技術(shù)，值得一瞥。

2.perf

perf的全稱是Performance Event，在2.6.31版本后的Linux內(nèi)核中均有集成，是Linux自帶的強(qiáng)力性能分析工具，使用現(xiàn)代處理器中的特殊硬件PMU（Performance Monitor Unit，性能監(jiān)視單元）和內(nèi)核性能計數(shù)器統(tǒng)計性能數(shù)據(jù)。

perf的工作方式是對運行中的進(jìn)程按一定頻率進(jìn)行中斷采樣，獲取當(dāng)前執(zhí)行的函數(shù)名及調(diào)用棧。如果大部分的采樣點都落在同一個函數(shù)上，則表明該函數(shù)執(zhí)行的時間較長或該函數(shù)被頻繁調(diào)用，可能存在性能問題。

使用perf需要首先對目標(biāo)進(jìn)程進(jìn)行采樣：

$ sudo perf record -F 1000 -p `pidof fisco-bcos` -g -- sleep 60

在上述命令中， 我們使用perf record指定記錄性能的統(tǒng)計數(shù)據(jù)；使用-F指定采樣的頻率為1000Hz，即一秒鐘采樣1000次；使用-p指定要采樣的進(jìn)程ID（既fisco-bcos的進(jìn)程ID），我們可以直接通過pidof命令得到；使用-g表示記錄調(diào)用棧信息；使用sleep指定采樣持續(xù)時間為60秒。

待采樣完成后，perf會將采集到的性能數(shù)據(jù)寫入當(dāng)前目錄下的perf.data文件中。

$ perf report -n

上述命令會讀取perf.data并統(tǒng)計每個調(diào)用棧的百分比，且按照從高到低的順序排列，如下圖所示：

信息已足夠豐富，但可讀性仍然不太友好。盡管示例中perf的用法較為簡單，但實際上perf能做的遠(yuǎn)不止于此。配合其他工具，perf采樣出的數(shù)據(jù)能夠以更加直觀清晰的方式展現(xiàn)在我們面前，這便是我們接下來要介紹的性能分析神器——火焰圖。

3.火焰圖

火焰圖，即Flame Graph，藉由系統(tǒng)性能大牛 Brendan Gregg提出的動態(tài)追蹤技術(shù)而發(fā)揚光大，主要用于將性能分析工具生成的數(shù)據(jù)進(jìn)行可視化處理，方便開發(fā)人員一眼就能定位到性能問題所在。火焰圖的使用較為簡單，我們僅需將一系列工具從github上下載下來，置于本地任一目錄即可：

wget https://github.com/brendangregg/FlameGraph/archive/master.zipunzip master.zip

3.1、CPU火焰圖

當(dāng)我們發(fā)現(xiàn)FISCO BCOS性能較低時，直覺上會想弄清楚到底是哪一部分的代碼拖慢了整體速度，CPU是我們的首要考察對象。

首先使用perf對FISCO BCOS進(jìn)程進(jìn)行性能采樣：

sudo perf record  -F 10000 -p `pidof fisco-bcos` -g -- sleep 60# 對采樣數(shù)據(jù)文件進(jìn)行解析生成堆棧信息sudo perf script > cpu.unfold

生成了采樣數(shù)據(jù)文件后，接下來調(diào)用火焰圖工具生成火焰圖：

# 對perf.unfold進(jìn)行符號折疊sudo ./stackcollapse-perf.pl cpu.unfold > cpu.folded# 生成SVG格式的火焰圖sudo ./flamegraph.pl  cpu.folded > cpu.svg

最后輸出一個SVG格式圖片，用來展示CPU的調(diào)用棧，如下圖所示：

縱軸表示調(diào)用棧。每一層都是一個函數(shù)，也是其上一層的父函數(shù)，最頂部就是采樣時正在執(zhí)行的函數(shù)，調(diào)用棧越深，火焰就越高。

橫軸表示抽樣數(shù)。注意，并不是表示執(zhí)行時間。若一個函數(shù)的寬度越寬，則表示它被抽到的次數(shù)越多，所有調(diào)用棧會在匯總后，按字母序列排列在橫軸上。

火焰圖使用了SVG格式，可交互性大大提高。在瀏覽器中打開時，火焰的每一層都會標(biāo)注函數(shù)名，當(dāng)鼠標(biāo)懸浮其上，會顯示完整的函數(shù)名、被抽樣次數(shù)和占總抽樣字?jǐn)?shù)的百分比，如下：

點擊某一層時，火焰圖會水平放大，該層會占據(jù)所有寬度，并顯示詳細(xì)信息，點擊左上角的『Reset Zoom』即可還原。下圖展示了PBFT模塊在執(zhí)行區(qū)塊時，各個函數(shù)的抽樣數(shù)占比：

從圖中可以看出，在執(zhí)行區(qū)塊時，主要開銷在交易的解碼中，這是由于傳統(tǒng)的RLP編碼在解碼時，RLP編碼中每個對象的長度不確定，且RLP編碼只記錄了對象的個數(shù)，沒記錄對象的字節(jié)長度，若要獲取其中的一個編碼對象，必須遞歸解碼其前序的所有對象。

因此，RLP編碼的解碼過程是一個串行的過程，當(dāng)區(qū)塊中交易數(shù)量較大時，這一部分的開銷將變得十分巨大。對此，我們提出了一種并行解碼RLP編碼的優(yōu)化方案，具體實現(xiàn)細(xì)節(jié)可以參考上一篇文章《FISCO BCOS中的并行化實踐 》。

有了火焰圖，能夠非常方便地查看CPU的大部分時間開銷都消耗在何處，進(jìn)而也能針對性進(jìn)行優(yōu)化了。

3.2、Off-CPU火焰圖

在實現(xiàn)FISCO BCOS的并行執(zhí)行交易功能時，我們發(fā)現(xiàn)有一個令人困惑的現(xiàn)象：有時即使交易量非常大，區(qū)塊的負(fù)載已經(jīng)打滿，但是通過top命令觀察到CPU的利用率仍然比較低，通常4核CPU的利用率不足200%。在排除了交易間存在依賴關(guān)系的可能后，推測CPU可能陷入了I/O或鎖等待中，因此需要確定CPU到底在什么地方等待。

使用perf，我們可以輕松地了解系統(tǒng)中任何進(jìn)程的睡眠過程，其原理是利用perf static tracer抓取進(jìn)程的調(diào)度事件，并通過perf inject對這些事件進(jìn)行合并，最終得到誘發(fā)進(jìn)程睡眠的調(diào)用流程以及睡眠時間。

我們要通過perf分別記錄sched:sched_stat_sleep、sched:sched_switch、sched:sched_process_exit三種事件，這三種事件分別表示進(jìn)程主動放棄 CPU 而進(jìn)入睡眠的等待事件、進(jìn)程由于I/O和鎖等待等原因被調(diào)度器切換而進(jìn)入睡眠的等待事件、進(jìn)程的退出事件。

perf record -e sched:sched_stat_sleep -e sched:sched_switch \-e sched:sched_process_exit -p `pidof fisco-bcos` -g \-o perf.data.raw sleep 60perf inject -v -s -i perf.data.raw -o perf.data# 生成Off-CPU火焰圖perf script -f comm,pid,tid,cpu,time,period,event,ip,sym,dso,trace | awk '    NF > 4 { exec = $1; period_ms = int($5 / 1000000) }    NF > 1 && NF <= 4 && period_ms > 0 { print $2 }    NF < 2 && period_ms > 0 { printf "%s\n%d\n\n", exec, period_ms }' | \./stackcollapse.pl | \./flamegraph.pl --countname=ms --title="Off-CPU Time Flame Graph" --colors=io > offcpu.svg

在較新的Ubuntu或CentOS系統(tǒng)中，上述命令可能會失效，出于性能考慮，這些系統(tǒng)并不支持記錄調(diào)度事件。好在我們可以選擇另一種profile工具——OpenResty的SystemTap，來替代perf幫助我們收集進(jìn)程調(diào)度器的性能數(shù)據(jù)。我們在CentOS下使用SystemTap時，只需要安裝一些依賴kenerl debuginfo即可使用。

wget https://raw.githubusercontent.com/openresty/openresty-systemtap-toolkit/master/sample-bt-off-cpuchmod +x sample-bt-off-cpu./sample-bt-off-cpu -t 60 -p `pidof fisco-bcos` -u > out.stap./stackcollapse-stap.pl out.stap > out.folded./flamegraph.pl --colors=io out.folded > offcpu.svg

得到的Off-CPU火焰圖如下圖所示：

展開執(zhí)行交易的核心函數(shù)后，位于火焰圖中右側(cè)的一堆lock_wait很快引起了我們的注意。分析過它們的調(diào)用棧后，我們發(fā)現(xiàn)這些lock_wait的根源，來自于我們在程序中有大量打印debug日志的行為。

在早期開發(fā)階段，我們?yōu)榱朔奖阏{(diào)試，添加了很多日志代碼，后續(xù)也沒有刪除。雖然我們在測試過程中將日志等級設(shè)置得較高，但這些日志相關(guān)的代碼仍會產(chǎn)生運行時開銷，如訪問日志等級狀態(tài)來決定是否打印日志等。由于這些狀態(tài)需要線程間互斥訪問，因此導(dǎo)致線程由于競爭資源而陷入饑餓。

我們將這些日志代碼刪除后，執(zhí)行交易時4核CPU的利用率瞬間升至300%+，考慮到線程間調(diào)度和同步的開銷，這個利用率已屬于正常范圍。這次調(diào)試的經(jīng)歷也提醒了我們，在追求高性能的并行代碼中輸出日志一定要謹(jǐn)慎，避免由于不必要的日志而引入無謂的性能損失。

3.3 、內(nèi)存火焰圖

在FISCO BCOS早期測試階段，我們采取的測試方式是反復(fù)執(zhí)行同一區(qū)塊，再計算執(zhí)行一個區(qū)塊平均耗時，我們發(fā)現(xiàn)，第一次執(zhí)行區(qū)塊的耗時會遠(yuǎn)遠(yuǎn)高于后續(xù)執(zhí)行區(qū)塊的耗時。從表象上看，這似乎是在第一次執(zhí)行區(qū)塊時，程序在某處分配了緩存，然而我們并不知道具體是在何處分配的緩存，因此我們著手研究了內(nèi)存火焰圖。

內(nèi)存火焰圖是一種非侵入式的旁路分析方法，相較于模擬運行進(jìn)行內(nèi)存分析的Valgrid和統(tǒng)計heap使用情況的TC Malloc，內(nèi)存火焰圖可以在獲取目標(biāo)進(jìn)程的內(nèi)存分配情況的同時不干擾程序的運行。

制作內(nèi)存火焰圖，首先需要向perf動態(tài)添加探針以監(jiān)控標(biāo)準(zhǔn)庫的malloc行為，并采樣捕捉正在進(jìn)行內(nèi)存申請/釋放的函數(shù)的調(diào)用堆棧：

perf record -e probe_libc:malloc -F 1000 -p `pidof fisco-bcos` -g -- sleep 60

然后繪制內(nèi)存火焰圖：

perf script > memory.perf./stackcollapse-perf.pl memory.perf > memory.folded./flamegraph.pl  --colors=mem memory.folded > memory.svg

得到的火焰圖如下圖所示：

我們起初猜想，這塊未知的緩存可能位于LevelDB的數(shù)據(jù)庫連接模塊或JSON解碼模塊中，但通過比對第一次執(zhí)行區(qū)塊和后續(xù)執(zhí)行區(qū)塊的內(nèi)存火焰圖，我們發(fā)現(xiàn)各個模塊中malloc采樣數(shù)目的比例大致相同，因此很快便將這些猜想否定掉了。直到結(jié)合Off-CPU火焰圖觀察，我們才注意到第一次執(zhí)行區(qū)塊時調(diào)用sysmalloc的次數(shù)異常之高。聯(lián)想到malloc會在首次被調(diào)用時進(jìn)行內(nèi)存預(yù)分配的特性，我們猜想第一次執(zhí)行區(qū)塊耗時較多可能就是由此造成的。

為驗證猜想，我們將malloc的預(yù)分配空間上限調(diào)低：

export MALLOC_ARENA_MAX=1

然后再次進(jìn)行測試并繪制Off-CPU火焰圖，發(fā)現(xiàn)雖然性能有所降低，但是第一次執(zhí)行區(qū)塊的耗時和sysmalloc調(diào)用次數(shù)，基本無異于之后執(zhí)行的區(qū)塊。據(jù)此，我們基本可以斷定這種有趣的現(xiàn)象是由于malloc的內(nèi)存預(yù)分配行為導(dǎo)致。

當(dāng)然，這種行為是操作系統(tǒng)為了提高程序整體性能而引入的，我們無需對其進(jìn)行干涉，況且第一個區(qū)塊的執(zhí)行速度較慢，對用戶體驗幾乎也不會造成負(fù)面影響，但是再小的性能問題也是問題，作為開發(fā)人員我們應(yīng)當(dāng)刨根問底，做到知其然且知其所以然。

雖然這次Memory火焰圖并沒有幫我們直接定位到問題的本質(zhì)原因，但通過直觀的數(shù)據(jù)比對，我們能夠方便地排除錯誤的原因猜想，減少了大量的試錯成本。面對復(fù)雜的內(nèi)存問題，不僅需要有敏銳的嗅覺，更需要Memory火焰圖這類好幫手。

4.DIY工具

盡管已經(jīng)有如此多優(yōu)秀的分析工具，幫助我們在性能優(yōu)化前進(jìn)的道路上披荊斬棘，但強(qiáng)大的功能有時也會趕不上性能問題的多變性，這種時候就需要我們結(jié)合自身的需求，自給自足地開發(fā)分析工具。

在進(jìn)行FISCO BCOS的穩(wěn)定性測試時，我們發(fā)現(xiàn)隨著測試時間的增長，F(xiàn)ISCO BCOS節(jié)點的性能呈現(xiàn)衰減趨勢，我們需要得到所有模塊的性能趨勢變化圖，以排查出導(dǎo)致性能衰減的元兇，但現(xiàn)有的性能分析工具基本無法快速、便捷地實現(xiàn)這一需求，因此我們選擇另尋他路。

首先，我們在代碼中插入大量的樁點，這些樁點用于測量我們感興趣的代碼段的執(zhí)行耗時，并將其附加上特殊的標(biāo)識符記錄于日志中：

auto startTime = utcTime();/*...code to be measured...*/auto endTime = utcTime();auto elapsedTime = endTime - startTime;LOG(DEBUG) << MESSAGE("<identifier>timeCost: ") \  << MESSAGE(to_string(elspasedTime));

當(dāng)節(jié)點性能已經(jīng)開始明顯下降后，我們將其日志導(dǎo)出，使用自己編寫的Python腳本將日志以區(qū)塊為單位進(jìn)行分割，隨后讀取每個區(qū)塊在執(zhí)行時產(chǎn)生的樁點日志，并解析出各個階段的耗時，然后由腳本匯總到一張大的Excel表格中，最后再直接利用Excel自帶的圖表功能，繪制出所有模塊的性能趨勢變化圖，如下圖所示：

其中，橫坐標(biāo)為區(qū)塊高度，縱坐標(biāo)為執(zhí)行耗時（ms），不同顏色曲線代表了不同模塊的性能變化。

從圖中可以看出，只有由紅色曲線代表的區(qū)塊落盤模塊的執(zhí)行耗時明顯地隨著數(shù)據(jù)庫中數(shù)據(jù)量的增大而迅速增加，由此可以判斷節(jié)點性能衰減問題的根源就出在區(qū)塊落盤模塊中。使用同樣的方式，對區(qū)塊落盤模塊的各個函數(shù)進(jìn)一步剖析，我們發(fā)現(xiàn)節(jié)點在向數(shù)據(jù)庫提交新的區(qū)塊數(shù)據(jù)時，調(diào)用的是LevelDB的update方法，并非insert方法。

兩者的區(qū)別是，由于LevelDB以K-V的形式存儲數(shù)據(jù)，update方法在寫入數(shù)據(jù)前會進(jìn)行select操作，因為待update的數(shù)據(jù)可能在數(shù)據(jù)庫中已存在，需要先按Key查詢出Value的數(shù)據(jù)結(jié)構(gòu)才能進(jìn)行修改，而查詢的耗時與數(shù)據(jù)量成正比，insert方法則完全不需要這一步。由于我們寫入的是全新的數(shù)據(jù)，因此查詢這一步是不必要的，只需改變數(shù)據(jù)寫入的方式，節(jié)點性能衰減的問題便迎刃而解。

相同的工具稍微變換一下用法，就能衍生出其他的用途，比如：將兩批樁點性能數(shù)據(jù)放入同一張Excel表格中，便能夠通過柱狀圖工具清晰地展現(xiàn)兩次測試結(jié)果的性能變化。

下圖展示的是我們在優(yōu)化交易解碼及驗簽流程時，優(yōu)化前后性能柱狀對比圖：

從圖中可以看出，交易解碼和驗簽流程優(yōu)化后的耗時的確比優(yōu)化前有所降低。借由柱狀對比圖，我們能夠輕松地檢查優(yōu)化手段是否行之有效，這一點在性能優(yōu)化的過程中起到了重要的指導(dǎo)作用。

上述就是小編為大家分享的FISCO BCOS工程師常用的性能分析工具有什么了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

本文標(biāo)題：FISCOBCOS工程師常用的性能分析工具有什么
本文鏈接：http://chinadenli.net/article48/ggjhep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、網(wǎng)站導(dǎo)航、網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、App設(shè)計、營銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)