中間件（WAS、WMQ）運維 9個常見難點解析

本文由社區中間件達人wangxuefeng26六、ayy216226分享整理，包括WAS、WMQ在安裝、巡檢、監控、優化過程當中的常見難點。

安裝

一、was 負載均衡的機制的粘連性，was負載均衡異常？

有一個case系統，部署在was集羣環境，應用是集羣環境，有的時候當一個節點異常的時，客戶端訪問該系統就會拋出異常，按正常狀況，該會話應該不會斷或者斷了再鏈接一次就會到另外一個節點，可是好多時候無論客戶端如何鏈接，都不行，該正常的客戶端一直是正常的，不正常重啓機器也不正常。固然其餘新鏈接的節點也沒啥問題，直到重啓了故障節點的應用，原先不能正常訪問的客戶端才正常，就算當時清除瀏覽器緩存也很差使，哪位有這方面的經驗能夠多談談。

答：

1，這是故障轉移，was有內部機制能夠作到

1）內存到內存複製技術能夠，缺點，因每臺服務器共享session，因此佔用內存比較大（若是server不多，能夠考慮使用）。

2）存儲到數據苦或者其餘地方也能夠實現。推薦使用，可是實現較複雜

二、如何大批量的完成WAS的安裝和部署？有哪些工具和方法？

如：幾百臺或上千臺WAS服務器的安裝和部署

答：

1，wsadmin 去寫腳本是個好辦法，配合虛擬化去作。

2，還有上千臺的已經不適合去用商業軟件了，建議去考慮下開源的軟件，或者雲平臺了。

三、was安裝低版本升級須要注意哪些方面？須要從新繳費嗎？

答：

1，was 6 官方已經再也不提供支持，除非額外買服務。

2，從2018年4月開始，將再也不支持Java SE 6 與 WebSphere Application Server 配合使用，建議更新爲 Java SE 7 或 8

3，WAS V7.0.x 和 V8.0.x 和 Portal Server V8.0.x 於 April 30, 2018 End Of Service

低版本注意事項：

1，規劃好磁盤空間，內存和CPU

2，規劃好安裝目錄，儘可能作到安裝目錄統一，規範。

3，瞭解好業務量大小，併發等等，方便你設計你的was部署方案。

4，調參數時注意結合實際，並無徹底統一的配置。

5，升級前固然要在測試環境測試後在驚醒生產，JDK版本，及WAS不通版本是有差別的。

巡檢

一、針對WAS例行巡檢，通常有哪些檢查點？每一個檢查點判斷的標準是什麼？

例如：巡檢WAS，須要檢查文件系統、CPU是否高、線程過載、JVM性能、JDBC等方面是否正常。通常以磁盤空間未佔滿60%，CPU低，未發生線程過載等判斷是否存在問題。

答：

1,WAS DM node server的進程狀態，was自帶狀態命令。結合系統命令查看。

2，server的was_home/profiles/node/logs/server下:SystemOut.log SystemErr.log native_stderr.log native_stdout.log

3，was_home/profiles/node/logs/ffdc 日誌

4，巡檢須要查看JVM 參數設置、線程池參數設置，標準應該參照客戶的規範或者以通用參數設置爲標準，

5，若是有性能問題時須要查看系統運行狀況：內存、CPU，如常常發生的內存泄露問題，有多是堆內存(heap)或本地內存(native)，這常常性的是一個過程性的問題，須要具體分析。

二、該如何分析Javacore（was中間件）

日常的故障中，通常都是須要分析javacore。也是夠頭疼的了。

通常在獲得幾個javacore文件以後，就想到能夠用IBM Thread and Monitor Dump Analyzer for Java工具去協助分析，不過。。。好像沒有找到如何分析的教程，看來不少文章，仍是沒有頭緒。。

咱們應該去關注那個Current Thread？仍是Thread Detail裏面的哪些線程捏？關注Blocked和僵死狀態的線程？？應該從那個開始着手呀？

答：

不能經過幾句話說清楚點，須要知識積累，介紹幾個文檔：

1，IBM爲javacore、GC和heapdump的提供了一個集成工具，叫IBMSupport Assistant

2，http://www-01.ibm.com/support/docview.wss?uid=swg21181068#2.1.1

3，IBMJava626.pdf 這本書去去看看，瞭解清楚了JVM。

三、咱們ERP中WAS版本比較低，JVM設置256-1280，幾乎每月總會有JVM宕機重啓發生，這正常嗎？

WAS版本5.1。JVM宕機重啓緣由大可能是因爲內存溢出致使，曾經試着給堆擴容至2048，仍會有宕機發生，從網上搜了很多資料，有人也建議設置定時重啓，這正常嗎？不能從根本是杜絕WAS宕機重啓嗎？

答：

1，首先你須要確認OOM是由於內存不夠致使內存溢出仍是由於應用代碼不規範存在內存泄露。

2，內存也不是越大越好，須要和你你本身的環境。

3，JVM參數配置須要看你OS 平臺 32 位有限制，64位理論上來講沒有限制，可是考慮到GC時間 最好不要調的過大，而最小JVM內存若是過小則會頻繁GC。

4，能夠看下應用是否有內存泄露，注意下GC日誌，分析下。

監控

一、WAS JVM使用率該如何合理監控？

若是隻是監控WAS HEAP USED%，那告警頻率過高，若是開啓了GC，那麼GC頻率結合WAS HEAP USED%是不是個好的監控方法？那麼GC頻率的閥值該如何設置？

答：

這個並無定論：JVM 堆內存過低會致使GC頻繁，而JVM對內存太大，致使GC時間太長，影響應用訪問，若是併發又比較大，又存在大對象、處理的數據量又比較大，應用對數據有沒有特殊處理，那發生高CPU的問題會很頻繁。

因此沒有固定值，適合本身系統的須要測試嘍！

能夠開啓詳細垃圾回收，而後本身測試GC間隔時長，而後作出判斷。

二、針對MQ的監控，通常有哪些指標值得咱們去關注？請列舉說明

如：MQ的隊列深度、日誌報錯等

答：

MQ巡檢通常狀況關注三個方面。

1，錯誤日誌。

A）qmgr 錯誤日誌：默認目錄 /var/mqm/qmgrs/<qmgrname>/errors/AMQERR01.log，AMQERR02.log，AMQERR03.log

最新日誌通常記錄在AMQERR01.log中，查看該日誌判斷mq有什麼問題。常見報錯：AMQ9999通道異常終止錯誤，AMQ9526消息序列號不一致，AMQ9513達到通道鏈接數最大值，AMQ9207 收到主機消息無效,還有錯誤AMQ9206，AMQ9208，AMQ9209等。

除了上述錯誤，能夠把平時運行中常見報錯，記錄下來，做爲往後巡檢的參考。

B）mq錯誤日誌： /var/mqm/errors/AMQERR01.log，AMQERR02.log，AMQERR03.log，*FDC文件

這個目錄等錯誤通常和軟件運行有關的錯誤，若是有錯誤該重點關注，且詳細分析每一條錯誤的緣由。FDC文件則是mq軟件運行有問題時的堆棧信息，能夠經過這個文件判斷是否mq自己的bug。

2，MQ運行狀態

A）通道的狀態，非running的狀態都是有問題的。須要結合日誌判斷通道終止或者binding的緣由。

B）隊列深度，若是隊列深度持續增加，沒有降低的趨勢須要重點關注。須要查隊列增加的緣由。不一樣的隊列增加的緣由也是不一樣的。若是是本地隊列增加過快，查應用程序爲何沒有取走消息。若是是傳輸隊列，多是通道或者網絡有問題，消息沒法傳輸

3，重點關注如下參數配置

A）tcp參數：

修改WebSphere MQ系統配置文件mqs.ini，增長以下一節：TCP：

KeepAlive=Yes

B）修改操做系統的TCP/IP參數：

tcp_keepidle保持TCP/IP鏈接的時間，單位爲0.5秒，缺省值爲14,400，即兩個小時，咱們可將它設爲5分鐘；

tcp_keepinittcp鏈接初始timeout值，單位爲0.5秒，缺省值爲150，咱們可將它設爲50；

tcp_keepintvl鏈接間隔，單位爲0.5秒，缺省值爲150，咱們可將它設爲50；

/usr/sbin/no -o tcp_keepidle=240

/usr/sbin/no -o tcp_keepinit=50

/usr/sbin/no -o tcp_keepintvl=50

須要注意的一點是通道兩端的KeepAlive參數要保持協調一致，若發送端的KeepAlive值小於接收端的KeepAlive值，則當網絡出現故障時，發送端的通道停下來以後，接收端的通道會仍然停不下來。

C）使用AdoptNewMCA

經過修改qm.ini文件的Channels一節進行修改,如：Channels:

AdoptNewMCA=ALL

當MQ接收到啓動通道的請求，可是同時它發現與該通道對應的amqcrsta的進程已經存在，這時，該進程必須首先被中止，而後，通道才能啓動。AdoptNewMCA的做用就是中止這種進程，而且爲新的通道啓動請求啓動一個新的進程。

該屬性能夠將狀態處於running狀態的接收端通道強行終止，從而使發送端的通道啓動或請求操做得以成功。

若是爲某一通道指定了AdoptNewMCA的屬性，可是新的通道因爲"channel is already running"而啓動失敗，則它能夠：

1） 新的通道通知以前的通道中止

2） 若是舊的通道在AdoptNewMCATimeout的時間間隔內沒有接受該中止請求，相應的進程（或線程）被kill掉

3） 若是舊的通道通過步驟2仍未終止，則當第二個AdoptNewMCATimeout時間間隔到達時，MQ終止該通道，同時產生"channelin use"的錯誤。

D） 設置MaxChannels和MaxActiveChannels屬性

MaxChannels和MaxActiveChannels分別表明隊列管理器容許配置的通道的最大個數和容許同時運行的通道的個數，MaxChannels的缺省值是100，MaxActiveChannels的缺省值與MaxChannels相同。若是您的併發通道鏈接個數超過了100，您須要修改這兩個參數。這對於大併發的Client/Server間通信尤其重要。

E）Disconnect interval屬性

DisconnectInterval(DISCINT)是發送和服務類型的通道所具備的一個參數，它的做用是：在它設置的時間間隔內，若是傳輸隊列爲空即通道上沒有消息經過時，通道就會被中止。設置完Disconnect Interval參數以後，當發送方重起通道時，通道就會被正常啓動。

Disconnect Interval的值會地影響通道的性能。若是把Disconnect Interval的值設置得很是小，會致使通道的頻繁啓動；反之，若是把Disconnect Interval的值設置得很大，則意味着即便通道上很長時間沒有消息，系統資源也會被長期佔用，從而影響系統的性能。所以，利用改變 Disconnect Interval的值，咱們能夠有效地改善通道的性能。

當傳輸隊列中沒有消息要傳送時，發送方通道(SDR)、服務器通道(SVR)將在等待了該參數指定的時間間隔後斷開鏈接，中止通道。該參數以秒爲單位，定義新的通道時，若是沒有特別指定，該參數會繼承系統對象的屬性，設爲6000秒，約兩個小時。亦通道連續兩個小時沒有消息發送後就會中止。DISCINT參數設定爲0，通道永遠不會中止。（注：有防火牆的不能設爲0）

F） Heart Beat Interval屬性

與Disconnect Interval(HBINT)相對應的是Heart BeatInterval這一參數(僅針對WebSphere MQ for AIX、HP-UX、OS/二、Sun Solaris、Windows NT/2000 V5.1以上)。它的做用是：在Heart Beat Interval指定的時間間隔內，若是傳輸隊列上沒有一直沒有消息到達，發送方MCA會向接收方MCA發送一個心跳信號，據此給接收方通道以中止的機會，在這種狀況下，它沒必要等待Disconnect Interval超時，也會將通道中止下來。同時，它會釋放用來存貯大消息的內存空間並關閉接收方的隊列。

爲了使HeartBeat Interval和Disconnect Interval這兩個參數更有效地發揮做用，通常狀況下須要讓Heart Beat Interval設置值小於Disconnect Interval設置值。

另外，若是咱們使用的傳輸協議是TCP/IP，咱們也能夠利用設置TCP/IP的socket的SO_KEEPALIVE參數來實現這一功能。設置完 SO_KEEPALIVE參數，並設置時間間隔以後，TCP/IP自己就會按期去檢測另外一端鏈接的狀態，若是對方鏈接已斷開，通道也會被中止。在這裏，TCP/IP的時間間隔也應小於WebSphere MQ通道的Disconnect Interval的值。

G） ShortRetry和LongRetry屬性

在發送類型等類型的通道屬性中，還有四個參數是與通信恢復和通道鏈接有關的，它們是：shortrty,shorttmr,longrty,longtmr,它們的缺省值分別是：10，60，999999999，1200，分別表明短 重試時間間隔和次數以及長重試時間間隔和次數，它們的做用和含義在於當通道從running變爲retrying狀態時，按照這四個參數規定的時間間隔和次數進行通道從新鏈接的嘗試，而且先進行短重試，短重試結束後，再進入長重試。

在設計這四個參數時，要注意如下兩點：

1） 要確保短重試+長重試的時間〉故障恢復時間

例如：假設您估計您的系統故障恢復時間爲1個小時，則要設置shorttmr(time of shortrty)+longtmr(time of shortrty)>2 hours這樣，才能保證在故障恢復以後，通道仍然可以自動進行從新鏈接的嘗試。

2） 重試間隔將影響自動恢復的效率

例如：若是您把短重試總時間設定爲10分鐘，而長重試時間間隔設爲1小時，而網絡在15分鐘後，便已經恢復，但是此時，因爲通道已經進入長重試階段，它將在 1個小時以後，才能經過長重試恢復通道的正常運行。相反，也沒必要把重試間隔設置得過短，應根據須要和用戶的實際狀況進行適中的設置。

H） Batch size屬性

通道的Batchsize(BATCHSZ)值是影響通道性能的一個關鍵參數。在MQ進行消息傳輸時，通道對消息的處理也是在同步點的控制之下並具備交易特性的，在如下條件知足時，它將統一提交一批消息：

當發送的消息個數達到BATCHSZ時；或傳輸隊列爲空，而且在BATCHINT指定的時間間隔內一直沒有消息到達時。

缺省狀況下，通道的Batchsz是50，這是一個較爲合理和優化的設置。一個小的Batch size值會使每條消息佔用大的資源。好比，假設咱們在局域網的狀況下，Batch size值越大，通道的性能越好。然而，在廣域網環境下，要根據網絡情況的好壞來設置該參數，若網絡情況不好，Batch size值越大，可能會致使通道的性能越差。

優化

一、針對MQ和WAS的優化，通常從哪些方面去作，怎樣判斷性能瓶頸出如今哪裏？

如：怎樣合理的配置WAS的線程數和JVM的大小？怎麼發現和處理性能瓶頸？

答：

MQ：

MQ通常不存在性能問題，對內存和CPU消耗比較少。

通常能夠從如下幾個方面對MQ進行性能優化：

1，MQ的API中最耗CPU的是MQCONN、MQDISC、MQOPEN和MQCLOSE，儘可能避免必要地重複使用，最好作相關的鏈接池（本身開發這塊調用的話），批量消息使用一個MQCOMIT。只發送一條消息時用MQPUT1，性能消耗最小。

2，消息大小最好能少於8K，IBM的人說8K就是一個檻，大於它性能就愈來愈差。非重要的、不可丟失的消息，使用非持久性，非持久性消息只會在內存中，不會記日誌，性能比持久性的消息高10倍。

3，日誌分文件系統，/var/mqm/log和/var/mqm分別保存在不一樣的文件系統中，能提升I/O效率。日誌文件儘可能最大化，個數最小化，可減小日誌文件切換頻率，咱們生產上好象就是主日誌64M，5個。

4，根據本身系統真實狀況修改qm.ini中的默認配置，好比說：MaxChannels、MaxActiveChannels和PipeLineLength，當通道鏈接量大的時候應該改大MaxChannels、MaxActiveChannels。設置MCA採用多個線程的方式來傳輸消息需修改PipeLineLength

WAS：

1，WAS通常調優的話針對JVM、線程池、DataSource 鏈接池，

2，參數怎麼調，須要根據實際應用去測試

通常初始化調參能夠試着設置爲如下：

3，須要結合監控數據和實際，去分析系統的瓶頸和優化的方法。