包括WAS、WMQ在安裝、巡檢、監控、優化過程中的常見難點。
安裝
1、was 負載均衡的機制的粘連性，was負載均衡異常？
有一個case系統，部署在was集群環境，應用是集群環境，有的時候當一個節點異常的時，客戶端訪問該系統就會拋出異常，按正常情況，該會話應該不會斷或者斷了再連接一次就會到另一個節點，但是好多時候不管客戶端如何連接，都不行，該正常的客戶端一直是正常的，不正常重啟機器也不正常。當然其他新連接的節點也沒啥問題，直到重啟了故障節點的應用，原先不能正常訪問的客戶端才正常，就算當時清除瀏覽器緩存也不好使，哪位有這方面的經驗可以多談談。
答：
1，這是故障轉移，was有內部機制可以做到
1）內存到內存復制技術可以，缺點，因每台服務器共享session，所以占用內存比較大（如果server很少，可以考慮使用）。
2）存儲到數據苦或者其他地方也可以實現。推薦使用，但是實現較復雜
2、如何大批量的完成WAS的安裝和部署？有哪些工具和方法？
如：幾百台或上千台WAS服務器的安裝和部署
答：
1，wsadmin 去寫腳本是個好辦法，配合虛擬化去做。
2，還有上千台的已經不適合去用商業軟件了，建議去考慮下開源的軟件，或者雲平台了。
3、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不通版本是有差異的。
巡檢
1、針對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)，這經常性的是一個過程性的問題，需要具體分析。
2、該如何分析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。
3、我們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日志，分析下。
監控
1、WAS JVM使用率該如何合理監控？
如果只是監控WAS HEAP USED%，那告警頻率太高，如果開啟了GC，那么GC頻率結合WAS HEAP USED%是否是個好的監控方法？那么GC頻率的閥值該如何設置？
答：
這個並沒有定論：JVM 堆內存太低會導致GC頻繁，而JVM對內存太大，導致GC時間太長，影響應用訪問，如果並發又比較大，又存在大對象、處理的數據量又比較大，應用對數據有沒有特殊處理，那發生高CPU的問題會很頻繁。
所以沒有固定值，適合自己系統的需要測試嘍！
可以開啟詳細垃圾回收，然后自己測試GC間隔時長，然后做出判斷。
2、針對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/2、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值越大，可能會導致通道的性能越差。
優化
1、針對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，需要結合監控數據和實際，去分析系統的瓶頸和優化的方法。