FISCO BCOS工程師常用的性能分析工具有什么

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

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

前 言

『過(guò)早的優(yōu)化是萬(wàn)惡之源』

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

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

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

1.Poor Man's Profiler

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

第一步，獲取一定數(shù)量的線程堆?？煺眨?/p>

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全部精華之所在。極度簡(jiǎn)單易用是PMP的最大賣(mài)點(diǎn)，除了依賴一個(gè)隨處可見(jiàn)的調(diào)試器外，PMP不需要安裝任何組件，正如PMP作者在介紹中所言：『盡管存在更高級(jí)的分析技術(shù)，但毫無(wú)例外它們安裝起來(lái)都太麻煩了……Poor man doesn't have time. Poor man needs food.』????。

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

但是在某些特殊場(chǎng)合，PMP還是能發(fā)揮作用的，比如在一些中文技術(shù)博客中，就有開(kāi)發(fā)人員提到使用PMP成功定位出了線上生產(chǎn)環(huán)境中的死鎖問(wèn)題，PMP作者也稱這項(xiàng)技術(shù)在Facebook、Intel等大廠中有所應(yīng)用。不管怎樣，這種閃爍著程序員小智慧又帶點(diǎn)小幽默的技術(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)核性能計(jì)數(shù)器統(tǒng)計(jì)性能數(shù)據(jù)。

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

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

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

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

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

$ perf report -n

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

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

3.火焰圖

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

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

3.1、CPU火焰圖

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2、Off-CPU火焰圖

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

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

我們要通過(guò)perf分別記錄sched:sched_stat_sleep、sched:sched_switch、sched:sched_process_exit三種事件，這三種事件分別表示進(jìn)程主動(dòng)放棄 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)中，上述命令可能會(huì)失效，出于性能考慮，這些系統(tǒng)并不支持記錄調(diào)度事件。好在我們可以選擇另一種profile工具——OpenResty的SystemTap，來(lái)替代perf幫助我們收集進(jìn)程調(diào)度器的性能數(shù)據(jù)。我們?cè)贑entOS下使用SystemTap時(shí)，只需要安裝一些依賴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火焰圖如下圖所示：

展開(kāi)執(zhí)行交易的核心函數(shù)后，位于火焰圖中右側(cè)的一堆lock_wait很快引起了我們的注意。分析過(guò)它們的調(diào)用棧后，我們發(fā)現(xiàn)這些lock_wait的根源，來(lái)自于我們?cè)诔绦蛑杏写罅看蛴ebug日志的行為。

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

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

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

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

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

制作內(nèi)存火焰圖，首先需要向perf動(dòng)態(tài)添加探針以監(jiān)控標(biāo)準(zhǔn)庫(kù)的malloc行為，并采樣捕捉正在進(jìn)行內(nèi)存申請(qǐng)/釋放的函數(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ù)庫(kù)連接模塊或JSON解碼模塊中，但通過(guò)比對(duì)第一次執(zhí)行區(qū)塊和后續(xù)執(zhí)行區(qū)塊的內(nèi)存火焰圖，我們發(fā)現(xiàn)各個(gè)模塊中malloc采樣數(shù)目的比例大致相同，因此很快便將這些猜想否定掉了。直到結(jié)合Off-CPU火焰圖觀察，我們才注意到第一次執(zhí)行區(qū)塊時(shí)調(diào)用sysmalloc的次數(shù)異常之高。聯(lián)想到malloc會(huì)在首次被調(diào)用時(shí)進(jìn)行內(nèi)存預(yù)分配的特性，我們猜想第一次執(zhí)行區(qū)塊耗時(shí)較多可能就是由此造成的。

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

export MALLOC_ARENA_MAX=1

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

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

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

4.DIY工具

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

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

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

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

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

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

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

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

下圖展示的是我們?cè)趦?yōu)化交易解碼及驗(yàn)簽流程時(shí)，優(yōu)化前后性能柱狀對(duì)比圖：

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

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