性能分析之大屏可視化平臺瓶頸分析（window版）

1、性能分析之屏可視化平臺瓶頸分析版）背景運(yùn)環(huán)境硬件環(huán)境服務(wù)器類型機(jī)器名配置說明應(yīng)服務(wù)器WIN-8PEK4VLQU8RCPU: Inter Xeon(R) E7- 4830 2.13GHz_ HTT/CMP單元8 /8 內(nèi)存:32G硬盤:300G絡(luò)類型絡(luò)類型寬帶設(shè)備局域1000M企業(yè)級千兆交換機(jī)性能監(jiān)控監(jiān)控設(shè)計(jì)通過Spotlighton window收集應(yīng)服務(wù)器window性能數(shù)據(jù)，采樣周期7x24時(shí)不間斷，系統(tǒng)監(jiān)控期間正常運(yùn)，如下圖。告警分析通過對告警志（即Alarmlog）整理，我們抽樣的時(shí)間段為2014/5/309:41:002014/6/6 9:39:00，這其中共產(chǎn)9563條告警志。通過

2、簡單按嚴(yán)重程序排序，我們可以發(fā)現(xiàn)其中存在許多的嚴(yán)重級別的告警，如下圖。9563條告警中，嚴(yán)重級別的告警存在195條 記錄。最后，通過對嚴(yán)重級別告警志歸納整理，我們得出了主要以下兩個(gè)問題：Pagereads/sec過且頻繁（告警174次）單線程CPU Usage達(dá)到100%（告警21次） 截圖如下：問題分析Page過且頻繁操作系統(tǒng)會(huì)利磁盤較好的式提系統(tǒng)可內(nèi)存量或者提內(nèi)存的使效率Pages Read直接反應(yīng)了操作系統(tǒng)進(jìn)頁交換的頻度，其為解析硬頁錯(cuò)誤讀取磁盤的次數(shù)，數(shù)值表是緩存讀為主。我們從Spotlight中隨機(jī)選擇12：35的告警記錄查看其內(nèi)存使情況，如下是此時(shí)操作系統(tǒng)整體運(yùn)圖：我們可以從圖上看

3、出，量的內(nèi)存頁從硬盤的件(Pagefile)調(diào)了內(nèi)存，且數(shù)值達(dá)760pages/s，這說明在處理器在量的請求內(nèi)存 中該部分內(nèi)存，由于該部分內(nèi)存從內(nèi)存中刪除暫存在硬盤的Pagefile，所以這個(gè)時(shí)候Windows內(nèi)存管理器把量對應(yīng)的內(nèi)存頁重新從 ）出現(xiàn)錯(cuò)誤時(shí)，這就構(gòu)成個(gè)PageFault，由于量的處理器請 求該部分內(nèi)存，這時(shí)候就會(huì)產(chǎn)量的PageFaults。接下來我們查看此時(shí)間點(diǎn)操作系統(tǒng)的PageFaults情況，如下圖：我們可以看見Hardfaults和Soft faults都超過5000，Hardfaults（硬錯(cuò)誤）該頁必須從硬盤上重新讀取時(shí)，如果該頁在內(nèi)存的其他位置，該錯(cuò)誤被稱為Soft

4、faults（軟錯(cuò)誤）。許多處理器可以在有量軟錯(cuò)誤的情況下繼續(xù)操作，但是硬錯(cuò)誤可以導(dǎo)致明顯的拖延。此數(shù)值將直很則說明此時(shí)服務(wù)器沒有分配夠的內(nèi)存處理其作負(fù)荷，分析代碼之后可以建議內(nèi)存使案。因?yàn)槲锢韮?nèi)存還有量的空閑可，此時(shí)softfaults和hard faults如此之，說明應(yīng)對內(nèi)存的使常不合理。然后我們可以看看操作系統(tǒng)Pages的相關(guān)情況，如下圖：Pages Input 是以解析硬頁錯(cuò)誤從磁盤讀取的頁數(shù)，PagesOutput指為了釋放物理內(nèi)存空間將頁寫磁盤的頁數(shù)，從圖上我們可以看出橙的PagesOutput乎為0，此時(shí)Pages Input達(dá)5000，這說明服務(wù)器在此時(shí)有量的換頁的需求，已達(dá)

5、到每秒讀取將近20M 的硬盤數(shù)據(jù)流量。此時(shí)我們來看看，此時(shí)的操作系統(tǒng)的CacheFaults情況，如下圖：Cache Faults/sec 指在件系統(tǒng)緩存中找不到要尋找的頁需要從內(nèi)存(軟錯(cuò)誤)的其他地或從磁盤(硬錯(cuò)誤)的其他上檢索時(shí)出現(xiàn)的錯(cuò)誤的速度。從上圖我們可以看出此時(shí)的軟、硬錯(cuò)誤都很，都已經(jīng)超過了5000。CPU處理；如果沒有找到，就從速度相對慢的內(nèi) 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)。我們可以看出此時(shí)后臺在Cache對象本的執(zhí)量的 Ge

6、t和Put操作，這說明此時(shí)后臺執(zhí)著量的數(shù)據(jù)查詢操作。接下來我們來分析下定時(shí)推送.log，通過數(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ì)話，后臺服務(wù)會(huì)批量注冊所有數(shù)據(jù)集的定時(shí)任 faults、hardfaults，從造成數(shù)據(jù)讀取時(shí)延。其中cache中不存在的數(shù)據(jù)會(huì)從數(shù)據(jù)庫重新查詢數(shù)據(jù)，查詢完的數(shù)據(jù)再放內(nèi)存進(jìn)數(shù)據(jù)計(jì)算，并將此部分?jǐn)?shù)據(jù)同步更新Cache。Windows內(nèi)存管理器把量對應(yīng)的內(nèi)存頁從硬盤調(diào)內(nèi)存中。當(dāng) 處理器向內(nèi)存指定的位置請求頁出現(xiàn)錯(cuò)誤時(shí)，這就構(gòu)成個(gè)PageFault，由于量的處理器請

7、求數(shù)據(jù)，這時(shí)候就會(huì)產(chǎn)量的PageFaults，這樣就會(huì)導(dǎo)致整個(gè)服務(wù)器數(shù)據(jù)處理的等待時(shí)延。結(jié)應(yīng)對內(nèi)存使的不合理，造成量的Page Faults和Cache Faults，引起服務(wù)器處理時(shí)延。單線程 CPU 100%CPU啟了超線程技術(shù)，總計(jì)64個(gè)邏輯核。 我們從Spotlight中隨機(jī)選擇查看13：10的告警記錄查看其CPU使情況，如下圖：我們可以看見單個(gè)CPU在此時(shí)的CPU Usage為100%，且不是個(gè)別獨(dú)的現(xiàn)象，是連續(xù)的出現(xiàn)。接下來我們查看此刻Total CPU Utilization情況，發(fā)現(xiàn)其平均均值較低，基本都沒上10%，如下圖：應(yīng)不能利所有CPU從以上圖中完全可以得到結(jié)論。接著查看

8、Total ProcessorQueue Length情況，發(fā)現(xiàn) Queue Length最不過1， 不存在處理器阻塞情況，如下圖：接下來我們查看了處理器Context Switching情況，發(fā)現(xiàn)在此時(shí)的Context Switch值近9500，這說明后臺應(yīng)線程競爭很激烈。對于并發(fā)程序來說，如果存在量的CS，疑是性能極的打擊，鎖競爭最明顯的現(xiàn)象就是增加線程上下切換，且這些開銷都是與 CPU核有多少，最終只有個(gè)核在運(yùn)，加速 只有1，多核的性能只相當(dāng)于單核的性能。所以這可以在分析業(yè)務(wù)邏輯后建議開發(fā)使多線程異步處理的式。接下來，我們對后臺Transmission志進(jìn)分析，我們統(tǒng)計(jì)了13：10時(shí)刻的活躍線程的個(gè)數(shù)的約為64個(gè)，如下圖通過分析threaddump，看到有互斥鎖的存在，同時(shí)通過應(yīng)志分析發(fā)現(xiàn)在線程N(yùn)ew I/O server worker #2-5線程處理持有時(shí)間近20 秒，持有的鎖時(shí)間過長，那么相對地，鎖的競爭程序也就越激烈。該應(yīng)志具體內(nèi)容截圖如下：結(jié)后臺應(yīng)線程執(zhí)推送任務(wù)的時(shí)候個(gè)別線程占鎖時(shí)間過長，出現(xiàn)激烈的鎖競爭，造成上下切換的開銷，在切換周期內(nèi)單個(gè)CPU使率 。瓶頸分析后臺應(yīng)單時(shí)間點(diǎn)定時(shí)推