安装1、负载均衡机制粘连，负载均衡是否异常？有一个部署在was集群环境下的案例系统，应用是集群环境。有时当某个节点出现异常时，客户端访问系统时会抛出异常。按照正常情况，session是不应该断掉的，否则断掉后会去别的节点。不管怎么连接，正常的client一直都是正常的，异常重启机器也不正常。当然，其他新连接的节点是没有问题的。直到故障节点的应用重启后，无法正常访问的客户端才会正常。即使当时清除了浏览器缓存，也没有用。谁有这方面的经验可以多谈。答：1.这是故障转移。是有一个可以做到这一点的内部机制。1）内存到内存复制技术成为可能。缺点是每个服务器共享一个session，所以占用内存比较大（如果服务器很少，可以考虑使用）。2）也可以存放在数据存储器或其他地方。推荐使用，但是实现比较复杂。2、如何完成大批量WAS的安装部署？有哪些工具和方法？比如：安装部署成百上千台WAS服务器答：1、wsadmin的任务是写脚本，用虚拟化来做是个好办法。2、还有几千台已经不适合做商业软件了。建议考虑开源软件或者云平台。3、安装低版本的was需要注意哪些方面？我需要再次付款吗？答：1.was6官方不再提供支持，除非购买额外的服务。2.从2018年4月开始，JavaSE6将不再支持与WebSphereApplicationServer一起使用。2018-04-30建议更新JavaSE7或83，WASV7.0.x和V8.0.x及PortalServerV8.0.x低版本注意事项：1.规划磁盘空间、内存和CPU2，规划安装目录，尽量使安装目录统一规范。3.了解业务量大小，并发量等，以便设计你的was部署方案。4、调整参数要注意实际情况，没有完全统一的配置。5、升级前，当然要在测试环境测试完后唤醒生产。JDK版本和WAS版本是有区别的。检查1.WAS的例行检查，一般检查点有哪些？每个检查点的标准是什么？比如：检查WAS，需要检查文件系统，CPU是否高，线程过载，JVM性能，JDBC等方面是否正常。一般以磁盘空间未占用60%，CPU低，未出现线程过载来判断是否有问题。Answer:1.WASDM节点服务器的进程状态，是有自己的status命令的。结合系统命令查看。2、服务器的was_home/profiles/node/logs/server下：SystemOut.logSystemErr.lognative_stderr.lognative_stdout.log3、was_home/profiles/node/logs/ffdclog4、检查需要检查JVM参数设置和threadpool参数设置，标准参考客户规范或设置通用参数为标准。5.如果出现性能问题，需要检查系统运行：内存，CPU，比如频繁的内存泄漏，可能是堆内存（heap）或者本地内存（native），这往往是程序问题，需要具体分析。2、如何分析Javacore（是中间件）在正常故障中，一般需要分析javacore。真是够头疼的。一般来说，在得到几个javacore文件后，我认为我可以使用IBMThreadandMonitorDumpAnalyzerforJava工具来辅助分析，但是。..好像没有教程是怎么分析的。看来很多文章还是没有头绪。.我们应该关注当前线程吗？或者线程详细信息中的哪些线程？注意阻塞和死线程？我们应该从那开始吗？答：不是三言两语说清楚的，需要积累知识，介绍几个Documentation：1、IBM提供了javacore、GC和heapdump的集成工具，叫做IBMSupportAssistant2，http://www-01.ibm.com/support/docview.wss?uid=swg21181068#2.1.13，IBMJava626。pdf去读这本书，清楚地了解JVM。3、我们ERP中的WAS版本比较低，JVM设置为256-1280。几乎每个月，总会有一次JVM关机重启。这是正常的吗？是5.1版。JVM宕机重启的原因，大部分都是内存溢出。我已经尝试将堆扩展到2048，但仍然会出现停机时间。在网上查了很多资料，也有人建议设置定时重启。这是正常的吗？不能从根本上防止WAS死机重启吗？答：1、首先需要确认OOM是由于内存不足，导致内存溢出，还是因为应用代码不规范，存在内存泄漏。2、内存越大越好，需要配合自己的环境。3.JVM参数配置取决于您的操作系统平台。32位是有限的，64位理论上是无限的。但是考虑到GC时间，最好不要调整太大，如果最小JVM内存太小，会出现频繁的GC。4、可以查看应用是否有内存泄漏，关注GC日志，分析一下。监控1.如何正确监控WASJVM的使用情况？如果只监控WASHEAPUSED%，报警频率太高。如果启用了GC，GC频率结合WASHEAPUSED%是否是一个好的监控方法？那么GC频率的阈值怎么设置呢？答：这个没有定论：JVM堆内存太低会导致频繁GC，而JVM内存太多，导致GC时间太长，影响应用程序访问，如果并发量比较大，有大对象，量需要处理的数据量比较大，应用程序是否对数据进行了特殊处理，会经常出现高CPU的问题。所以没有固定值，适合自己系统的需要去测试！可以开启详细的垃圾回收，然后自己测试GC间隔，再做判断。2、对于MQ监控，一般有哪些指标值得我们关注？请列举并说明如：MQ队列深度、日志报错等。答：MQ检查一般侧重于三个方面。1.错误日志。a)qmgr错误日志：默认目录/var/mqm/qmgrs//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文件这个目录下的errors一般都是软件运行相关的错误，如果有错误，关注一下详细分析它们每个错误的原因。FDC文件是mq软件运行出现问题时的堆栈信息。您可以使用此文件来确定mq本身是否存在错误。2、MQ运行状态A）通道状态和非运行状态都有问题。您需要结合日志来确定通道终止或绑定的原因。b)队列深度，如果队列深度持续增长且没有下降趋势，则需要注意。需要检查队列增长的原因。不同的队列因不同的原因而增长。如果本地队列增长太快，请检查应用程序未接收消息的原因。如果是传输队列，可能是通道或网络有问题，无法传输消息。3、重点配置以下参数A)tcp参数：修改WebSphereMQ系统配置文件mqs.ini，增加如下部分：TCP:KeepAlive=YesB)修改操作系统的TCP/IP参数：tcp_keepidle维护TCP/IP连接时间，单位是0.5秒，默认值是14400，也就是两个小时，我们可以设置成5分钟；tcp_keepinittcp连接初始超时值，单位为0.5秒，默认值为150，我们可以设置为50；tcp_keepintvl连接间隔，单位为0.5秒，默认值为150，我们可以设置为50；/usr/sbin/no-otcp_keepidle=240/usr/sbin/no-otcp_keepinit=50/usr/sbin/no-otcp_keepintvl=50需要注意的是通道两端的KeepAlive参数必须保持一致。发生故障时，发送端通道停止后，接收端通道仍不会停止。c）使用AdoptNewMCA修改qm.ini文件的Channels部分，如：Channels:AdoptNewMCA=ALL当MQ收到启动通道的请求，但同时发现该通道对应的amqcrsta进程已经存在存在，则必须先停止进程，然后才能启动通道。AdoptNewMCA的作用是停止这个进程，并为一个新的通道启动请求启动一个新的进程。该属性可以强制终止处于运行状态的接收端通道，从而使发送端的通道启动或请求操作能够成功。如果一个通道指定了AdoptNewMCA属性，但是新通道由于“通道已经运行”而启动失败，可以：1）新通道通知前一个通道停止2）如果旧通道在时间之内在AdoptNewMCATimeout的区间内没有接受停止请求，相应的进程（或线程）被杀死。3）如果旧通道在步骤2之后还没有终止，那么当第二个AdoptNewMCATimeout时间间隔到来时，MQ终止通道并产生“channelinuse”错误。d)设置MaxChannels和MaxActiveChannels属性MaxChannels和MaxActiveChannels分别表示队列管理器允许配置的最大通道数和允许同时运行的通道数。MaxChannels默认值为100，MaxActiveChannels默认值与MaxChannels相同。如果你的通道并发连接数超过100，你需要修改这两个参数。这对于大型并发客户端/服务器通信尤其重要。E)断开间隔属性DisconnectInterval(DISCINT)是发送和服务类型通道的参数。它的作用是：在它设定的时间间隔内，如果传输队列为空，即没有消息通过通道时，通道就会停止。设置DisconnectInterval参数后，当发送方重启通道时，通道会正常启动。DisconnectInterval的取值将极大地影响通道的性能。如果DisconnectInterval的值设置得太小，会导致通道频繁启动；反之，如果DisconnectInterval的值设置的很大，则意味着即使通道上很长时间没有消息，也会长期占用系统资源，从而影响系统的性能.因此，通过改变DisconnectInterval的值，我们可以有效的提升通道的性能。当传输队列中没有消息要传输时，发送者通道（SDR）和服务器通道（SVR）将在等待该参数指定的时间间隔后断开连接，并停止通道。该参数以秒为单位。定义新通道时，如果不指定，该参数将继承系统对象的属性。将它设置为6000秒，大约两个小时。此外，该频道将在两个小时没有发送消息后停止。将DISCINT参数设置为0时，通道永不停止。（注意：如果有防火墙不能设置为0）F）HeartBeatInterval属性和DisconnectInterval（HBINT）对应HeartBeatInterval参数（仅适用于WebSphereMQforAIX,HP-UX,OS/2、SunSolaris、WindowsNT/2000V5.1或以上）。它的作用是：在HeartBeatInterval规定的时间间隔内，如果没有消息到达传输队列，发送方MCA会向接收方MCA发送一个心跳信号，从而给接收方通道一个停止的机会。在这种情况下，它不必等待DisconnectInterval超时，还可以停止通道。同时，它释放用于存储大消息的内存空间并关闭接收者的队列。为了让HeartBeatInterval和DisconnectInterval这两个参数更有效的工作，一般需要让HeartBeatInterval的设置值小于DisconnectInterval的设置值。另外，如果我们使用的传输协议是TCP/IP，也可以通过TCP/IP套接字的SO_KEEPALIVE参数来实现这个功能。在设置了SO_KEEPALIVE参数并设置了时间间隔后，TCP/IP自身会周期性的检查对方的连接状态。如果另一端断开连接，通道也将停止。这里TCP/IP的时间间隔也应该小于WebSphereMQ通道的DisconnectInterval的值。G)ShortRetry和LongRetry属性在发送类型等信道属性中，有四个与通信恢复和信道连接相关的参数，它们是：shortrty、shorttmr、longrty、longtmr，它们的默认值分别是：10、60、999999999,1200分别代表短重试间隔和次数和长重试间隔和次数。它们的作用和含义是当通道从运行状态变为重试状态时，根据这四个参数指定的时间间隔和通道重试次数，先进行短重试，短重试结束后，再进入长重试。在设计这四个参数时，需要注意以下两点：1）确保短重试+长重试的时间>故障恢复时间例如：假设你估计你的系统故障恢复时间为1小时，你需要设置shorttmr(timeofshortrty)+longtmr(timeofshortrty)>2小时，保证故障恢复后通道仍能自动尝试重连。2）重试间隔会影响自动恢复的效率。例如：如果设置短重试总时间为10分钟，长重试间隔时间为1小时，15分钟后网络已经恢复，但此时由于通道进入长重试阶段，需要1小时才能通过长重试恢复通道的正常运行。相反，重试间隔没有必要设置得太短，应该根据需要和用户的实际情况适度设置。h)Batchsize属性通道的Batchsize(BATCHSZ)值是影响通道性能的关键参数。MQ在传输消息时，通道对消息的处理也是在同步点的控制下，具有事务特性。当满足以下条件时，统一提交一批消息：当发送消息数达到BATCHSZ时；或者当传输队列为空并且在BATCHINT指定的时间间隔内没有消息到达时。默认情况下，通道的Batchsz为50，这是一个合理且最优的设置。较小的Batchsize值会使每条消息占用大量资源。例如，假设我们在局域网的情况下，Batchsize值越大，通道的性能越好。但是在广域网环境下，这个参数应该根据网络质量来设置。如果网络状况不佳，Batchsize值越大，通道的性能可能越差。优化1、MQ和WAS的优化，一般要做哪些方面的工作，如何判断性能瓶颈出现在哪里？比如：如何合理配置WAS的线程数和JVM的大小？如何发现和处理性能瓶颈？答：MQ：MQ一般不会有性能问题，消耗内存和CPU较少。一般来说，MQ的性能可以从以下几个方面进行优化：1.MQAPI中MQCONN、MQDISC、MQOPEN和MQCLOSE是消耗CPU最多的。块调用），批处理消息使用一个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使用多线程传输消息，需要修改PipeLineLengthWAS：1.WAS一般调的话，针对JVM，线程池，DataSource连接池。2、如何调整参数需要根据实际应用进行测试。一般的初始化调优参数可以尝试设置如下：3.需要结合监控数据和实际分析系统瓶颈，优化方法。
