共計(jì) 9498 個(gè)字符，預(yù)計(jì)需要花費(fèi) 24 分鐘才能閱讀完成。
今天就跟大家聊聊有關(guān)如何進(jìn)行 Linux 的性能分析，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
當(dāng)你登陸一臺(tái) Linux 服務(wù)器之后，因?yàn)橐粋€(gè)問題要做性能分析時(shí)：你會(huì)在第 1 分鐘內(nèi)做哪些檢測(cè)呢?
在 Netflix，我們有很多 EC2 的 Linux 機(jī)器，并且也需要很多性能分析工具來監(jiān)控和檢查它們的性能。包括有針對(duì)云上的監(jiān)控工具 Atlas，和按需要進(jìn)行實(shí)例分析的 Vector。雖然這些工具能幫助我們解決大多數(shù)問題，但是我們有時(shí)候還需要登陸機(jī)器實(shí)例去運(yùn)行一些標(biāo)準(zhǔn)的 Linux 性能分析工具。
最開始的 60 秒：總結(jié)
在這篇文章中，Netflix 的性能分析工程師團(tuán)隊(duì)會(huì)給你展示在最開始的 60 秒內(nèi)，如何在命令行模式下使用已有的 Linux 標(biāo)準(zhǔn)工具進(jìn)行性能優(yōu)化檢測(cè)。在 60 秒內(nèi)只需要通過運(yùn)行下面的 10 個(gè)命令就可以對(duì)系統(tǒng)資源使用和運(yùn)行進(jìn)程有一個(gè)很高程度的了解。尋找錯(cuò)誤信息和飽和度指標(biāo)，并且可以顯示為請(qǐng)求隊(duì)列的長度，或者等待時(shí)長。因?yàn)樗鼈兌己苋菀桌斫猓缓缶褪琴Y源利用率。飽和度是指一個(gè)資源已經(jīng)超過了它自己的負(fù)荷能力。
uptime dmesg | tail vmstat 1 mpstat -P ALL 1 pidstat 1 iostat -xz 1 free -m sar -n DEV 1 sar -n TCP,ETCP 1 top有些命令需要安裝 sysstat 工具包。這些命令展示的指標(biāo)會(huì)幫助你完成一些 USE(Utilization，Saturation，Errors) 方法：定位性能瓶頸的方法論。包括了檢查使用率 (Utilization)，飽和度(Saturation)，所有資源(比如 CPU，內(nèi)存，磁盤等) 的錯(cuò)誤指標(biāo)(Errors)。同樣也要關(guān)注你什么時(shí)候檢查和排除一個(gè)資源問題，因?yàn)橥ㄟ^排除可以縮小分析范圍，同時(shí)也指導(dǎo)了任何后續(xù)的檢查。
下面的章節(jié)將會(huì)通過一個(gè)生產(chǎn)系統(tǒng)中的例子來介紹這些命令。要了解更多這些工具的信息，也可以查看它們的幫助手冊(cè)。
1. uptime
$ uptime 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02這是一個(gè)快速展示系統(tǒng)平均負(fù)載的方法，這也指出了等待運(yùn)行進(jìn)程的數(shù)量。在 Linux 系統(tǒng)中，這些數(shù)字包括等待 CPU 運(yùn)行的進(jìn)程數(shù)，也包括了被不可中斷 I/O(通常是磁盤 I/O)阻塞的進(jìn)程。這給出了資源負(fù)載的很直接的展示，可以在沒有其它工具的幫助下更好的理解這些數(shù)據(jù)。它是唯一快捷的查看系統(tǒng)負(fù)載的方式。
這三個(gè)數(shù)字是以遞減的方式統(tǒng)計(jì)了過去 1 分鐘，5 分鐘和 15 分鐘常數(shù)的平均數(shù)。這三個(gè)數(shù)字給我們直觀展示了隨著時(shí)間的變化系統(tǒng)負(fù)載如何變化。例如，如果你被叫去查看一個(gè)有問題的服務(wù)器，并且 1 分鐘的所代表的值比 15 分鐘的值低很多，那么你可能由于太遲登陸機(jī)器而錯(cuò)過了問題發(fā)生的時(shí)間點(diǎn)。
在上面的例子中，平均負(fù)載顯示是在不斷增加的，1 分鐘的值是 30，相比 15 分鐘的值 19 來說是增加了。這個(gè)數(shù)字這么大就意味著有事情發(fā)生了：可能是 CPU 需求;vmstat 或者 mpstat 會(huì)幫助確認(rèn)到底是什么，這些命令會(huì)在本系列的第 3 和第 4 個(gè)命令中介紹。
2. dmesg | tail
$ dmesg | tail [1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0 [...] [1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child [1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB [2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.這里展示的是最近 10 條系統(tǒng)消息日志，如果系統(tǒng)消息沒有就不會(huì)展示。主要是看由于性能問題導(dǎo)致的錯(cuò)誤。上面這個(gè)例子中包含了殺死 OOM 問題的進(jìn)程，丟棄 TCP 請(qǐng)求的問題。
所以要記得使用這個(gè)命令，dmesg 命令值得一用。
3. vmstat 1
$ vmstat 1 procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0 32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0 32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0 32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0 32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0 ^C對(duì)虛擬內(nèi)存統(tǒng)計(jì)的簡短展示，vmstat 是一個(gè)常用工具(最早是幾十年前為 BSD 創(chuàng)建的)。它每一行打印關(guān)鍵的服務(wù)信息統(tǒng)計(jì)摘要。
vmstat 使用參數(shù) 1 來運(yùn)行的時(shí)候，是每 1 秒打印一條統(tǒng)計(jì)信息。在這個(gè)版本的 vmstat 中，輸出的第一行展示的是自從啟動(dòng)后的平均值，而不是前一秒的統(tǒng)計(jì)。所以現(xiàn)在，可以跳過第一行，除非你要看一下抬頭的字段含義。
每列含義說明：
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS 技術(shù)社區(qū)
r: CPU 上的等待運(yùn)行的可運(yùn)行進(jìn)程數(shù)。這個(gè)指標(biāo)提供了判斷 CPU 飽和度的數(shù)據(jù)，因?yàn)樗话?I/O 等待的進(jìn)程。可解釋為：“r”的值比 CPU 數(shù)大的時(shí)候就是飽和的。
free：空閑內(nèi)存，單位是 k。如果這個(gè)數(shù)比較大，就說明你還有充足的空閑內(nèi)存。“free -m”和下面第 7 個(gè)命令，可以更詳細(xì)的分析空閑內(nèi)存的狀態(tài)。
si，so：交換進(jìn)來和交換出去的數(shù)據(jù)量，如果這兩個(gè)值為非 0 值，那么就說明沒有內(nèi)存了。
us，sy，id，wa，st：這些是 CPU 時(shí)間的分解，是所有 CPU 的平均值。它們是用戶時(shí)間，系統(tǒng)時(shí)間(內(nèi)核)，空閑，等待 I/O 時(shí)間，和被偷的時(shí)間(這里主要指其它的客戶，或者使用 Xen，這些客戶有自己獨(dú)立的操作域)。
CPU 時(shí)間的分解可以幫助確定 CPU 是不是非常忙(通過用戶時(shí)間和系統(tǒng)時(shí)間累加判斷)。持續(xù)的 I/O 等待則表明磁盤是瓶頸。這種情況下 CPU 是比較空閑的，因?yàn)槿蝿?wù)都由于等待磁盤 I/O 而被阻塞。你可以把等待 I/O 看作是另外一種形式的 CPU 空閑，而這個(gè)命令給了為什么它們空閑的線索。
系統(tǒng)時(shí)間對(duì)于 I/O 處理來說是必須的。比較高的平均系統(tǒng)時(shí)間消耗，比如超過了 20%，就有必要進(jìn)一步探索分析了：也有可能是內(nèi)核處理 I/O 效率不夠高導(dǎo)致。
在上面的例子中，CPU 時(shí)間幾乎都是用戶級(jí)別的，說明這是一個(gè)應(yīng)用級(jí)別的使用情況。如果 CPU 的使用率平均都超過了 90%。這不一定問題; 可以使用“r” 列來檢查使用飽和度。
4. mpstat -p ALL 1
$ mpstat -P ALL 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78 07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99 07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00 07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03 [...]這個(gè)命令打印各個(gè) CPU 的時(shí)間統(tǒng)計(jì)，可以看出整體 CPU 的使用是不是均衡的。有一個(gè)使用率明顯較高的 CPU 就可以明顯看出來這是一個(gè)單線程應(yīng)用。
5. pidstat 1
$ pidstat 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 07:41:02 PM UID PID %usr %system %guest %CPU CPU Command 07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0 07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave 07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java 07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java 07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java 07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat 07:41:03 PM UID PID %usr %system %guest %CPU CPU Command 07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave 07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java 07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java 07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass 07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat ^Cpidstat 命令有點(diǎn)像 top 命令中的為每個(gè) CPU 統(tǒng)計(jì)信息功能，但是它是以不斷滾動(dòng)更新的方式打印信息，而不是每次清屏打印。這個(gè)對(duì)于觀察隨時(shí)間變化的模式很有用，同時(shí)把你看到的信息 (復(fù)制粘貼) 記到你的調(diào)查記錄中。
上面的例子可以看出是 2 個(gè) java 進(jìn)程在消耗 CPU。%CPU 列是所有 CPU 的使用率;1591% 是說明這個(gè) java 進(jìn)程消耗了幾乎 16 個(gè) CPU 核。
6. iostat -xz 1
$ iostat -xz 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 73.96 0.00 3.73 0.03 0.06 22.21 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09 xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25 xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26 dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04 dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00 dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03 [...] ^C這個(gè)工具對(duì)于理解塊設(shè)備 (比如磁盤) 很有用，展示了請(qǐng)求負(fù)載和性能數(shù)據(jù)。具體的數(shù)據(jù)看下面字段的解釋：
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS 技術(shù)社區(qū)
r/s, w/s, rkB/s, wkB/s：這些表示設(shè)備上每秒鐘的讀寫次數(shù)和讀寫的字節(jié)數(shù)(單位是 k 字節(jié))。這些可以看出設(shè)備的負(fù)載情況。性能問題可能就是簡單的因?yàn)榇罅康奈募虞d請(qǐng)求。
await：I/O 等待的平均時(shí)間(單位是毫秒)。這是應(yīng)用程序所等待的時(shí)間，包含了等待隊(duì)列中的時(shí)間和被調(diào)度服務(wù)的時(shí)間。過大的平均等待時(shí)間就預(yù)示著設(shè)備超負(fù)荷了或者說設(shè)備有問題了。
avgqu-sz：設(shè)備上請(qǐng)求的平均數(shù)。數(shù)值大于 1 可能表示設(shè)備飽和了(雖然設(shè)備通常都是可以支持并行請(qǐng)求的，特別是在背后掛了多個(gè)磁盤的虛擬設(shè)備)。
%util：設(shè)備利用率。是使用率的百分?jǐn)?shù)，展示每秒鐘設(shè)備工作的時(shí)間。這個(gè)數(shù)值大于 60% 則會(huì)導(dǎo)致性能很低(可以在 await 中看)，當(dāng)然這也取決于設(shè)備特點(diǎn)。這個(gè)數(shù)值接近 100% 則表示設(shè)備飽和了。
如果存儲(chǔ)設(shè)備是一個(gè)邏輯磁盤設(shè)備，后面掛載了多個(gè)磁盤，那么 100% 的利用率則只是表示有些 I/O 是在 100% 處理，然而后端的磁盤或許遠(yuǎn)遠(yuǎn)沒有飽和，還可以處理更多的請(qǐng)求。
請(qǐng)記住，磁盤 I/O 性能低不一定是應(yīng)用程序的問題。許多技術(shù)通常都被用來實(shí)現(xiàn)異步執(zhí)行 I/O，所以應(yīng)用程序不會(huì)直接阻塞和承受延時(shí)(比如：預(yù)讀取和寫緩沖技術(shù))。
7. free -m
$ free -m total used free shared buffers cached Mem: 245998 24545 221453 83 59 541 -/+ buffers/cache: 23944 222053 Swap:右面兩列展示的是：
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS 技術(shù)社區(qū)
buffers：用于塊設(shè)備 I/O 緩沖的緩存。
cached：用于文件系統(tǒng)的頁緩存。
我們只想檢測(cè)這些緩存的數(shù)值是否接近 0。不為 0 的可能導(dǎo)致較高的磁盤 I/O(通過 iostat 命令來確認(rèn))和較差的性能問題。上面的例子看起來沒問題，都還有很多 M 字節(jié)。
“-/+ buffers/cache”這一行提供了對(duì)已使用和空閑內(nèi)存明確的統(tǒng)計(jì)。Linux 用空閑內(nèi)存作為緩存，如果應(yīng)用程序需要，可以快速拿回去。所以應(yīng)該包含空閑內(nèi)存那一列，這里就是這么統(tǒng)計(jì)的。甚至有一個(gè)網(wǎng)站專門來介紹 Linux 內(nèi)存消耗的問題：linuxatemyram。
如果在 Linux 上使用了 ZFS 文件系統(tǒng)，則可能會(huì)更亂，因?yàn)楫?dāng)我們?cè)陂_發(fā)一些服務(wù)的時(shí)候，ZFS 有它自己的文件系統(tǒng)緩存，而這部分內(nèi)存的消耗是不會(huì)在 free -m 這個(gè)命令中合理的反映的。顯示了系統(tǒng)內(nèi)存不足，但是 ZFS 的這部分緩存是可以被應(yīng)用程序使用的。
8. sar -n DEV 1
$ sar -n DEV 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00 12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00 12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00 12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00 12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 ^C使用這個(gè)工具是可以檢測(cè)網(wǎng)絡(luò)接口的吞吐：rxkB/s 和 txkB/s，作為收發(fā)數(shù)據(jù)負(fù)載的度量，也是檢測(cè)是否達(dá)到收發(fā)極限。在上面這個(gè)例子中，eth0 接收數(shù)據(jù)達(dá)到 22 M 字節(jié) / 秒，也就是 176 Mbit/ 秒(網(wǎng)卡的上限是 1 Gbit/ 秒)。
這個(gè)版本的工具還有一個(gè)統(tǒng)計(jì)字段: %ifutil，用于統(tǒng)計(jì)設(shè)備利用率(全雙工雙向最大值)，這個(gè)利用率也可以使用 Brendan 的 nicstat 工具來測(cè)量統(tǒng)計(jì)。在這個(gè)例子中 0.00 這種情況就似乎就是沒有統(tǒng)計(jì)，這個(gè)和 nicstat 一樣，這個(gè)值是比較難統(tǒng)計(jì)正確的。
9. sar -n TCP,ETCP 1
$ sar -n TCP,ETCP 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 12:17:19 AM active/s passive/s iseg/s oseg/s 12:17:20 AM 1.00 0.00 10233.00 18846.00 12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s 12:17:20 AM 0.00 0.00 0.00 0.00 0.00 12:17:20 AM active/s passive/s iseg/s oseg/s 12:17:21 AM 1.00 0.00 8359.00 6039.00 12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s 12:17:21 AM 0.00 0.00 0.00 0.00 0.00 ^C這是對(duì) TCP 關(guān)鍵指標(biāo)的統(tǒng)計(jì)，它包含了以下內(nèi)容：
active/s：每秒本地發(fā)起的 TCP 連接數(shù)(例如通過 connect() 發(fā)起的連接)。
passive/s：每秒遠(yuǎn)程發(fā)起的連接數(shù)(例如通過 accept() 接受的連接)。
retrans/s：每秒 TCP 重傳數(shù)。
這種主動(dòng)和被動(dòng)統(tǒng)計(jì)數(shù)通常用作對(duì)系統(tǒng)負(fù)載的粗略估計(jì)：新接受連接數(shù)(被動(dòng))，下游連接數(shù)(主動(dòng))。可以把主動(dòng)看作是外部的，被動(dòng)的是內(nèi)部，但是這個(gè)通常也不是非常準(zhǔn)確(例如：當(dāng)有本地到本地的連接時(shí))。
重傳是網(wǎng)絡(luò)或者服務(wù)器有問題的一個(gè)信號(hào); 可能是一個(gè)不可靠的網(wǎng)絡(luò)(例如：公網(wǎng))，或者可能是因?yàn)榉?wù)器過載了開始丟包。上面這個(gè)例子可以看出是每秒新建一個(gè) TCP 連接。
10. top
$ top top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92 Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie %Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java 4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave 66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top 5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java 4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java 1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0 8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_schedtop 命令包含了很多我們前面提到的指標(biāo)。這個(gè)命令可以很容易看出指標(biāo)的變化表示負(fù)載的變化，這個(gè)看起來和前面的命令有很大不同。
top 的一個(gè)缺陷也比較明顯，很難看出變化趨勢(shì)，其它像 vmstat 和 pidstat 這樣的工具就會(huì)很清晰，它們是以滾動(dòng)的方式輸出統(tǒng)計(jì)信息。所以如果你在看到有問題的信息時(shí)沒有及時(shí)的暫停下來(Ctrl-S 是暫停, Ctrl-Q 是繼續(xù))，那么這些有用的信息就會(huì)被清屏。
Follow-on Analysis
還有很多可以使用來深挖系統(tǒng)問題的命令和技術(shù)，可以看看 Brendan 在 2015 年講的 Linux 性能工具介紹，這里面講述了 40 多個(gè)命令，涵蓋了可觀測(cè)性，基準(zhǔn)測(cè)試，調(diào)優(yōu)，靜態(tài)性能調(diào)優(yōu)，分析和跟蹤等多個(gè)方面。
看完上述內(nèi)容，你們對(duì)如何進(jìn)行 Linux 的性能分析有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道，感謝大家的支持。
