本文由社區(qū)中間件達人wangxuefeng266、ayy216226分享整理，包括WAS、WMQ在安裝、巡檢、監(jiān)控、優(yōu)化過程中的常見難點。

?安裝?

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

有一個case系統(tǒng)，部署在was集群環(huán)境，應用是集群環(huán)境，有的時候當一個節(jié)點異常的時，客戶端訪問該系統(tǒng)就會拋出異常，按正常情況，該會話應該不會斷或者斷了再連接一次就會到另一個節(jié)點，但是好多時候不管客戶端如何連接，都不行，該正常的客戶端一直是正常的，不正常重啟機器也不正常。當然其他新連接的節(jié)點也沒啥問題，直到重啟了故障節(jié)點的應用，原先不能正常訪問的客戶端才正常，就算當時清除瀏覽器緩存也不好使，哪位有這方面的經(jīng)驗可以多談談。

答：

1，這是故障轉移，was有內部機制可以做到

1）內存到內存復制技術可以，缺點，因每臺服務器共享session，所以占用內存比較大（如果server很少，可以考慮使用）。

2）存儲到數(shù)據(jù)苦或者其他地方也可以實現(xiàn)。推薦使用，但是實現(xiàn)較復雜

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

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

答：

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

2，還有上千臺的已經(jīng)不適合去用商業(yè)軟件了，建議去考慮下開源的軟件，或者云平臺了。

3、was安裝低版本升級需要注意哪些方面？需要重新繳費嗎？

答：

1，was 6 官方已經(jīng)不再提供支持，除非額外買服務。

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，規(guī)劃好磁盤空間，內存和CPU

2，規(guī)劃好安裝目錄，盡量做到安裝目錄統(tǒng)一，規(guī)范。

3，了解好業(yè)務量大小，并發(fā)等等，方便你設計你的was部署方案。

4，調參數(shù)時注意結合實際，并沒有完全統(tǒng)一的配置。

5，升級前當然要在測試環(huán)境測試后在驚醒生產(chǎn)，JDK版本，及WAS不通版本是有差異的。

?巡檢?

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

例如：巡檢WAS，需要檢查文件系統(tǒng)、CPU是否高、線程過載、JVM性能、JDBC等方面是否正常。一般以磁盤空間未占滿60%，CPU低，未發(fā)生線程過載等判斷是否存在問題。

答：

1,WAS DM node server的進程狀態(tài)，was自帶狀態(tài)命令。結合系統(tǒng)命令查看。

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 參數(shù)設置、線程池參數(shù)設置，標準應該參照客戶的規(guī)范或者以通用參數(shù)設置為標準，

5，如果有性能問題時需要查看系統(tǒng)運行情況：內存、CPU，如經(jīng)常發(fā)生的內存泄露問題，有可能是堆內存(heap)或本地內存(native)，這經(jīng)常性的是一個過程性的問題，需要具體分析。

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

平常的故障中，一般都是需要分析javacore。也是夠頭疼的了。

一般在得到幾個javacore文件之后，就想到可以用IBM Thread and Monitor Dump Analyzer for Java工具去協(xié)助分析，不過。。。好像沒有找到如何分析的教程，看來很多文章，還是沒有頭緒。。

我們應該去關注那個Current Thread？還是Thread Detail里面的哪些線程捏？關注Blocked和僵死狀態(tài)的線程？？應該從那個開始著手呀？

答：

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

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。

3、我們ERP中WAS版本比較低，JVM設置256-1280，幾乎每個月總會有JVM宕機重啟發(fā)生，這正常嗎？

WAS版本5.1。JVM宕機重啟原因大多是由于內存溢出導致，曾經(jīng)試著給堆擴容至2048，仍會有宕機發(fā)生，從網(wǎng)上搜了不少資料，有人也建議設置定時重啟，這正常嗎？不能從根本是杜絕WAS宕機重啟嗎？

答：

1，首先你需要確認OOM是因為內存不夠導致內存溢出還是因為應用代碼不規(guī)范存在內存泄露。

2，內存也不是越大越好，需要和你你自己的環(huán)境。

3，JVM參數(shù)配置需要看你OS 平臺 32 位有限制，64位理論上來說沒有限制，但是考慮到GC時間 最好不要調的過大，而最小JVM內存如果太小則會頻繁GC。

4，可以看下應用是否有內存泄露，注意下GC日志，分析下。

?監(jiān)控?

1、WAS JVM使用率該如何合理監(jiān)控？

如果只是監(jiān)控WAS HEAP USED%，那告警頻率太高，如果開啟了GC，那么GC頻率結合WAS HEAP USED%是否是個好的監(jiān)控方法？那么GC頻率的閥值該如何設置？

答：

這個并沒有定論：JVM 堆內存太低會導致GC頻繁，而JVM對內存太大，導致GC時間太長，影響應用訪問，如果并發(fā)又比較大，又存在大對象、處理的數(shù)據(jù)量又比較大，應用對數(shù)據(jù)有沒有特殊處理，那發(fā)生高CPU的問題會很頻繁。

所以沒有固定值，適合自己系統(tǒng)的需要測試嘍！

可以開啟詳細垃圾回收，然后自己測試GC間隔時長，然后做出判斷。

2、針對MQ的監(jiān)控，一般有哪些指標值得我們去關注？請列舉說明

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

答：

MQ巡檢一般情況關注三個方面。

1，錯誤日志。

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

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

除了上述錯誤，可以把平時運行中常見報錯，記錄下來，作為日后巡檢的參考。

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

這個目錄等錯誤一般和軟件運行有關的錯誤，如果有錯誤該重點關注，且詳細分析每一條錯誤的原因。FDC文件則是mq軟件運行有問題時的堆棧信息，可以通過這個文件判斷是否mq本身的bug。

2，MQ運行狀態(tài)

A）通道的狀態(tài)，非running的狀態(tài)都是有問題的。需要結合日志判斷通道終止或者binding的原因。

B）隊列深度，如果隊列深度持續(xù)增長，沒有下降的趨勢需要重點關注。需要查隊列增長的原因。不同的隊列增長的原因也是不同的。如果是本地隊列增長過快，查應用程序為什么沒有取走消息。如果是傳輸隊列，可能是通道或者網(wǎng)絡有問題，消息無法傳輸

3，重點關注以下參數(shù)配置

A）tcp參數(shù)：

修改WebSphere MQ系統(tǒng)配置文件mqs.ini，增加如下一節(jié)：TCP：

KeepAlive=Yes

B）修改操作系統(tǒng)的TCP/IP參數(shù)：

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參數(shù)要保持協(xié)調一致，若發(fā)送端的KeepAlive值小于接收端的KeepAlive值，則當網(wǎng)絡出現(xiàn)故障時，發(fā)送端的通道停下來之后，接收端的通道會仍然停不下來。

C）使用AdoptNewMCA

通過修改qm.ini文件的Channels一節(jié)進行修改,如：Channels:

AdoptNewMCA=ALL

當MQ接收到啟動通道的請求，但是同時它發(fā)現(xiàn)與該通道對應的amqcrsta的進程已經(jīng)存在，這時，該進程必須首先被停止，然后，通道才能啟動。AdoptNewMCA的作用就是停止這種進程，并且為新的通道啟動請求啟動一個新的進程。

該屬性可以將狀態(tài)處于running狀態(tài)的接收端通道強行終止，從而使發(fā)送端的通道啟動或請求操作得以成功。

如果為某一通道指定了AdoptNewMCA的屬性，但是新的通道由于"channel is already running"而啟動失敗，則它可以：

1） 新的通道通知之前的通道停止

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

3） 如果舊的通道經(jīng)過步驟2仍未終止，則當?shù)诙€AdoptNewMCATimeout時間間隔到達時，MQ終止該通道，同時產(chǎn)生"channelin use"的錯誤。

D） 設置MaxChannels和MaxActiveChannels屬性

MaxChannels和MaxActiveChannels分別代表隊列管理器允許配置的通道的最大個數(shù)和允許同時運行的通道的個數(shù)，MaxChannels的缺省值是100，MaxActiveChannels的缺省值與MaxChannels相同。如果您的并發(fā)通道連接個數(shù)超過了100，您需要修改這兩個參數(shù)。這對于大并發(fā)的Client/Server間通訊尤為重要。

E）Disconnect interval屬性

DisconnectInterval(DISCINT)是發(fā)送和服務類型的通道所具有的一個參數(shù)，它的作用是：在它設置的時間間隔內，如果傳輸隊列為空即通道上沒有消息通過時，通道就會被停止。設置完Disconnect Interval參數(shù)之后，當發(fā)送方重起通道時，通道就會被正常啟動。

Disconnect Interval的值會地影響通道的性能。如果把Disconnect Interval的值設置得非常小，會導致通道的頻繁啟動；反之，如果把Disconnect Interval的值設置得很大，則意味著即使通道上很長時間沒有消息，系統(tǒng)資源也會被長期占用，從而影響系統(tǒng)的性能。因此，利用改變 Disconnect Interval的值，我們可以有效地改善通道的性能。

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

F） Heart Beat Interval屬性

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

為了使HeartBeat Interval和Disconnect Interval這兩個參數(shù)更有效地發(fā)揮作用，一般情況下需要讓Heart Beat Interval設置值小于Disconnect Interval設置值。

另外，如果我們使用的傳輸協(xié)議是TCP/IP，我們也可以利用設置TCP/IP的socket的SO_KEEPALIVE參數(shù)來實現(xiàn)這一功能。設置完 SO_KEEPALIVE參數(shù)，并設置時間間隔之后，TCP/IP本身就會定期去檢測另一端連接的狀態(tài)，如果對方連接已斷開，通道也會被停止。在這里，TCP/IP的時間間隔也應小于WebSphere MQ通道的Disconnect Interval的值。

G） ShortRetry和LongRetry屬性

在發(fā)送類型等類型的通道屬性中，還有四個參數(shù)是與通訊恢復和通道連接有關的，它們是：shortrty,shorttmr,longrty,longtmr,它們的缺省值分別是：10，60，999999999，1200，分別代表短 重試時間間隔和次數(shù)以及長重試時間間隔和次數(shù)，它們的作用和含義在于當通道從running變?yōu)閞etrying狀態(tài)時，按照這四個參數(shù)規(guī)定的時間間隔和次數(shù)進行通道重新連接的嘗試，并且先進行短重試，短重試結束后，再進入長重試。

在設計這四個參數(shù)時，要注意以下兩點：

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

例如：假設您估計您的系統(tǒng)故障恢復時間為1個小時，則要設置shorttmr(time of shortrty)+longtmr(time of shortrty)>2 hours這樣，才能保證在故障恢復之后，通道仍然能夠自動進行重新連接的嘗試。

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

例如：如果您把短重試總時間設定為10分鐘，而長重試時間間隔設為1小時，而網(wǎng)絡在15分鐘后，便已經(jīng)恢復，可是此時，由于通道已經(jīng)進入長重試階段，它將在 1個小時之后，才能通過長重試恢復通道的正常運行。相反，也不必把重試間隔設置得太短，應根據(jù)需要和用戶的實際情況進行適中的設置。

H） Batch size屬性

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

當發(fā)送的消息個數(shù)達到BATCHSZ時；或傳輸隊列為空，并且在BATCHINT指定的時間間隔內一直沒有消息到達時。

缺省情況下，通道的Batchsz是50，這是一個較為合理和優(yōu)化的設置。一個小的Batch size值會使每條消息占用大的資源。比如，假設我們在局域網(wǎng)的情況下，Batch size值越大，通道的性能越好。然而，在廣域網(wǎng)環(huán)境下，要根據(jù)網(wǎng)絡狀況的好壞來設置該參數(shù)，若網(wǎng)絡狀況很差，Batch size值越大，可能會導致通道的性能越差。

?優(yōu)化?

1、針對MQ和WAS的優(yōu)化，一般從哪些方面去做，怎樣判斷性能瓶頸出現(xiàn)在哪里？

如：怎樣合理的配置WAS的線程數(shù)和JVM的大??？怎么發(fā)現(xiàn)和處理性能瓶頸？

答：

MQ：

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

一般可以從以下幾個方面對MQ進行性能優(yōu)化：

1，MQ的API中最耗CPU的是MQCONN、MQDISC、MQOPEN和MQCLOSE，盡量避免必要地重復使用，最好做相關的連接池（自己開發(fā)這塊調用的話），批量消息使用一個MQCOMIT。只發(fā)送一條消息時用MQPUT1，性能消耗最小。

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

3，日志分文件系統(tǒng)，/var/mqm/log和/var/mqm分別保存在不同的文件系統(tǒng)中，能提高I/O效率。日志文件盡量最大化，個數(shù)最小化，可減少日志文件切換頻率，我們生產(chǎn)上好象就是主日志64M，5個。

4，根據(jù)自己系統(tǒng)真實情況修改qm.ini中的默認配置，比如說：MaxChannels、MaxActiveChannels和PipeLineLength，當通道連接量大的時候應該改大MaxChannels、MaxActiveChannels。設置MCA采用多個線程的方式來傳輸消息需修改PipeLineLength

WAS：

1，WAS一般調優(yōu)的話針對JVM、線程池、DataSource 連接池，

2，參數(shù)怎么調，需要根據(jù)實際應用去測試

一般初始化調參可以試著設置為以下：

3，需要結合監(jiān)控數(shù)據(jù)和實際，去分析系統(tǒng)的瓶頸和優(yōu)化的方法。

點擊閱讀原文關注社區(qū)"中間件"技術主題?，將會不斷更新優(yōu)質資料、文章，您也可以前往提出疑難問題，與同行切磋交流。

在這里給大家整理了從事阿里 網(wǎng)易 百度等java開發(fā)10多年的大牛學習資料 添加QQ733234221群領?。。ㄕ心贾校?/span>