原標(biāo)題：中間件(WAS、WMQ)運(yùn)維 9個常見難點(diǎn)解析

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

安裝

1、was 負(fù)載均衡的機(jī)制的粘連性，was負(fù)載均衡異常？

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

答：

1，這是故障轉(zhuǎn)移，was有內(nèi)部機(jī)制可以做到

1)內(nèi)存到內(nèi)存復(fù)制技術(shù)可以，缺點(diǎn)，因每臺服務(wù)器共享session，所以占用內(nèi)存比較大(如果server很少，可以考慮使用)。

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

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

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

答：

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

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

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

答：

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

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

低版本注意事項(xiàng)：

1，規(guī)劃好磁盤空間，內(nèi)存和CPU

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

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

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

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

巡檢

1、針對WAS例行巡檢，一般有哪些檢查點(diǎn)？每個檢查點(diǎn)判斷的標(biāo)準(zhǔn)是什么？

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

答：

1,WAS DM node server的進(jìn)程狀態(tài)，was自帶狀態(tài)命令。結(jié)合系統(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è)置、線程池參數(shù)設(shè)置，標(biāo)準(zhǔn)應(yīng)該參照客戶的規(guī)范或者以通用參數(shù)設(shè)置為標(biāo)準(zhǔn)，

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

2、該如何分析Javacore(was中間件)

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

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

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

答：

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

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設(shè)置256-1280，幾乎每個月總會有JVM宕機(jī)重啟發(fā)生，這正常嗎？

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

答：

1，首先你需要確認(rèn)OOM是因?yàn)閮?nèi)存不夠?qū)е聝?nèi)存溢出還是因?yàn)閼?yīng)用代碼不規(guī)范存在內(nèi)存泄露。

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

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

4，可以看下應(yīng)用是否有內(nèi)存泄露，注意下GC日志，分析下。

監(jiān)控

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

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

答：

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

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

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

2、針對MQ的監(jiān)控，一般有哪些指標(biāo)值得我們?nèi)リP(guān)注？請列舉說明

如：MQ的隊(duì)列深度、日志報錯等

答：

MQ巡檢一般情況關(guān)注三個方面。

1，錯誤日志。

A)qmgr 錯誤日志：默認(rèn)目錄 /var/mqm/qmgrs//errors/AMQERR01.log，AMQERR02.log，AMQERR03.log

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

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

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

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

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

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

B)隊(duì)列深度，如果隊(duì)列深度持續(xù)增長，沒有下降的趨勢需要重點(diǎn)關(guān)注。需要查隊(duì)列增長的原因。不同的隊(duì)列增長的原因也是不同的。如果是本地隊(duì)列增長過快，查應(yīng)用程序?yàn)槭裁礇]有取走消息。如果是傳輸隊(duì)列，可能是通道或者網(wǎng)絡(luò)有問題，消息無法傳輸

3，重點(diǎn)關(guān)注以下參數(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，即兩個小時，我們可將它設(shè)為5分鐘；

tcp_keepinittcp連接初始timeout值，單位為0.5秒，缺省值為150，我們可將它設(shè)為50；

tcp_keepintvl連接間隔，單位為0.5秒，缺省值為150，我們可將它設(shè)為50；

/usr/sbin/no -o tcp_keepidle=240

/usr/sbin/no -o tcp_keepinit=50

/usr/sbin/no -o tcp_keepintvl=50

需要注意的一點(diǎn)是通道兩端的KeepAlive參數(shù)要保持協(xié)調(diào)一致，若發(fā)送端的KeepAlive值小于接收端的KeepAlive值，則當(dāng)網(wǎng)絡(luò)出現(xiàn)故障時，發(fā)送端的通道停下來之后，接收端的通道會仍然停不下來。

C)使用AdoptNewMCA

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

AdoptNewMCA=ALL

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

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

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

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

2) 如果舊的通道在AdoptNewMCATimeout的時間間隔內(nèi)沒有接受該停止請求，相應(yīng)的進(jìn)程(或線程)被kill掉

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

D) 設(shè)置MaxChannels和MaxActiveChannels屬性

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

E)Disconnect interval屬性

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

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

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

F) Heart Beat Interval屬性

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

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

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

G) ShortRetry和LongRetry屬性

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

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

1) 要確保短重試+長重試的時間〉故障恢復(fù)時間

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

2) 重試間隔將影響自動恢復(fù)的效率

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

H) Batch size屬性

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

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

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

優(yōu)化

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

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

答：

MQ：

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

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

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

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

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

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

WAS：

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

2，參數(shù)怎么調(diào)，需要根據(jù)實(shí)際應(yīng)用去測試

一般初始化調(diào)參可以試著設(shè)置為以下：

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

責(zé)任編輯：

總結(jié)

以上是生活随笔為你收集整理的was这么做的负载均衡_中间件（WAS、WMQ）运维 9个常见难点解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。