基于Web中間件的運維管理系統的性能優化方法研究與實踐

更新時間:2024-03-06 20:00:55 閱讀：評論：0

2024年3月6日發(作者：苦熱)

張永華

【摘要】從運維管理系統的實際情況出發,分析基于中間件的Web體系結構的系統技術特點,對該類型的運維管理系統實際運行環境(主機系統、網絡、數據庫、中間件、應用結構)出現的性能故障進行全面分析,找出影響性能的原因,給出調整參數的理論方法.通過系統運行過程的不斷優化,得出合理的參數值,以減少和消除運維管理系統性能導致的用戶感知差的影響.%This article analyzes the system

technical characteristics of Web-baaed middleware architecture, she

performance problems of network system operation environment, such as

the host system, network., databa, middleware, application structure,

and identifies the reasons lhaL affect performance and ihe theoretical

method of adjusting ihe parameters. Through rhe reasonable parameter

values, we can reduce the impact caud by the eliminate of network

management system.

【期刊名稱】《電信科學》

【年(卷),期】2011(027)011

【總頁數】8頁(P147-154)

【關鍵詞】運維管理;性能優化;Web應用;中間件

【作者】張永華

【作者單位】中國移動通信集團公司廣西分公司南寧530022

【正文語種】中文

1 引言

近年來，隨著電信運營商市場的發展，為適應全業務發展和市場競爭需要，對運維管理系統能力提升提出了更高的要求，運維管理系統經過長期建設，各種應用規模越來越龐大，所承載的應用范圍不斷拓寬，其中電子運維系統（electric

operation maintenance system，EOMS）作為業務開通和網絡運維集中管理的重要支撐系統，隨著用戶量的不斷擴大，新功能模塊的更新上線，其性能開始下降，影響了用戶使用感知。EOMS采用基于中間件的Web應用模式建設，這種分布式體系具有易擴展和方便維護的特點，但其多層的體系架構也給整體性能優化帶來了新的問題與挑戰，以往對這種Web應用性能優化研究主要集中在數據庫訪問的性能優化上，并沒有從整個體系考慮系統的性能優化策略。針對這一問題，本文以EOMS系統的性能優化實踐為背景，在保持系統良好體系結構和易于擴展、維護的基礎上，從主機系統、網絡、數據庫、中間件、應用結構多個層面對基于中間件的Web應用提出性能優化方法，并對這些方法的實施效果作了測試比較。

參照EOMS系統用戶數量在廣西省與中國移動通信集團公司廣西分公司（簡稱廣西移動）同等規模的公司系統運行情況，同時結合廣西省網絡現狀，將本次優化活動的目標設定如下：將EOMS系統日常處理訪問量最大的模塊——流程管理模塊下的工單處理速度作為本次優化效果評估的主要指標，最終把EOMS工單處理時間縮短到7 s以內（當前性能13 s）。

2 技術特點及性能影響因素

EOMS是一套支撐網絡運維工作集中化、流程化、電子化、自動化、智能化的系統。廣西移動的EOMS由2006年開始建設，經過4年多不斷的完善，目前系統主要分為流程管理、值班管理、業務開通、信息發布、代維管理、作業計劃等6

大模塊。系統在用賬號已經達到2 400個，日均在線人數600～700人，日均工單流轉量達到7 000～10 000張。隨著電信市場全業務的發展，EOMS將成為支撐全業務開通及保障的重要系統。

EOMS采用基于中間件的3層軟件結構體系，自下而上分別是數據庫、中間件、Web服務（如圖1所示），這種架構應用本身不具備獨立運行的能力，必須將其部署到中間件容器中，應用系統才可以正常地運行。隨著EOMS用戶量的增加，用戶經常抱怨常用的應用模塊（如工單、維護作業、信息發布等）訪問速度慢、頁面提交處理及查詢反應時間長等問題。EOMS性能優化必須結合系統的技術特點，對影響性能的各層面因素（包括主機系統、數據庫、中間件（應用服務器）、應用（服務層與應用層）自身）進行全面分析。以下分別從主機、數據庫、Web中間件、應用4個層面，對可能存在的性能影響因素與影響特性進行闡述。

2.1 主機系統

目前EOMS系統采用SPARC Enterpri M9000服務器。該型號服務器的性能有如下特點。

SPARC Enterpri M9000服務器是采用對稱式多處理（symmetric multi-processing，SMP）體系結構開發的 Unix 服務器，兼具超級計算機的高速技術和 Unix服務器的開放性。如果在運行過程中發生了問題，可以自我修正或隔離導致異常的環節，而無需停止系統。此特性可在許多情況下最大限度地減少系統故障，從而提高作業的連續性。

每個SPARC Enterpri M9000服務器都包含一個或多個SPARC64TMⅥ/SPARC64TMⅦCPU。它們可像多個服務器一樣運行，允許靈活地使用資源（包括更有效地執行作業操作），有利于虛擬化技術的應用。針對M9000服務器可分區分片利用的新特性，結合EOMS應用特性，可通過配置多個應用節點且分布式部署的方式，使系統的資源利用率達到最優。

另外，主機操作系統版本為Sun Solaris 10，其影響I/O性能的主要參數介紹如下。

（1）ulimit

ulimit是一種 Solaris系統的內鍵功能，具有一套參數集，用于由它生成的 shell進程及其子進程的資源使用設置限制。

假設有這樣一種情況，一臺 Unix主機上同時登錄了10個人，在系統資源無限制的情況下，這 10個用戶同時打開了 500個文檔，而假設每個文檔的大小有 10

MB，這時系統的內存資源就會受到巨大的挑戰。

而EOMS實際應用的環境要比這種假設復雜得多，EOMS作為在線式數據庫處理應用，對操作系統的文件資源操作更為頻繁，例如一個典型工單流操作中，每個工單文件流轉環節、步驟都對開啟文件描述符的數量、分配堆棧的大小、CPU時間、虛擬內存大小等有非常嚴格的要求。資源的合理限制和分配，不僅僅是保證系統可用性的必要條件，也與系統上軟件運行的性能有著密不可分的聯系。這時，ulimit可以起到很大的作用，是一種簡單并且有效的實現資源限制的方式。

ulimit用于限制 shell啟動進程所占用的資源，支持對以下各種類型資源的限制：所創建的內核文件的大小、進程數據塊的大小、shell進程創建文件的大小、內存鎖住的大小、常駐內存集的大小、打開文件描述符的數量、最大分配堆棧的大小、CPU時間、單個用戶的最大線程數、shell進程所能使用的最大虛擬內存。同時，它支持硬資源和軟資源的限制。

（2）TCP_TIME_WAIT_INTERVAL

該參數用于通知TCP/IP將已關閉的連接控制塊保留的時間。在應用程序完成

TCP/IP連接后，控制塊將保留指定的時間。當連接比率較高時，該保留時間的設置可能導致累積大量的 TCP/IP連接，從而導致服務器性能下降。當EOMS系統

在線用戶并發處理統一應用模塊（如維護作業模塊）時，服務器在某些峰值期間會延遲，用netstat命令顯示 HTTP Server打開的許多套接字處于 CLOSE_WAIT或

FIN_WAIT_2狀態。明顯的延遲可能會長達 4 min，其間服務器無法發送任何響應，但是 CPU利用率很高，所有活動都在系統進程中。

（3）TCP_FIN_WAIT_2_FLUSH_INTERVAL

該參數用于指定禁止處于 FIN_WAIT_2狀態的連接保持該狀態的計時器時間間隔。該參數與TCP_TIME_WAIT_INTERVAL配合使用，可以讓EOMS的數據操作應用訪問操作系統時，網絡等待時間達到合理水平。

2.2 數據庫

數據庫常用的幾種定量分析方法主要包括：響應時間和吞吐量之間的權衡、數據庫的可用性和命中率、內存的使用情況。

（1）響應時間和吞吐量之間的權衡

響應時間是指應用做出反應的時間，以毫秒或秒表示，該值越低越好。吞吐量是指每個單位時間完成的工作，或是單位時間內數據庫完成的 SQL語句數目，以每秒的事務量表示，該值越高越好。

（2）數據庫的高可用性和命中率

高可用性：數據庫系統保障能長時間運行，減少計劃內（甚至是計劃外）停機時間，最好能夠24 h×7無障礙運行，這就是高可用性標準。

命中率：Oracle數據庫通過使用LRU算法，將最近訪問的數據塊存放到緩存中，從而使對磁盤數據的訪問效率優化到接近內存訪問的速度。由于數據庫應用的核心操作就是數據的訪問和處理，因此如果應用系統訪問的大部分數據塊已在緩存中，也就是數據在緩存中命中，即數據命中率。

Oracle中的命中率公式為：Hit Ratio=1-(physical reads/(DB block

gets+consistent gets))，其中 DB Block Gets表示當前模式塊請求的塊數目，即

在操作中正好提取的塊數目，而不是在一致性讀的情況下產生的塊數。Consistent Gets指需要在一致性讀狀態上處理塊的數量，即數據請求總數在回滾段Buffer中的數據一致性讀所需要的數據塊，這些塊產生的主要原因是在查詢的過程中，由于其他會話對數據塊進行操作，而對所要查詢的塊進行了修改，但是由于查詢是在這些修改之前調用的，所以需要對回滾段中的數據塊的前映像進行查詢，以保證數據的一致性，這樣就產生了一致性讀狀態。Physical Reads就是從磁盤上讀取數據塊的數量。當在內存中找不到所需的數據塊時，就需要從磁盤中獲取，于是就產生了“Phsical Reads”。

（3）內存分配調優

內存分配是在系統運行期間動態完成的，以EOMS的Oracle 10版本為例，數據庫管理員可以根據數據庫運行狀況調整數據庫系統全局區（SGA區）的數據緩沖區、日志緩沖區和共享池的大小；還可以調整程序全局區（PGA區）的大小。合理地分配SGA與PGA內存，可以提高緩存的性能，降低 SQL語句解析的時間，減少頁面調度及換頁，另外一方面，數據庫索引配置不合理，會導致Oracle數據庫產生大量的全表掃描，全表掃描必然造成數據內存頁面的頻繁調度。

本文中的EOMS系統優化，將重點從數據庫的可用性和命中率、內存的使用情況兩個方面進行分析。

2.3 中間件

中間件是一種獨立的系統軟件或服務程序，分布式應用軟件借助這種軟件在不同的技術之間共享資源。中間件位于客戶機/服務器的操作系統之上，管理計算機資源和網絡通信，是連接兩個獨立應用程序或獨立系統的軟件。相連接的系統，即使具有不同的接口，通過中間件彼此也能交換信息。

EOMS采用的是IBM WebSphere Process Server V6（WPS）中間件產品，WPS是運行于 WebSphere ApplicationServer(WAS)之上的業務流程集成服務，

WAS中的各種參數的設置都會對 WPS的運行性能產生直接影響。影響WAS運行性能的主要參數如下。

（1）追蹤和日志相關的參數

追蹤和日志是進行問題分析最重要的手段之一，詳細的追蹤和日志可以幫助用戶和

WAS開發、支持人員獲得更多的運行信息，但同時也帶來了較大的 I/O資源消耗，降低了 WAS的性能。

（2）Java虛擬機 (JVM)相關的參數

IBM JVM默認的 Java GC規則是標記-清除-整理，IBM在Java 5.0之后引入新的 Java GC規則，該規則在許多情況下通過調整短生命周期對象和長生命周期對象所占用 Java堆的空間大小提高性能。初始堆大小用于指定JVM代碼可使用的初始堆大小（以兆字節計）。增加最小堆大小可改進啟動，減少發生垃圾回收的次數，并且可實現 10%的性能增益。通常，增加 Java堆的大小會改進吞吐量，直到堆不再駐留在物理內存中。當堆開始交換到磁盤后，Java性能將大幅下降。

（3）線程池大小相關的參數

對于每個WAS的Server，有3個線程池的參數需要調整：Default、ORB、Web

Container。

Default線程池中的線程為分配給 MDB的實例使用，除非單獨指定其他的線程池。這意味著Default線程池要比較大，尤其是當增大激活規范的 maxConccurency參數時。

ORB（object request broker，對象請求代理）線程池用于運行 ORB請求，如遠程 EJB（enterpri Java beans）調用。如果有大量的遠程 EJB被調用，比如人工任務 API被調用，需要加大 ORB線程池大小提高遠程 EJB調用的并發處理能力。

Web Container線程池中的線程用于處理 HTTP和Web服務的請求，且被所有

應用共用，因此需要增大線程池，以提高 HTTP和 Web服務請求的并發處理能力。

（4）數據源連接池大小相關的參數

最大連接數指可以在數據源連接池中創建的最大物理連接數，最大連接數會影響數據庫操作的并發能力。

2.4 應用程序

應用不是獨立于它的操作環境而存在的，相反，內存資源、磁盤輸入/輸出和 CPU的使用直接影響它的操作環境，應用優化得越好，就越容易優化支持這個應用的環境。由于其他系統硬件或軟件的原因而導致的瓶頸，如應用系統本身的設計問題、超出系統吞吐量（在一定時間內系統處理數據的能力）的限制、使用的 SQL結構和語句不合理等，必須聯合應用軟件開發商，從設計上分析影響性能的問題，并對其進行改進和調整。常見的問題如下。

·大量使用固定參數，SQL硬編碼過多。

·SQL語句中編碼不嚴謹，查詢條件設計不合理。

·頻繁和無序的邏輯數據塊讀寫，導致物理I/O的讀取次數過多。

·代碼關鍵字不合理，以“不等于”和“等于”為例：SQL中帶有很多“<>”的查詢，如果字段值是有限個不重復值，要改寫為多個OR連接的“=”查詢，例如deleted<>1，deleted字段只出現2個值，即 0和 1，不如寫為deleted=0，“<>”查詢會導致字段的索引失效，應盡量避免。

3 優化實施方法

3.1 操作系統參數調優

（1）Solaris 文件描述符（ulimit）

文件描述符是Unix系統內核中用于表示特定進程打開的特定文件的方式，通常是一個整型的變量。如果此參數的值過低，在系統日志中顯示打開過多文件錯誤，從而影響用戶的請求。根據EOMS用戶訪問量和工單數據處理量的估算，對EOMS

操作系統Solaris 10的相應參數調整如下。

缺省值：無；

建議值：65 535。

（2）Solaris TCP_TIME_WAIT_INTERVAL

該參數是通知TCP/IP保留已關閉連接控制塊的時間。在應用程序完成 TCP/IP連接后，控制塊保留指定的時間。根據EOMS數據連接方式和TCP網絡訪問特點，對EOMS操作系統Solaris 10的相應參數調整如下。

缺省值：缺省為 2 400 s。

建議值：60 s。

（3）Solaris TCP_FIN_WAIT_2_FLUSH_INTERVAL

該參數指定禁止處于 FIN_WAIT_2中的連接保留在此狀態中的定時器間隔。根據EOMS數據連接方式和TCP網絡訪問特點，對EOMS操作系統Solaris 10的相應參數調整如下。

缺省值：缺省為 675 000。

建議值：67 500。

EMOS系統的分布式部署方案如圖2所示。

EOMS系統，現有軟件部署架構由一臺ISA服務器在最前端實現移動運維內部網絡與移動OA網絡間的互連互通。

在ISA服務器后端，引入一個HTTP服務中間件NGINX。NGINX起到負載均衡、按端口提供映射服務的作用。其優點如下：由于系統實現分布式處理，以NGINX替換原IBM提供的負載分流軟件HIS以提高負載分流時的性能；通過NGINX配置文件的修改調整，當系統某組節點出現故障時，可以快速切換，將使用用戶分流到其他節點。切換時間2 s，不影響用戶。

在NGINX服務器后端，通過NGINX和M9000虛擬化分區技術，對應用中間件建立了7組節點服務。采用7組節點的原因如下：原有EOMS系統WPS軟件應用集群只有兩個節點，兩個節點共同承載整個EOMS系統的所有應用，當EOMS軟件因為線程或者應用高負荷導致系統崩潰時，無備用節點提供系統服務。

當某個EOMS應用內部異常導致某個WPS節點崩潰時，通過NGINX配置快速切換，不會影響其他應用資源，以保障應用可用性和穩定性。

EOMS系統既存在人工任務（如派發工單、處理工單等），也存在自動任務（如網管告警派單接口、各類輪循任務等）。由于人工任務與自動任務的特點及要求是不同的，如果混雜在一起，將會導致系統越在忙時越忙的情況，影響系統運行。所以在新的系統環境中按照業務特點，對系統進行拆分及分布式部署，使自動任務與人工任務相隔離，各行其道，互不干擾。

數據庫承載服務在原EOMS系統采用的HA技術上，引入了Oracle Data Guard同步備份機制，保證了在數據庫出現異常時，可以在線切換到備用的數據庫進行業務承載，達到應用24 h不間斷處理服務的目的。

3.2 數據庫調優

本次結合EOMS日常工單處理量及人工任務并發訪問量，對數據庫進行DBA跟蹤，主要對Hit Ratio、PGA、LOG buffer、Hash join語句等參數作出以下調整：

·因Hit Ratio命中率低，將db_cache_size增加到7 086 MB，同時

SGA_MAX_SIZE相應增加，Hit Ratio調整前后指標變化如圖3所示；

·因PGA的命中率極低，將pga_aggregate_target提高一倍后，數據庫TEMP表空間現象明顯減少，大幅增加了涉及sort和Hash join操作的語句執行效率；

·因LOG buffer相關等待事件明顯，增大log_buffer大小為2 MB；

·按照順序掃描的SQL語句創建或重建相關表的索引；

·新增索引，對無索引或條件語句涉及的字段未建有索引的表創建相應的索引，通

過statspack篩選所有table access full的語句，判斷全表掃描的必要性，對于走索引合理的語句創建合適的索引，通過梳理新建了35個索引，調整后全表掃描前后的對比如圖4所示；

·把使用最頻繁的幾個索引單獨放在一個dbspace里，暫時不需要對單個索引作分片處理。

索引表空間分布如圖5所示。SYSTEM和XDB為系統索引表空間，indexdbs表空間是主要的用戶索引表空間，包含306個用戶索引，EOMS30和emosdbs是次要用戶索引表空間，分別包含184個和175個用戶索引。

3.3 中間件調優

通過對IBM WebSphere的中間件運行日志進行跟蹤分析，結合IBM官網給出中間件性能問題指南手冊，重點對JVM、線程、數據庫連接池等方面進行分析調優。

（1）VM 檢查

目前系統分配給WPS JVM的大小為1 GB，在實際JVM消耗情況跟蹤中，發現系統運行過程中，其JVM的峰值已經與系統設定的閾值很接近了，在用戶請求集中而可用資源較少的情況下，就會出現系統等待的情況，原因是中間件必須將內存回收后，才會分配排隊等待的請求，所以JVM要進行適當的調整，把最大堆調整至1 500 MB。

（2）線程池

EOMS所有用戶訪問請求最終都轉化成中間件用戶響應線程的形式完成處理，線程池解決了用戶響應線程的創建與銷毀所消耗的時間，可以有效地提高對用戶請求的響應，所以給線程池設置一個合適的值，滿足目前系統吞吐量是一個很重要的工作。目前系統分配給中間件的線程數是150個，即線程池中有150個線程循環響應用戶的請求。結合系統設置和對忙時EOMS應用日志的觀察，認為需要增大線

程池，以滿足現有的業務需求，因此將線程數設置為200個。

（3）數據庫連接池

EOMS應用并不直接管理數據庫連接，而是通過中間件提供的連接池管理。在每次建立數據庫物理連接時，數據庫要為該連接分配多種資源，反之，釋放連接時，要把這些資源及時釋放掉。分配和釋放資源也都是耗時的操作，因此，反復建立/釋放數據庫連接會對系統的效率產生不良影響。IBM WebSphere自身提供連接池技術，在連接池中維護多個活動的數據庫物理連接，當系統需要進行數據庫訪問操作時，從池中獲得一個連接，操作完畢后并不直接釋放，而是把連接放回池中，以便以后使用，這樣可以大大減少建立/釋放連接的次數。通過對連接池物理連接數量大小的調整，可以獲得最佳性能。結合系統設置和EOMS忙時的應用日志的觀察，需要相應地對數據連接池參數進行調整，經過評估，250個足以滿足現有業務需求，因此連接池的最大并發數設置為250個。

3.4 應用代碼調優

完成以上3個層面的調整后，發現還有30%～40%的系統性能問題未得到明顯改善，需要進一步對應用代碼進行分析。主要提出以下EOMS開發編碼規范，以“關鍵模塊代碼走查”和“框架代碼復查”為主要方式，對代碼提出了調整策略。

（1）批量查詢代碼調整策略

一次操作中提取盡量多的數據 (N+1)：通過代碼循環優化，增加一次性數據讀取的數量集合，減少與數據庫交互的次數，以便大量數據操作在內存中完成，保證代碼執行效率。

（2）將需要存取的塊的數量減到最小，必要時重寫代碼及SQL語句

即能定義為包體的局部過程或局部變量的，就不要在包中定義；能在過程內定義的子過程或變量，就不要定義為包體中的局部過程或局部變量；子過程使用的變量，

不要在父過程中定義。從而執行部分縮小，減少網絡傳輸以及內存交互的負荷。

（3）對關鍵字編碼進行規范

規則如下。

·變量未賦值前，保持進行Null的引用，避免因內存泄露導致系統性能下降。

·減少SQL硬編碼，硬編碼即每個SQL查詢條件都使用固定參數形式寫死，這樣導致每一次參數的變動Oracle數據庫都會當作一條新的SQL解析并執行，無法利用Oracle的緩存命中區，從而增加了Oracle數據庫解析的開銷。

·不要隨意使用distinct、<>等關鍵字，如必須使用，注意分析其必要性。

·避免未捕獲的異常拋出，每個SQL都有可能出錯。需要使用異常捕獲語句包裹每個SQL，并給出恰當的提示。比如某系統前段時間一直有no_data_found的錯誤，程序拋出的異常就是這個。很簡單，這說明程序中有個lect語句查詢結果為空，但并沒有捕獲這個異常，所以直接拋出了no_data_found，這個錯誤是無法定位的。過多未被捕獲異常會產生額外的性能開銷。

通過程序代碼走查修改，逐步優化程序代碼，減少不規范，從每周統計的同一類工單查詢的執行效率趨勢圖，可以看出優化效果明顯，如圖6所示。

4 優化效果及貢獻度

（1）優化效果

對EOMS訪問量最多的流程管理模塊下的工單處理模塊處理速度進行優化前后效果比對分析，優化前后的對比趨勢如圖7所示。

經過優化，工單平均處理時間下降到7 s以下，性能效果較優化前提升了50%。

（2）優化任務貢獻度

根據優化順序，針對主機系統、中間件、數據庫、應用代碼4個方面，每做完一

項優化措施，對運維系統的性能優化效果提升貢獻情況進行記錄和統計，詳見圖8。

可以看出，對于基于Web中間件的運維系統調優，建議的調優任務的實施順序依次為：數據庫調優、應用代碼調優、中間件調優、主機系統調優。

5 結束語

本文結合具體實踐，對基于中間件的Web應用系統進行性能調優，從主機系統、中間件、數據庫、應用結構4方面提出了分析和優化策略，并最終取得較好的成效。同時對各層面調優實施后對整體優化效果的貢獻情況進行記錄與分析，為后續同類型技術架構的運維管理系統性能問題優化提供了參考依據和優化方向性指導。

參考文獻