性能分析之大屏可視化平臺(tái)瓶頸分析（window版）

1.??背景

大屏展示的可視化平臺(tái)以交互性圖像顯示技術(shù)為核心，結(jié)合各業(yè)務(wù)流程、指標(biāo)體系的信息化建設(shè)成果，實(shí)現(xiàn)了對(duì)生產(chǎn)與經(jīng)營(yíng)信息全方位集中監(jiān)控和多角度的全景式信息展示，為創(chuàng)建高效企業(yè)管控提供了載體。

本可視化平臺(tái)采用開(kāi)放式框架設(shè)計(jì)，充分汲取了目前成熟的技術(shù)成果，建立了以數(shù)據(jù)服務(wù)、設(shè)計(jì)工具、播放控制、交互管理、主題場(chǎng)景應(yīng)用為核心的平臺(tái)體系，為大屏系統(tǒng)、桌面系統(tǒng)和移動(dòng)終端搭建了統(tǒng)一的可視化部署應(yīng)用。

2.??運(yùn)行環(huán)境

2.1.??硬件環(huán)境

服務(wù)器類型

機(jī)器名

配置說(shuō)明

應(yīng)用服務(wù)器

WIN-8PEK4VLQU8R

CPU: Inter Xeon(R) E7- 4830@ 2.13GHz_ HTT/CMP單元8 /8

內(nèi)存:32G

硬盤(pán):300G

2.2.??網(wǎng)絡(luò)環(huán)境

網(wǎng)絡(luò)類型

寬帶

設(shè)備

局域網(wǎng)

1000M

企業(yè)級(jí)千兆交換機(jī)

2.3.??系統(tǒng)架構(gòu)

3.??性能監(jiān)控

3.1.??監(jiān)控設(shè)計(jì)

通過(guò)Spotlighton window收集應(yīng)用服務(wù)器window性能數(shù)據(jù)，采樣周期7x24小時(shí)不間斷，系統(tǒng)監(jiān)控期間正常運(yùn)行，如下圖。

4.??告警分析

通過(guò)對(duì)告警日志（即Alarmlog）整理，我們抽樣的時(shí)間段為2014/5/309:41:00~2014/6/6? 9:39:00，這其中共產(chǎn)生9563條告警日志。通過(guò)簡(jiǎn)單按嚴(yán)重程序排序，我們可以發(fā)現(xiàn)其中存在許多的嚴(yán)重級(jí)別的告警，如下圖。

為了分析嚴(yán)重級(jí)別告警的類別，我們導(dǎo)出了相關(guān)日志并對(duì)最嚴(yán)重級(jí)進(jìn)行了篩選整理，結(jié)果發(fā)現(xiàn)9563條告警中，嚴(yán)重級(jí)別的告警存在195條記錄。

最后，通過(guò)對(duì)嚴(yán)重級(jí)別告警日志歸納整理，我們得出了主要以下兩個(gè)方面問(wèn)題：

1.?????Pagereads/sec過(guò)高且頻繁（告警174次）

2.?????單線程CPU Usage達(dá)到100%（告警21次）

截圖如下：

5.??問(wèn)題分析

5.1.??Page reads/sec過(guò)高且頻繁

操作系統(tǒng)會(huì)利用磁盤(pán)較好的方式提高系統(tǒng)可用內(nèi)存量或者提高內(nèi)存的使用效率Pages Read直接反應(yīng)了操作系統(tǒng)進(jìn)行頁(yè)交換的頻度，其為解析硬頁(yè)錯(cuò)誤而讀取磁盤(pán)的次數(shù)，小數(shù)值表示是緩存讀為主。

我們從Spotlight中隨機(jī)選擇12：35的告警記錄查看其內(nèi)存使用情況，如下是此時(shí)操作系統(tǒng)整體運(yùn)行圖：

我們可以從圖上看出，大量的內(nèi)存頁(yè)從硬盤(pán)的文件里(Pagefile)調(diào)入了內(nèi)存，且數(shù)值高達(dá)760pages/s，這說(shuō)明在處理器在大量的請(qǐng)求內(nèi)存中該部分內(nèi)存，由于該部分內(nèi)存從內(nèi)存中刪除暫存在硬盤(pán)的Pagefile里面，所以這個(gè)時(shí)候Windows內(nèi)存管理器把大量對(duì)應(yīng)的內(nèi)存頁(yè)重新從硬盤(pán)調(diào)入內(nèi)存中。當(dāng)處理器向內(nèi)存指定的位置請(qǐng)求一頁(yè)（可能是數(shù)據(jù)或代碼）出現(xiàn)錯(cuò)誤時(shí)，這就構(gòu)成一個(gè)PageFault，由于大量的處理器請(qǐng)求該部分內(nèi)存，這時(shí)候就會(huì)產(chǎn)生大量的PageFaults。

接下來(lái)我們查看此時(shí)間點(diǎn)操作系統(tǒng)的PageFaults情況，如下圖：

我們可以看見(jiàn)Hardfaults和Soft faults都超過(guò)5000，Hardfaults（硬錯(cuò)誤）該頁(yè)必須從硬盤(pán)上重新讀取時(shí)，而如果該頁(yè)在內(nèi)存的其他位置，該錯(cuò)誤被稱為Softfaults（軟錯(cuò)誤）。許多處理器可以在有大量軟錯(cuò)誤的情況下繼續(xù)操作，但是硬錯(cuò)誤可以導(dǎo)致明顯的拖延。此數(shù)值將一直很高則說(shuō)明此時(shí)服務(wù)器沒(méi)有分配足夠的內(nèi)存處理其工作負(fù)荷，分析代碼之后可以建議內(nèi)存使用方案。因?yàn)槲锢韮?nèi)存還有大量的空閑可用，而此時(shí)softfaults和hard faults又如此之高，說(shuō)明應(yīng)用對(duì)內(nèi)存的使用非常不合理。

然后我們可以看看操作系統(tǒng)Pages的相關(guān)情況，如下圖：

Pages Input?是以解析硬頁(yè)面錯(cuò)誤從磁盤(pán)讀取的頁(yè)數(shù)，而PagesOutput指為了釋放物理內(nèi)存空間而將頁(yè)面寫(xiě)入磁盤(pán)的頁(yè)數(shù)，從圖上我們可以看出橙色的PagesOutput幾乎為0，此時(shí)Pages Input高達(dá)5000，這說(shuō)明服務(wù)器在此時(shí)有大量的換頁(yè)的需求，已達(dá)到每秒讀取將近20M的硬盤(pán)數(shù)據(jù)流量。

此時(shí)我們來(lái)看看，此時(shí)的操作系統(tǒng)的CacheFaults情況，如下圖：

Cache Faults/sec?指在文件系統(tǒng)緩存中找不到要尋找的頁(yè)而需要從內(nèi)存(軟錯(cuò)誤)的其他地方或從磁盤(pán)(硬錯(cuò)誤)的其他上檢索時(shí)出現(xiàn)的錯(cuò)誤的速度。從上圖我們可以看出此時(shí)的軟、硬錯(cuò)誤都很高，都已經(jīng)超過(guò)了5000。

正常情況下，CPU要讀取一個(gè)數(shù)據(jù)時(shí)，首先從Cache中查找，如果找到就立即讀取并送給CPU處理；如果沒(méi)有找到，就從速度相對(duì)慢的內(nèi)存或更慢的硬盤(pán)中讀取并送給CPU處理。而此時(shí)我們可以看出大量的數(shù)據(jù)從內(nèi)存和硬盤(pán)讀取，這大大增加了IO的時(shí)間，也使CPU處理數(shù)據(jù)時(shí)需要等待，從而造成整個(gè)服務(wù)器數(shù)據(jù)處理的時(shí)延。

其表現(xiàn)就是整體CPU使用率不高，但由于內(nèi)存策略使用的不合理導(dǎo)致大量出現(xiàn)softfaults和hard faults的出現(xiàn)。

接下來(lái)我們來(lái)分析下后臺(tái)應(yīng)用處理的系統(tǒng)業(yè)務(wù)的日志，通過(guò)查看visuBusiness.log，我們可以看出此時(shí)后臺(tái)在Cache對(duì)象本身的執(zhí)行大量的Get和Put操作，這說(shuō)明此時(shí)后臺(tái)執(zhí)行著大量的數(shù)據(jù)查詢操作。

接下來(lái)我們來(lái)分析下定時(shí)推送.log，通過(guò)數(shù)據(jù)統(tǒng)計(jì)我們得出在12：35共計(jì)執(zhí)行了將盡1100個(gè)展示數(shù)據(jù)集推送任務(wù)，如下圖

在可視化系統(tǒng)里面，所有數(shù)據(jù)集在服務(wù)端會(huì)形成一個(gè)與客戶端、連接會(huì)話相關(guān)聯(lián)一個(gè)全局會(huì)話，后臺(tái)服務(wù)會(huì)批量注冊(cè)所有數(shù)據(jù)集的定時(shí)任務(wù)。當(dāng)大量的數(shù)據(jù)請(qǐng)求過(guò)來(lái)后，CPU大量從Cache里讀取數(shù)據(jù)，由于部分?jǐn)?shù)據(jù)不存在，需要從內(nèi)存或虛擬內(nèi)存(軟錯(cuò)誤)或磁盤(pán)(硬錯(cuò)誤)上檢索，此時(shí)就會(huì)造成大量的CacheFaults、soft faults、hard faults，從而造成數(shù)據(jù)讀取時(shí)延。其中cache中不存在的數(shù)據(jù)會(huì)從數(shù)據(jù)庫(kù)重新查詢數(shù)據(jù)，查詢完的數(shù)據(jù)再放至內(nèi)存進(jìn)行數(shù)據(jù)計(jì)算，并將此部分?jǐn)?shù)據(jù)同步更新至Cache。

當(dāng)CPU請(qǐng)求內(nèi)存中數(shù)據(jù)的時(shí)候，存在硬盤(pán)的Pagefile里面，所以這個(gè)時(shí)候Windows內(nèi)存管理器把大量對(duì)應(yīng)的內(nèi)存頁(yè)從硬盤(pán)調(diào)入內(nèi)存中。當(dāng)處理器向內(nèi)存指定的位置請(qǐng)求一頁(yè)出現(xiàn)錯(cuò)誤時(shí)，這就構(gòu)成一個(gè)Page Fault，由于大量的處理器請(qǐng)求數(shù)據(jù)，這時(shí)候就會(huì)產(chǎn)生大量的PageFaults，這樣就會(huì)導(dǎo)致整個(gè)服務(wù)器數(shù)據(jù)處理的等待時(shí)延。

5.1.1小結(jié)

應(yīng)用對(duì)內(nèi)存使用的不合理，造成大量的Page Faults和Cache Faults，引起服務(wù)器處理時(shí)延。

5.2.??單線程CPU Usage達(dá)到100%

通過(guò)查看系統(tǒng)配置，我們可以明確應(yīng)用服務(wù)器CPU啟用了超線程技術(shù)，總計(jì)64個(gè)邏輯核心。

我們從Spotlight中隨機(jī)選擇查看13：10的告警記錄查看其CPU使用情況，如下圖：

我們可以看見(jiàn)單個(gè)CPU在此時(shí)的CPU Usage為100%，且不是個(gè)別獨(dú)立的現(xiàn)象，而是連續(xù)的出現(xiàn)。

接下來(lái)我們查看此刻Total CPU Utilization情況，發(fā)現(xiàn)其平均均值比較低，基本都沒(méi)上10%，如下圖：

應(yīng)用不能利用所有CPU從以上圖中完全可以得到結(jié)論。接著查看Total ProcessorQueue Length情況，發(fā)現(xiàn)?Queue Length最高不過(guò)1，不存在處理器阻塞情況，如下圖：

接下來(lái)我們查看了處理器Context Switching情況，發(fā)現(xiàn)在此時(shí)的Context Switch值近9500，這說(shuō)明后臺(tái)應(yīng)用線程競(jìng)爭(zhēng)很激烈。

對(duì)于高并發(fā)程序來(lái)說(shuō)，如果存在大量的CS，無(wú)疑是性能極大的打擊，鎖競(jìng)爭(zhēng)最明顯的現(xiàn)象就是增加線程上下文切換，而且這些開(kāi)銷(xiāo)都是與應(yīng)用需求無(wú)關(guān)的系統(tǒng)開(kāi)銷(xiāo)。鎖競(jìng)爭(zhēng)導(dǎo)致的串行化現(xiàn)象對(duì)加速比指標(biāo)有非常重大的影響，不論CPU核有多少，最終只有一個(gè)核在運(yùn)行，加速比只有1，多核的性能只相當(dāng)于單核的性能。

所以這里可以在分析業(yè)務(wù)邏輯后建議開(kāi)發(fā)使用多線程異步處理的方式。

接下來(lái)，我們對(duì)后臺(tái)Transmission日志進(jìn)行分析，我們統(tǒng)計(jì)了13：10時(shí)刻的活躍線程的個(gè)數(shù)的大約為64個(gè)，如下圖

通過(guò)分析threaddump，看到有互斥鎖的存在，同時(shí)通過(guò)應(yīng)用日志分析發(fā)現(xiàn)在線程N(yùn)ew I/O server worker #2-5線程處理持有時(shí)間近20秒，持有的鎖時(shí)間過(guò)長(zhǎng)，那么相對(duì)地，鎖的競(jìng)爭(zhēng)程序也就越激烈。

該應(yīng)用日志具體內(nèi)容截圖如下：

5.2.1小結(jié)

后臺(tái)應(yīng)用線程執(zhí)行推送任務(wù)的時(shí)候個(gè)別線程占用鎖時(shí)間過(guò)長(zhǎng)，出現(xiàn)激烈的鎖競(jìng)爭(zhēng)，造成上下文切換的開(kāi)銷(xiāo)大，在切換周期內(nèi)單個(gè)CPU使用率高?。

6.??瓶頸分析

1.?????后臺(tái)應(yīng)用單時(shí)間點(diǎn)定時(shí)推送的數(shù)據(jù)集時(shí)在內(nèi)存使用策略上不合理，導(dǎo)致大量空閑內(nèi)存沒(méi)有使用到，同時(shí)又產(chǎn)生了大量的faults。

2.?????后臺(tái)應(yīng)用鎖競(jìng)爭(zhēng)激烈，線程占用鎖時(shí)間過(guò)長(zhǎng)。

3.?????第一個(gè)問(wèn)題的處理可以緩解第二個(gè)問(wèn)題，但是切換的問(wèn)題仍然需要解決。

7.??優(yōu)化建議

1.?????后臺(tái)應(yīng)用單時(shí)間點(diǎn)定時(shí)推送數(shù)據(jù)集時(shí)充分利用內(nèi)存資源；

2.?????后臺(tái)程序優(yōu)化，采用多線程異步處理的方式。

任務(wù)調(diào)度 壓力測(cè)試

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。