为您推荐:
精华内容
最热下载
问答
  • 5星
    8KB weixin_43723517 2021-10-09 13:38:01
  • 5星
    6KB weixin_43723517 2021-01-28 22:05:30
  • 12.13MB joe1212 2015-07-11 21:31:33
  • was运维安装好的,我只是简单配置了一下概要,第一次搞,没想到遇到了这么多坑,另外,英语好是真重要。 1.首先是官网配置 这三个命令很重要,是在was根目录下面,我的是/opt/IBM/WebSphere/Appserver/bin 1.列出...

    was是运维安装好的,我只是简单配置了一下概要,第一次搞,没想到遇到了这么多坑,另外,英语好是真重要。

    1.首先是官网配置

    这三个命令很重要,是在was根目录下面,我的是/opt/IBM/WebSphere/Appserver/bin

    1.列出现有概要文件
    ./manageprofiles.sh -listProfiles
    2.刷新概要文件注册表
    ./manageprofiles.sh -validateAndUpdateRegistry
    3.删除概要文件
    ./manageprofiles.sh -delete -profileName Dmgr01
    ./manageprofiles.sh -delete -profileName AppSrv01
    

    第一步 :创建管理摘要
    /opt/IBM/WebSphere/Appserver/目录下创建文件

    cat >> _portdef_DMgr.props
    
    CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=9403
    WC_adminhost=9060
    DCS_UNICAST_ADDRESS=9352
    BOOTSTRAP_ADDRESS=9809
    SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=9401
    CELL_DISCOVERY_ADDRESS=7277
    SOAP_CONNECTOR_ADDRESS=8879
    ORB_LISTENER_ADDRESS=9100
    CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=9402
    WC_adminhost_secure=9043
    

    还是在这个目录,创建管理概要

    ./manageprofiles.sh -create -templatePath  /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr -profileName  Dmgr01 -profilePath   /opt/IBM/WebSphere/AppServer/profiles/Dmgr01 -portsFile    /opt/IBM/WebSphere/AppServer/_portdef_DMgr.props
    

    第二步:创建应用概要
    /opt/IBM/WebSphere/Appserver/目录下创建文件

    cat >> _portdef_AppSvr.props
    
    CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=9201
    DCS_UNICAST_ADDRESS=9353
    NODE_DISCOVERY_ADDRESS=7272
    NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS=5001
    BOOTSTRAP_ADDRESS=2809
    SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=9901
    SOAP_CONNECTOR_ADDRESS=8878
    NODE_MULTICAST_DISCOVERY_ADDRESS=5000
    ORB_LISTENER_ADDRESS=9101
    CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=9202
    

    创建完毕之后执行

    ./manageprofiles.sh -create -templatePath  /opt/IBM/WebSphere/AppServer/profileTemplates/default -profileName  AppSvr02 -profilePath   /opt/IBM/WebSphere/AppServer/profiles/AppSvr02 -portsFile    /opt/IBM/WebSphere/AppServer/_portdef_AppSvr.props
    

    第三步:启动管理节点

    /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/startManager.sh
    

    第四步:查看SOAP端口

    grep SOAP /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/logs/AboutThisProfile.txt
    得到管理 SOAP 连接器端口: 8879
    

    第五步:增加应用概要

    /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/addNode.sh 127.0.0.1 8879
    

    如果添加时出错,例如:The system cannot create a SOAP connector to connect to host 127.0.0.1 at port 8879
    此时 使用命令 hostname 得到主机名
    切换到“/opt/IBM/WebSphere/AppServer/profiles/AppSrv02/bin/”下:
    执行 :./syncNode.sh 主机名 8879

    第六步:启动

    /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/startNode.sh
    

    此时如果出现端口被占用的情况

    这时候

    ps -ef | grep java
    ps -ef | grep was
    

    能结束掉的进程都结束掉

    第七步:这个时候就可以通过浏览器访问was控制平台

    http://你的ip地址:9060/ibm/console/login.do
    

    然后开始新建服务server1
    第八步:再命令行开启server1服务

    cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/
    ./startServer.sh server1
    
    

    此时如果发现网页登录不了,那么你就去查看一下你服务器的防火墙状态

     service iptables status
     一般都是开着的,如果开着的话就关闭就好了
     service iptables stop
     当然,你也可以设置filter让特定IP访问
    

    完毕收工。

    2.简单化配置

    不需要创建 _portdef_AppSvr.props以及_portdef_DMgr.props文件
    直接创建两个概要

    创建管理概要
    ./manageprofiles.sh
    -create
    -profileName  Dmgr01
    -profilePath  /opt/IBM/WebSphere/AppServer/profiles/Dmgr01
    -templatePath  /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr/
    
    创建应用概要
    ./manageprofiles.sh
    -create
    -templatePath  /opt/IBM/WebSphere/AppServer/profileTemplates/default 
    -profileName  AppSvr02
    -profilePath   /opt/IBM/WebSphere/AppServer/profiles/AppSvr02 
    
    

    这样也是可以的。

    展开全文
    sinat_30035833 2019-02-27 08:56:25
  • 原标题:让人头疼的WAS内存溢出,银行运维人员该如何优雅的解决 1 引言WAS(IBM WebSphere Application Server)是IBM发布的一款成熟的企业级Web中间件产品,凭借其可靠性与稳定性,一直是国内大型商业银行Web服务的...

    原标题:让人头疼的WAS内存溢出,银行运维人员该如何优雅的解决

    1 引言

    WAS(IBM WebSphere Application Server)是IBM发布的一款成熟的企业级Web中间件产品,凭借其可靠性与稳定性,一直是国内大型商业银行Web服务的主流选择。可再稳定也会出问题,在日常的生产运维中,WAS应用问题的排查确实让笔者这种银行运维人员头疼。一方面厂商提供技术支持的时效性与准确性有待改善,另一方面像IBM其他产品一样,网上开放的可参考和借鉴的资料太少,发生WAS问题时着实让人无从下手。不过不要紧,鲁迅先生曾经说过,“走的人多了,自然就有路了”,笔者作为具有多年WAS运维经验的老鸟,下面就把自己在应对WAS内存溢出方面的知识总结一下,为大家介绍一下如何优雅的应对WAS内存溢出。

    2 IBM JAVA内存管理

    要应对WAS内存溢出,必须对IBM对JAVA内存的管理有所了解,下面,笔者就简单介绍一下IBM是如何管理JAVA内存的。不同于大家经常使用的Oracle Java,WAS使用的JAVA是内置于WAS内部的IBM JAVA,与Oracle Java在JVM、配置参数等方面有着显著不同。

    IBM JAVA 同样包含JDK、JRE、JVM三层,其关系如图所示:

    图1 JDK、JRE、JVM关系

    JVM内存管理区域包括程序计数器、Java虚拟机栈、堆空间、方法区、运行时常量池、本地方法栈(The Java® Virtual Machine Specification Java SE 8 Edition定义的内存区域)。以上几个内存区域中,除程序计数器区域外,都可能会产生OutOfMemoryError错误(本文中内存溢出特指Java的“OutOfMemoryError”)。

    图2 JVM 运行时内存区域

    程序计数器区域

    Java虚拟机支持多线程运行,所以对于每个线程,都需要一个指示其运行程序位置的指针,这个指针指向当前程序运行方法的地址。

    Java虚拟机栈

    每一个Java线程都拥有一个私有的Java虚拟机栈。像其他传统语言一样,Java虚拟机栈保存了程序调用时的局部变量和部分结果(称之为Frame)。

    方法区、运行时常量池

    方法区存放运行时常量池、字段以及方法(包括构造方法、特殊方法)代码。在IBM Java 8版本中,所有加载的类都存放在称之为Metaspace的空间中,Metaspace使用操作系统本地内存空间。

    本地方法区域

    为了支持操作系统本地方法(如C语言)调用,虚拟机中在本地方法区域中存储本地方法调用的栈信息。

    堆空间

    堆是JVM运行时内存中最大的区域,也是和程序开发密切相关区域,所有的对象实例(包括基本类型)、数组都存放在这个区域。和传统的C、C++语言不同,Java语言不需要开发人员显式地进行内存的申请和释放,而是由JVM的Allocator(内存分配器)和Garbage Collection(内存垃圾回收器,简称GC)负责管理内存。我们最常见的内存溢出“java.lang.OutOfMemoryError : Java heap space”也主要和该区域有关。下面我们将着重阐述IBM J9 VM堆空间相关模型和垃圾回收策略。

    堆空间内存结构和垃圾回收策略(GC)

    J9 VM支持多种不同的GC策略,不同的GC策略对应不同的Heap内存模型及分配回收算法,不同的GC策略适应于不同的业务场景,对于大多数系统(特别是交易类系统)来说,可使用“Generational Concurrent Garbage Collector”策略(简称gencon,参数:-Xgcpolicy:gencon可以指定使用该策略),这也是J9 VM的默认GC策略,本文主要详细介绍该策略。

    “Generational Concurrent Garbage Collector”策略特别适合存在非常多短生命周期对象的应用,即对象申请完之后,很快就不被使用,可以被GC回收。而一般的交易类系统,都符合这种场景。

    在该策略下,Heap内存被划分成新区域(Nursery)、老区域(Tenured)。所有对象创建后都被分配到Nursery区域,之后如果该对象一直标记为可用,则会被自动到Tenured区域。

    图3 J9 VM 默认堆空间内存模型

    更进一步,可以将Nursery区域划分为Allocate空间、Survivor空间。新创建的对象一开始被分配到Allocate空间,当Allocate空间满之后,触发一次Local GC,由Scavenge 进程将Allocate空间中“活着的”对象拷贝到Survivor区,超过一定周期(Tenured age)的对象则直接被移动到Tenured区域。之后,Allocate空间、Survivor空间的角色互换,等待下次Local GC。

    图4 Local GC过程

    上文提到,在一般场景下,大部分对象创建后,很快就不被使用、存活的对象较少,所以Local GC移动的数据也很少,而且Local GC后,可以得到很大的Allocate空间,这样就减小了GC时间。在JVM中,GC意味着所有运行中线程都要停下来(Pause)等待GC结束,GC完成后,才可以继续运行,所以Local GC可以减少因GC带来的系统吞吐量下降的影响。

    发生堆空间分配失败或者调用System.gc方法后,触发Global GC过程。Global GC通过标记、清除、压缩过程来尽可能释放JVM内存空间。Global GC需要获得整个JVM的排他控制权,所以当进行Global GC时,所有应用线程也将暂停。当Global GC结束后,应用线程将恢复执行。

    3 常见的WAS内存溢出原因

    上面我们介绍了IBM Java内存管理的模型和策略。理解上述模型后,我们可以清楚的知道为何会发生内存溢出:

    (1)JVM内部或者JVM间接使用的操作系统内存分配失败后触发内存溢出报错。JVM内存区域中,除了程序计数器区域外,Java虚拟机栈、堆空间、方法区、运行时常量池、本地方法栈都可能会发生内存溢出报错。

    (2)对于堆空间,当堆空间已经尽可能扩展,并且JVM花费了95%以上的时间在GC时,也会触发内存溢出报错。

    以上两点是内存溢出的基本要点,但实际生产系统由于运行环境往往较为复杂,在处理实际问题时,我们还应结合环境配置和业务场景来分析。通过总结实际运维过程中经验,可以将内存溢出原因分为如下几类:

    (1)堆内存大小上限配置过低

    由于Java程序所能使用的堆空间上限完全取决于JVM启动时的参数配置,当堆空间上限参数设置过低,即使操作系统物理内存空闲较多,应用程序也无法使用。所以在问题排查时,我们首先应该明确系统配置的堆空间上限(由Xmx参数指定),一般不能使用堆大小上限默认值。

    (2)程序内存泄漏导致内存持续增长

    如果程序存在内存泄漏,即使已经不再使用的内存仍将无法被GC回收释放,JVM内存将持续增长(而且,由于内存使用率逐渐升高,将会更加频繁的触发GC,反复GC又会引发CPU过高),最终导致堆内存空间满而引发内存溢出。

    (3)数据查询交易返回记录数过多或者程序申请使用大内存对象

    当程序过度地使用内存大对象或数组,导致无法申请足够的内存空间而引发内存溢出。例如,在实际生产中,可能存在应用程序读取整表数据或情况(数据条数在几万条以上),极易引发内存溢出。

    (4)物理内存过低或因其他进程消耗过多内存引发内存溢出

    即使我们设定了合理的JVM内存空间大小上限,但也有可能因为本地操作系统本身可用内存过低、无法实现内存空间的动态扩充,进而导致内存溢出;也可能因为在同一个操作系统上运行的其他JVM或者本地进程使用过多的内存导致内存溢出;由于JVM的部分区域(如Metaspace、DirectMemory等)直接使用的是操作系统内存,所以当操作系统内存过低,但创建本地线程过多、加载类过多时也有可能发生内存溢出异常;当程序过度使用DirectMemory也会引发内存溢出。

    (5)交易量突然增大

    如果我们将JVM堆内存上限设为M,每支交易处理需要使用的堆内存是N,那么当同时处理的交易量X突然增多N*X>M时,就容易触发内存溢出。

    4 如何优雅的应对WAS内存溢出

    当发生内存溢出后,首先要做的是恢复生产,恢复因内存溢出而宕机的Server。恢复生产后,可按照下面步骤进行内存溢出原因分析。

    收集环境信息

    内存溢出分析首先要做的就是收集环境信息和日志信息。

    收集日志文件

    表 1 收集日志文件表

    分析应用日志

    查看SystemOut.log日志java.lang.OutOfMemoryError的提示信息,确定内存溢出发生在JVM的哪个区域之后,查看SystemOut.log、SystemErr.log中应用交易日志,分析是否可疑的异常交易。

    分析堆内存使用趋势

    一般内存分析,第一步先查看JVM内存使用情况,即通过“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector”工具,打开native_stderr.log文件,查看JVM堆空间内存使用曲线:

    对于大对象或数组使用导致内存溢出的曲线一般如下图所示,存在曲线突然升高的情况:

    图5 大对象内存溢出堆空间趋势图

    内存泄漏导致内存溢出的曲线一般如下图所示,曲线缓慢上升(红色曲线):

    图6 内存泄漏程序堆空间趋势图

    找到堆空间可疑内存溢出点

    使用IBM HeapAnalyzer工具分析Heapdump文件。HeapAnalyzer工具列出了可疑的内存溢出点,分析人员需要逐个对这些可疑点进行排查,结合程序代码进行进一步确认。

    分析线程现场信息

    使用“IBM Thread and Monitor Dump Analyzer for Java”工具,分析javacore文件。检查内存溢出时正在执行的交易、正在执行的方法。

    非堆空间内存溢出

    如果出现“java.lang.OutOfMemoryError: 本机内存耗尽”内存溢出报错,则需要考虑DirectByteBuffer内存区域引发内存溢出。

    5 如何在具体场景应用

    上面白话了那么多,想必各位已经头晕眼花,那么接下来就来点干货。在具体的运维场景中,银行运维人员该如何快速分析和定位WAS内存溢出的问题呢,让笔者来结合自己遇到的某个实际场景进行阐述。

    某次笔者正在优雅的喝着咖啡,写着工作总结,忽然接到监控告警通知,“XX管理系统交易超时率提高,请尽快处置”。笔者一阵激灵,赶快扔下咖啡跑进操作间开始排查系统问题。

    第一步,当然是尽快恢复生产喽,笔者排查时,通过监控发现某台WAS服务器内存直冲天际,隐隐有突破内存限制的隐患,而就在同时,交易超时的情况开始同时升高。基本已经能定位问题是由于内存原因导致的,那么为了尽快恢复生产,笔者当然是首先选择对故障服务器的WAS应用进行了重启。

    图7:发生问题时某台WAS服务器的内存监控情况

    第二步,重启大法果然不出意外的解决了问题,重启WAS应用后系统交易超时指标恢复了正常。接下来,笔者就要认真排查问题,到底是什么导致了这次内存意外的冲高呢。笔者开始着手采集分析文件,主要包括SystemOut.log(输出日志)、SystemErr.log(错误日志)、native_stderr.log(GC日志),在采集时,笔者还在日志目录中发现了Javacore文件与Heapdump文件,这已经能确认是发生了内存溢出,下面的问题就是分析原因了。

    第三步,首先我们来查看日志文件,下面分别是SystemOut.log和SystemErr.log的部分内容。果然,在问题时点附近的错误日志中看到了OutOfMemoryError,同时在应用日志中看到了一些正在执行的sql,那么到底是哪个程序在作怪,又是为什么产生了内存溢出呢。

    图8:问题时点的应用日志

    图9:问题时点的错误日志

    第四步,看来仅从日志是无法定位具体问题的,笔者接下来要运用工具来解决问题了。笔者先后用IBM HeapAnalyzer和IBM Thread and Monitor Dump Analyzer for Java工具,分别对Heapdump文件及Javacore文件进行了具体的分析。对Heapdump文件的解析结果显示,某个List居然存在68万多个对象,占用了近50%的内存空间。对Javacore文件的分析结果显示,发生溢出时某支交易线程一直处于等待状态。

    图10:Heapdump文件的分析结果

    图11:Heapdump文件的分析结果

    第五步,有了这么丰富的信息,笔者已经做出了基本的判断,本次WAS内存溢出应该是由于某线程在一次查询时获取了太多数据,导致JVM为装载这些数据的List对象分配了过多内存,从而导致的内存溢出。笔者将信息反馈给开发人员后,果然没多久就得到确认,确实是某条查询语句未对查询结果进行分页处理,一次性命中过多查询结果后将其全部装入内存导致。

    至此,笔者的这次应急处置与事件分析工作告了一段落,笔者心满意足的回到工位,继续开始喝咖啡,写总结,优雅的等待下班的到来,相信开发人员修复这个隐藏缺陷后,笔者又可以清净一段时间了。

    6 如何预防或解决内存溢出问题

    经过上面一番讲解,相信对于WAS内存溢出的分析,无论是理论还是实践大家都有了一定的认识,那么,我们如何能预防或避免这种问题呢。笔者进行了一些简答的总结。

    对于物理内存不足或者堆空间上限配置不足的情况,需要评估合适的物理内存或者堆空间上限大小,进行扩充。需要注意的是32位WAS最大堆内存上限为1536MB,如果需要升级到更大内存,则需要迁移到64位WAS平台。另外,堆内存空间并不是越大越好,越大的内存意味着GC管理也越复杂,GC的耗时及应用程序停顿的时间也越长。

    对于存在内存泄漏或者是大对象申请情况引发的内存溢出,一般需要在定位问题原因后,在测试环境复现问题,进行程序优化解决问题。程序优化的方法不一而足,例如存在大数据量数据查询的情况可以加入筛选条件或者增加分页处理;也可以暂时规避解决的方式,通过关闭发生问题的交易或者修改交易流程不触发内存溢出的场景来临时性解决问题。

    7 最后

    以上就是笔者总结的如何优雅的应对WAS内存溢出的全部内容了,WAS作为一款企业级Web中间件,至少目前在国内银行、证券等大型国企中还占据着主导地位,了解WAS知识有助于我们在生产运维过程中高效解决问题,提高应急处置效率,后续笔者会继续总结在日常运维过程中碰到的问题,跟大家共同分享和交流。

    作者单位:中国农业银行研发中心 栾勇 耿鹏返回搜狐,查看更多

    责任编辑:

    展开全文
    weixin_39650994 2020-12-21 15:45:56
  • 可再稳定也会出问题,在日常的生产运维中,WAS应用问题的排查确实让笔者这种银行运维人员头疼。一方面厂商提供技术支持的时效性与准确性有待改善,另一方面像IBM其他产品一样,网上开放的可参考和借鉴的资料太少,.....

    1 引言

    WAS(IBM WebSphere Application Server)是IBM发布的一款成熟的企业级Web中间件产品,凭借其可靠性与稳定性,一直是国内大型商业银行Web服务的主流选择。可再稳定也会出问题,在日常的生产运维中,WAS应用问题的排查确实让笔者这种银行运维人员头疼。一方面厂商提供技术支持的时效性与准确性有待改善,另一方面像IBM其他产品一样,网上开放的可参考和借鉴的资料太少,发生WAS问题时着实让人无从下手。不过不要紧,鲁迅先生曾经说过,“走的人多了,自然就有路了”,笔者作为具有多年WAS运维经验的老鸟,下面就把自己在应对WAS内存溢出方面的知识总结一下,为大家介绍一下如何优雅的应对WAS内存溢出。

    2 IBM JAVA内存管理

    要应对WAS内存溢出,必须对IBM对JAVA内存的管理有所了解,下面,笔者就简单介绍一下IBM是如何管理JAVA内存的。不同于大家经常使用的Oracle Java,WAS使用的JAVA是内置于WAS内部的IBM JAVA,与Oracle Java在JVM、配置参数等方面有着显著不同。

    IBM JAVA 同样包含JDK、JRE、JVM三层,其关系如图所示:

    图1 JDK、JRE、JVM关系

    JVM内存管理区域包括程序计数器、Java虚拟机栈、堆空间、方法区、运行时常量池、本地方法栈(The Java® Virtual Machine Specification Java SE 8 Edition定义的内存区域)。以上几个内存区域中,除程序计数器区域外,都可能会产生OutOfMemoryError错误(本文中内存溢出特指Java的“OutOfMemoryError”)。

    图2 JVM 运行时内存区域

    程序计数器区域

    Java虚拟机支持多线程运行,所以对于每个线程,都需要一个指示其运行程序位置的指针,这个指针指向当前程序运行方法的地址。

    Java虚拟机栈

    每一个Java线程都拥有一个私有的Java虚拟机栈。像其他传统语言一样,Java虚拟机栈保存了程序调用时的局部变量和部分结果(称之为Frame)。

    方法区、运行时常量池

    方法区存放运行时常量池、字段以及方法(包括构造方法、特殊方法)代码。在IBM Java 8版本中,所有加载的类都存放在称之为Metaspace的空间中,Metaspace使用操作系统本地内存空间。

    本地方法区域

    为了支持操作系统本地方法(如C语言)调用,虚拟机中在本地方法区域中存储本地方法调用的栈信息。

    堆空间

    堆是JVM运行时内存中最大的区域,也是和程序开发密切相关区域,所有的对象实例(包括基本类型)、数组都存放在这个区域。和传统的C、C++语言不同,Java语言不需要开发人员显式地进行内存的申请和释放,而是由JVM的Allocator(内存分配器)和Garbage Collection(内存垃圾回收器,简称GC)负责管理内存。我们最常见的内存溢出“java.lang.OutOfMemoryError : Java heap space”也主要和该区域有关。下面我们将着重阐述IBM J9 VM堆空间相关模型和垃圾回收策略。

    堆空间内存结构和垃圾回收策略(GC)

    J9 VM支持多种不同的GC策略,不同的GC策略对应不同的Heap内存模型及分配回收算法,不同的GC策略适应于不同的业务场景,对于大多数系统(特别是交易类系统)来说,可使用“Generational Concurrent Garbage Collector”策略(简称gencon,参数:-Xgcpolicy:gencon可以指定使用该策略),这也是J9 VM的默认GC策略,本文主要详细介绍该策略。

    “Generational Concurrent Garbage Collector”策略特别适合存在非常多短生命周期对象的应用,即对象申请完之后,很快就不被使用,可以被GC回收。而一般的交易类系统,都符合这种场景。

    在该策略下,Heap内存被划分成新区域(Nursery)、老区域(Tenured)。所有对象创建后都被分配到Nursery区域,之后如果该对象一直标记为可用,则会被自动到Tenured区域。

    图3 J9 VM 默认堆空间内存模型

    更进一步,可以将Nursery区域划分为Allocate空间、Survivor空间。新创建的对象一开始被分配到Allocate空间,当Allocate空间满之后,触发一次Local GC,由Scavenge 进程将Allocate空间中“活着的”对象拷贝到Survivor区,超过一定周期(Tenured age)的对象则直接被移动到Tenured区域。之后,Allocate空间、Survivor空间的角色互换,等待下次Local GC。

    图4 Local GC过程

    上文提到,在一般场景下,大部分对象创建后,很快就不被使用、存活的对象较少,所以Local GC移动的数据也很少,而且Local GC后,可以得到很大的Allocate空间,这样就减小了GC时间。在JVM中,GC意味着所有运行中线程都要停下来(Pause)等待GC结束,GC完成后,才可以继续运行,所以Local GC可以减少因GC带来的系统吞吐量下降的影响。

    发生堆空间分配失败或者调用System.gc()方法后,触发Global GC过程。Global GC通过标记、清除、压缩过程来尽可能释放JVM内存空间。Global GC需要获得整个JVM的排他控制权,所以当进行Global GC时,所有应用线程也将暂停。当Global GC结束后,应用线程将恢复执行。

    3 常见的WAS内存溢出原因

    上面我们介绍了IBM Java内存管理的模型和策略。理解上述模型后,我们可以清楚的知道为何会发生内存溢出:

    (1)JVM内部或者JVM间接使用的操作系统内存分配失败后触发内存溢出报错。JVM内存区域中,除了程序计数器区域外,Java虚拟机栈、堆空间、方法区、运行时常量池、本地方法栈都可能会发生内存溢出报错。

    (2)对于堆空间,当堆空间已经尽可能扩展,并且JVM花费了95%以上的时间在GC时,也会触发内存溢出报错。

    以上两点是内存溢出的基本要点,但实际生产系统由于运行环境往往较为复杂,在处理实际问题时,我们还应结合环境配置和业务场景来分析。通过总结实际运维过程中经验,可以将内存溢出原因分为如下几类:

    (1)堆内存大小上限配置过低

    由于Java程序所能使用的堆空间上限完全取决于JVM启动时的参数配置,当堆空间上限参数设置过低,即使操作系统物理内存空闲较多,应用程序也无法使用。所以在问题排查时,我们首先应该明确系统配置的堆空间上限(由Xmx参数指定),一般不能使用堆大小上限默认值。

    (2)程序内存泄漏导致内存持续增长

    如果程序存在内存泄漏,即使已经不再使用的内存仍将无法被GC回收释放,JVM内存将持续增长(而且,由于内存使用率逐渐升高,将会更加频繁的触发GC,反复GC又会引发CPU过高),最终导致堆内存空间满而引发内存溢出。

    (3)数据查询交易返回记录数过多或者程序申请使用大内存对象

    当程序过度地使用内存大对象或数组,导致无法申请足够的内存空间而引发内存溢出。例如,在实际生产中,可能存在应用程序读取整表数据或情况(数据条数在几万条以上),极易引发内存溢出。

    (4)物理内存过低或因其他进程消耗过多内存引发内存溢出

    即使我们设定了合理的JVM内存空间大小上限,但也有可能因为本地操作系统本身可用内存过低、无法实现内存空间的动态扩充,进而导致内存溢出;也可能因为在同一个操作系统上运行的其他JVM或者本地进程使用过多的内存导致内存溢出;由于JVM的部分区域(如Metaspace、DirectMemory等)直接使用的是操作系统内存,所以当操作系统内存过低,但创建本地线程过多、加载类过多时也有可能发生内存溢出异常;当程序过度使用DirectMemory也会引发内存溢出。

    (5)交易量突然增大

    如果我们将JVM堆内存上限设为M,每支交易处理需要使用的堆内存是N,那么当同时处理的交易量X突然增多N*X>M时,就容易触发内存溢出。

    4 如何优雅的应对WAS内存溢出

    当发生内存溢出后,首先要做的是恢复生产,恢复因内存溢出而宕机的Server。恢复生产后,可按照下面步骤进行内存溢出原因分析。

    收集环境信息

    内存溢出分析首先要做的就是收集环境信息和日志信息。

    收集日志文件

    表 1 收集日志文件表

    分析应用日志

    查看SystemOut.log日志java.lang.OutOfMemoryError的提示信息,确定内存溢出发生在JVM的哪个区域之后,查看SystemOut.log、SystemErr.log中应用交易日志,分析是否可疑的异常交易。

    分析堆内存使用趋势

    一般内存分析,第一步先查看JVM内存使用情况,即通过“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector”工具,打开native_stderr.log文件,查看JVM堆空间内存使用曲线:

    对于大对象或数组使用导致内存溢出的曲线一般如下图所示,存在曲线突然升高的情况:

    图5 大对象内存溢出堆空间趋势图

    内存泄漏导致内存溢出的曲线一般如下图所示,曲线缓慢上升(红色曲线):

    图6 内存泄漏程序堆空间趋势图

    找到堆空间可疑内存溢出点

    使用IBM HeapAnalyzer工具分析Heapdump文件。HeapAnalyzer工具列出了可疑的内存溢出点,分析人员需要逐个对这些可疑点进行排查,结合程序代码进行进一步确认。

    分析线程现场信息

    使用“IBM Thread and Monitor Dump Analyzer for Java”工具,分析javacore文件。检查内存溢出时正在执行的交易、正在执行的方法。

    非堆空间内存溢出

    如果出现“java.lang.OutOfMemoryError: 本机内存耗尽”内存溢出报错,则需要考虑DirectByteBuffer内存区域引发内存溢出。

    5 如何在具体场景应用

    上面白话了那么多,想必各位已经头晕眼花,那么接下来就来点干货。在具体的运维场景中,银行运维人员该如何快速分析和定位WAS内存溢出的问题呢,让笔者来结合自己遇到的某个实际场景进行阐述。某次笔者正在优雅的喝着咖啡,写着工作总结,忽然接到监控告警通知,“XX管理系统交易超时率提高,请尽快处置”。笔者一阵激灵,赶快扔下咖啡跑进操作间开始排查系统问题。第一步,当然是尽快恢复生产喽,笔者排查时,通过监控发现某台WAS服务器内存直冲天际,隐隐有突破内存限制的隐患,而就在同时,交易超时的情况开始同时升高。基本已经能定位问题是由于内存原因导致的,那么为了尽快恢复生产,笔者当然是首先选择对故障服务器的WAS应用进行了重启。

    图7:发生问题时某台WAS服务器的内存监控情况

    第二步,重启大法果然不出意外的解决了问题,重启WAS应用后系统交易超时指标恢复了正常。接下来,笔者就要认真排查问题,到底是什么导致了这次内存意外的冲高呢。笔者开始着手采集分析文件,主要包括SystemOut.log(输出日志)、SystemErr.log(错误日志)、native_stderr.log(GC日志),在采集时,笔者还在日志目录中发现了Javacore文件与Heapdump文件,这已经能确认是发生了内存溢出,下面的问题就是分析原因了。

    第三步,首先我们来查看日志文件,下面分别是SystemOut.log和SystemErr.log的部分内容。果然,在问题时点附近的错误日志中看到了OutOfMemoryError,同时在应用日志中看到了一些正在执行的sql,那么到底是哪个程序在作怪,又是为什么产生了内存溢出呢。

    图8:问题时点的应用日志

    图9:问题时点的错误日志

    第四步,看来仅从日志是无法定位具体问题的,笔者接下来要运用工具来解决问题了。笔者先后用IBM HeapAnalyzer和IBM Thread and Monitor Dump Analyzer for Java工具,分别对Heapdump文件及Javacore文件进行了具体的分析。对Heapdump文件的解析结果显示,某个List居然存在68万多个对象,占用了近50%的内存空间。对Javacore文件的分析结果显示,发生溢出时某支交易线程一直处于等待状态。

    图10:Heapdump文件的分析结果

    图11:Heapdump文件的分析结果

    第五步,有了这么丰富的信息,笔者已经做出了基本的判断,本次WAS内存溢出应该是由于某线程在一次查询时获取了太多数据,导致JVM为装载这些数据的List对象分配了过多内存,从而导致的内存溢出。笔者将信息反馈给开发人员后,果然没多久就得到确认,确实是某条查询语句未对查询结果进行分页处理,一次性命中过多查询结果后将其全部装入内存导致。至此,笔者的这次应急处置与事件分析工作告了一段落,笔者心满意足的回到工位,继续开始喝咖啡,写总结,优雅的等待下班的到来,相信开发人员修复这个隐藏缺陷后,笔者又可以清净一段时间了。

    6 如何预防或解决内存溢出问题

    经过上面一番讲解,相信对于WAS内存溢出的分析,无论是理论还是实践大家都有了一定的认识,那么,我们如何能预防或避免这种问题呢。笔者进行了一些简答的总结。对于物理内存不足或者堆空间上限配置不足的情况,需要评估合适的物理内存或者堆空间上限大小,进行扩充。需要注意的是32位WAS最大堆内存上限为1536MB,如果需要升级到更大内存,则需要迁移到64位WAS平台。另外,堆内存空间并不是越大越好,越大的内存意味着GC管理也越复杂,GC的耗时及应用程序停顿的时间也越长。对于存在内存泄漏或者是大对象申请情况引发的内存溢出,一般需要在定位问题原因后,在测试环境复现问题,进行程序优化解决问题。程序优化的方法不一而足,例如存在大数据量数据查询的情况可以加入筛选条件或者增加分页处理;也可以暂时规避解决的方式,通过关闭发生问题的交易或者修改交易流程不触发内存溢出的场景来临时性解决问题。

    7 最后

    以上就是笔者总结的如何优雅的应对WAS内存溢出的全部内容了,WAS作为一款企业级Web中间件,至少目前在国内银行、证券等大型国企中还占据着主导地位,了解WAS知识有助于我们在生产运维过程中高效解决问题,提高应急处置效率,后续笔者会继续总结在日常运维过程中碰到的问题,跟大家共同分享和交流。

    【编辑推荐】

    【责任编辑:张燕妮 TEL:(010)68476606】

    点赞 0

    展开全文
    weixin_39595931 2020-12-24 08:25:18
  • 包括WAS、WMQ在安装、巡检、监控、优化过程中的常见难点。安装1、was 负载均衡的机制的粘连性,was负载均衡异常?有一个case系统,部署在was集群环境,应用是集群环境,有的时候当一个节点异常的时,客户端访问该...

    包括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//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,参数怎么调,需要根据实际应用去测试

    一般初始化调参可以试着设置为以下:

    afc681d37a6670d8991221b80a16d73d.png

    3c29a847b8054eca13ace534fcd346c7.png

    f4a5c52cd38ca05d714272c9338b74e3.png

    3,需要结合监控数据和实际,去分析系统的瓶颈和优化的方法。

    展开全文
    weixin_36119965 2021-01-17 17:27:24
  • weixin_37549458 2020-12-15 11:39:44
  • weixin_42648844 2021-05-13 13:03:16
  • 3星
    351KB machen_smiling 2015-03-27 11:27:01
  • weixin_42320332 2020-12-24 06:32:28
  • jfchenhust 2020-04-10 17:31:09
  • penggerhe 2020-10-19 18:11:04
  • weixin_35927281 2021-05-13 12:23:18
  • prestigeding 2020-10-28 16:11:59
  • weixin_39653442 2020-12-19 14:11:19
  • weixin_32259601 2021-05-15 20:25:33
  • weixin_50345059 2021-01-19 12:41:33
  • weixin_42349469 2021-05-13 10:54:22
  • xk_xx 2020-05-26 08:47:43
  • valada 2018-07-01 03:45:55
  • weixin_42524976 2019-06-13 12:25:01
  • qq_43279384 2020-04-10 17:09:03
  • YSTWD_WY 2021-07-13 19:09:34
  • weixin_30617561 2018-12-14 14:31:00
  • weixin_54720351 2021-06-03 17:05:37
  • dazuibar 2020-06-19 11:03:24
  • weixin_44742962 2020-04-21 17:26:07
  • qq_19228635 2021-11-12 16:05:02
  • yiqian95 2021-07-02 10:59:20

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,863
精华内容 3,145
关键字:

was运维