應用系統性能管理的五個步驟

2019-11-18 13:12:01

字體：大中小

來源：轉載

供稿：網友

　　目前對很多行業來說，IT技術正在支持著要害的業務應用，如制造業的ERP 系統、電信BOSS系統、銀行的核心業務系統、卡業務系統以及基于電子商務的業務等。要害業務應用對性能有較高要求，性能下降往往對業務造成巨大損失。面對這些問題，需要有一系列工具和方法，能夠對IT系統的性能進行監控和治理，并對可能出現的性能問題進行及時、準確的分析和處理。從而改善服務品質，減少操作失敗和災難發生的風險，減少維護運營的整體成本，提高系統的可用性、縮短響應時間，提高最終客戶的滿足度。
　　
　　應用系統性能治理范圍涉及到企業級應用和終端應用的各個方面，例如打印設備，存儲設備，數據庫，應用服務器，網絡，Web服務器，操作系統，用戶應用軟件等。應用系統性能治理的尺度可概括為用戶的請求是否被快速處理，系統的資源是否得到合理的利用，以及系統是否能夠連續不間斷地運行等三個方面。具體實施可分為下面五個步驟：
　　
　　1."見微知著" ，主動及早發現問題
　　建立問題報警機制。在系統運行中，從網絡，操作系統，數據庫，應用服務器，Web服務器等環節上會產生大量的信息，這些信息的組合可能預示著某種潛在的性能問題，需要可靈活定制報警的機制，并且可以通過多種報警方式（電子郵件，手機短信等方式）通知治理員。
　　
　　在應用系統投入運行的前期，應盡量多地發現應用系統的潛在性能問題。雖然系統在早期一般負載不大，但是通過使用監控工具，可以明顯發現系統資源的細微變化。大部分問題是能夠在系統運行的早期發現的。
　　
　　大多數問題是可以從基本的操作系統，網絡的層面中反映出來的，例如內存過度消耗，CPU的高使用率，進程的頻繁啟動或數量過多等；所以常見的監控對象通常是：CPU、磁盤I/O、網絡、文件系統，進程，用戶，MIBII，系統日志，Web服務器等。為了發現與特定應用系統有關的問題，需要有針對性地建立規則，對于SAP,PeopleSoft,Oralce,WebLogic等軟件系統，應建立特定的報警規則。
　　
　　2."按圖索驥" 診斷問題
　　快速找出性能瓶頸，依靠更精確的監控信息。不管問題發生在操作系統，存儲，數據庫、應用軟件，應用服務器還是WebServer 等；我們需要借助軟件工具來收集有用的系統信息，提供豐富的實時的視圖和報表，直接在每個被監控的系統中搜集端到端的準確信息。在這些信息基礎上，進行實時和歷史分析。
　　
　　快速明確供給商責任是有利于快速解決問題?，F在的應用系統越來越復雜，涉及到提供主機，存儲設備，操作系統，數據庫，應用服務器，應用軟件，及其之間的大量接口的供給商，出現問題后，手工方式很難快速找到問題的根源，并且對于一些問題難以找到足夠的數據以明確供給商的責任。
　　
　　3.專家性建議
　　提供系統性的專家性建議，為快速解決問題提供依據和可能的方案；深入地分析問題：挖掘問題，向專家咨詢，從性能治理工具中查找建議，或訪問內部知識庫可獲得問題解決的建議及手段。
　　
　　一個好的知識庫，不只記錄了相關問題的技術信息，同時也記錄了應該找誰，在哪可以獲得幫助。知識庫是一個不斷積累的過程，現在一些廠商也開始提供不斷更新的診斷知識庫。
　　
　　4.解決問題
　　根據專家建議和方案，進行優化試驗，測試，驗證和評估等工作，在現有方案中確定最優的解決方案并進行實施。
　　
　　5.日常維護
　　保證系統正常運行，關注系統運營狀況，調整報警規則，關注新問題的發生，從而不斷提升服務治理水平。
　　
　　通過性能治理, 可以快速理解整個應用系統在運行中資源分配情況和運行機制。
　　
　　應該采用服務等級治理(SLA)，建立起IT技術實現到IT技術服務治理的橋梁，使得能夠從治理的層次對應用系統的維護進行評估。在SLA上前攝性地進行治理和報告，通過初始化SLA定義，可以提供實時和歷史數據，并能夠預見到未來的對SLA的違反，并基于這一數據對SLA進行調整。
　　
　　"應用性能問題好比是在一個黑暗的房間里，你知道這個黑屋里有些問題，但是你不知道屋子里有什么，也不知道問題在哪兒。這時，應用性能治理軟件就好比是一盞明亮的燈，有了這些軟件工具以后，整個黑屋明亮了起來，你能非常準確地、輕易地確定問題之所在，找出問題的原因，并馬上修復它。"
　　
　　這里以一種優秀的性能治理工具美國Quest 公司的Foglight 來說明是怎樣幫助治理J2EE應用。
　　
　　隨著J2EE的企業級應用越來越廣泛，在實際中面臨著很大風險，系統中的很多性能問題源于此。這是由于：
　　
　　J2EE 應用服務器體現了"黑箱"思想，用戶或開發人員對實現的細節并不清楚；
　　
　　開發人員只開發業務邏輯代碼，由已經標準化的資源來處理數據庫連接，消息等，并不熟悉這些標準化的資源的實現過程；目前J2EE發展很快, 在很多項目建設中, 技術人員普遍對J2EE缺乏經驗，專家非常缺乏；
　　
　　java本身難于調試，非凡是獲得運行中的信息更為困難。J2EE包含了很多組件，（包括客戶端軟件，Web 服務器，應用服務器，數據庫服務器，等等），排查問題尤為艱難。
　　
　　在Foglight中，監控治理信息的來源主要是：資源的使用，包括各種應用池和緩存；J2EE應用服務器通過JMX提供的信息；應用服務器/操作系統等的錯誤日志。
　　
　　1.發現問題
　　通過Foglight 定義發現問題的恰當規則是應用性能治理的要害一步，在實際中，可從三個方面考慮：
　　
　　a) 在可用性方面：
　　
　　當集群中有20%服務器宕機時，發出警告；
　　
　　當集群中有80%服務器宕機時，發出危急警報；
　　
　　當集群中有100%服務器宕機，或一個非集群服務器宕機時，發出致命錯誤；
　　
　　b) 在服務性能方面，需要根據應用的設計和負載定義規則：
　　
　　JDBC Pools，大多數應用是以數據庫為中心的，調整JDBC Pools的數量對應用的性能甚至正確性有顯著影響。根據應用的設計和負載，確定JDBC Pools閾值，系統在達到閾值時將報警。
　　
　　Execution Queues，根據應用實際情況，確定線程的閾值。
　　
　　JMS Servers，根據應用的設計和負載，確定字節/消息的閾值，系統在達到閾值時將報警。
　　
　　Message Driven Bean 和 Stateless session Bean pools，假如Beans不可用，則請求必須等待直到獲得。根據應用的設計和負載，確定Message Driven Bean 和 Stateless Session Bean pools閾值，系統在達到閾值時將報警。
　　
　　Entity Bean 和 Stateful Session Bean caches，當Beans過渡地鈍化或激活(passivated, activated)時，大量的磁盤I/O會顯著降低性能，系統可產生報警。
　　
　　回滾（Rollbacks），系統錯誤，資源不足，超時異常等產生的事務回滾可嚴重影響業務處理的成功完成。
　　
　　日志文件（Log Files），根據WebLogic日志的消息的嚴重程度，確定不同的報警方式(Warning,Critical,Fatal)。
　　
　　c) 在應用性能方面：
　　
　　反應時間（Response Times），反應時間：確定相關類或方法的響應時間的報警閾值，這些值可通過這些類或方法的響應時間的歷史紀錄確定。報警級別可根據與歷史紀錄的差距確定。
　　
　　回滾（Rollbacks），報警的嚴重程度與應用回滾數量與全部事務數量的比例相關。應用事務的回滾可能是正常的（例如校驗數據），但是當應用回滾的比例很大時，將意味著錯誤。
　　
　　.診斷問題：
　　Foglight根據預先定義的規則對應用系統進行監控并發出警報。Foglight 針對監控的對象類型，提供了豐富的關聯性圖表以顯示類或方法的響應時間，JDBC Pool，JMS，Entity Bean，Stateful Session Bean，Message Driven Bean，Execution Queues等的使用情況。其中垃圾回收和HTTP會話是編寫JAVA應用代碼中常見的問題癥狀。
　　
　　a)垃圾回收（Garbage Collection）：
　　
　　Foglight 提供圖表顯示垃圾回收的次數和每次回收的內存數量，可以判定應用使用內存的效率。假如每次回收大量內存的次數很多，意味著應用沒有正確使用內存資源；假如每次回收較少內存的次數很多，意味著應用在使用內存方面是健康的。
　　
　　b)HTTP會話：
　　
　　Foglight 可以顯示應用服務器上每個應用的HTTP會話的數量。可以分析HTTP會話的超時配置是否合適，同時可以計算會話對內存的消耗。假如會話數量很多，就需要注重每個會話使用的內存數量。
　　
　　3.專家性建議
　　根據經驗可以從三個方面獲得專家性建議：
　　
　　Foglight 和Spotlight（Quest公司的診斷產品）的聯機幫助，提供了大量的實用建議。
　　
　　系統維護團隊的工作日志或知識庫系統。
　　
　　J2EE應用服務器的供給商和應用系統開發商的技術咨詢隊伍。
　　
　　4.解決問題
　　在專家性建議的基礎上，需要一支經驗豐富的技術隊伍來完成，技術隊伍不但需要對系統和對JAVA開發有豐富的經驗，而且應具有正確的解決問題的規范和方法。
　　
　　5.日常維護
　　根據軟件版本的變化，新功能的開發，問題的解決，需要對一些預警規則進行調整，并繼續持續觀察。
　　
　　Foglight 提供對SLA的實時統計監控功能，自動進行統計并生成規范的治理報告。
　　
　　目前國內用戶對應用性能治理的熟悉還處于引導性階段。很多用戶還不了解對于絕大多數問題已經有工具化、程序化的解決方法。習慣在出現問題后，采用現有的簡單分析工具，完全依靠開發商的經驗進行分析和會診。這種非程序化方法導致解決問題時間的不可控。使用應用性能治理產品和服務，可以幫助用戶監控，分析和解決問題，從而提高整體治理水平。

上一篇：進階教程——Java性能優化通用篇

下一篇：在Oracle快速進行數據行存在性檢查