金蝶中国大企业技术支持部林珊珊EASCloud应用服务器实例宕机分析方法课程收益•了解实例宕机原因分类•掌握实例宕机常见原因的解决方法•掌握OOM宕机日志收集与分析方法EASCloud应用服务器实例宕机分析方法实例宕机0102实例宕机原因分类实例宕机案例分析03OOM类宕机日志收集与分析PART1：实例宕机原因分类基本概念解析OOMGCJVM实模式健康检查机制虚模式OutOfMemory(内存溢出)JavaVirtualMachine(Java虚拟机)GarbageCollection(垃圾回收)序时薄取数方法，一次性读取所有数据缓存到内存中，占用较大内存序时薄取数方法，每次只取当前显示页，预取前一页和后一页，取数效率高，占用内存小EASCloud自带的一套检查机制，用于监控实例健康状态，当发现某个实例的健康度差时，则主动重启该实例。基本概念解析heapdump*.phdcore*.dmpJavacore*javaheapdump*.hprofhs_err*.logheap.bin记录ibmjdk某一时刻JVM堆中对象内存使用情况记录Java应用各线程在某一时刻的运行的位置，即JVM执行到哪一个类、哪一个方法、哪一个行上记录ibmjdk在某一时刻JVM堆中对象内存与线程的使用情况记录oraclejdk某一时刻JVM堆中对象内存与线程的使用情况Oraclejdk下使用jmap手动生成的宕机日志，记录内存与线程当jvm出现致命错误时产生，记录了导致jvm崩溃的重要信息。实例宕机原因分类0102030405参数设置不合理标准或二开功能导致业务配置不合理导致群集负载不合理硬件资源不合理0102030405Jdkbug健康检查机制自动重启操作系统重启影响杀毒软件误杀系统中毒OOM非OOM如何判断实例是否发生宕机•管理控制台突然显示实例当前状态是“已停止”Killserver：通过控制台操作停止实例Stop：执行实例bin目录下的stopserver命令停止Start：启动实例Autokillserver：群集控制器通知管理控制台重启实例•实例..\server\profiles\server#\logs下的server.trace文件如何判断实例是否发生OOM•GC日志GC日志打开开关GC日志生成路径修改文件：..\server\profiles\server(N)\bin\set-server-env.bat(sh)默认是开启状态SETJVM_VERBOSE_GC=true..\server\profiles\server(N)\logs\jvm_gc_*Gc日志是以实例启动时间进行命名，查看当前Gc情况需以日志修改日期为准。记录每次GC触发的原因和时间、GC类型、GC前后的不同内存区域的大小、每次GC耗时等内容，可反映内存的使用情况。如何判断实例是否发生OOMIbmjdk分析工具：ga下载地址：ftp://ftpdev.kingdee.com/工具/分析工具/gc日志分析工具/ga.rarOracle（hp）jdk分析工具：Hpjmeter下载地址：ftp://ftpdev.kingdee.com/工具/分析工具/gc日志分析工具/hpjmeter.rarOracle（hp）jdk分析工具：GC_Viewer下载地址：ftp://ftpdev.kingdee.com/工具/分析工具/gc日志分析工具/GC_Viewer.7z如何判断实例是否发生OOM——ga工具如何判断实例是否发生OOM——ga工具如何判断实例是否发生OOM——ga工具如何判断实例是否发生OOM——Hpjmeter如何判断实例是否发生OOM——Hpjmeter内存占用累计时间起始时间如何判断实例是否发生OOM——GC_Viewer如何判断实例是否发生OOM——GC_Viewer如何判断实例是否发生OOM——GCeasy访问网址https://gceasy.io/如何判断实例是否发生OOM——GCeasy如何判断实例是否发生OOM——GCeasyPART2：实例宕机案例分析OOM案例1----参数设置不合理Heap内存过小..\server\profiles\server#\bin下的set-server-env.sh（bat）推荐配置：64位jdk下，建议设置JVM_INITIAL_HEAP_SIZE和JVM_MAX_HEAP_SIZE都设置为2048m~6144m（需根据操作系统内存资源情况进行评估）OOM案例2----参数设置不合理返回结果集参数设置过大---../admin/config/admin.vmoptions参数说明：criticalCollection：ORMapping（对象关系映射）中getCollection的最大条数criticalIDList：实模式返回最大结果集条数exceptionCellNumber：所有的结果集rowset中的单元格条数修改方法：修改上述配置文件或者在“管理控制台>>工具>>控制台参数”对这三个参数进行设置，保存后重启管理控制台，再重启EAS实例即可生效。（设置参数后，关掉管理控制台界面->执行admin目录下的stopserver.cmd(sh)->启动管理控制台->通过管理控制台启动eas实例）配置建议：criticalCollection=10000~100000criticalIDList=10000~300000exceptionCellNumber=100000~1000000OOM案例3----群集负载不合理处理建议：方案一：新建实例3，权重配置为1，加入群集；规范客户端使用群集控制器端口和网络代理端口进行访问方案二：调整群集控制器端口为原主实例的rpc端口，网络代理端口为原主实例的http端口，变更原主实例的两个端口为其它端口，则可避免每个客户端重新配置端口的麻烦问题描述：主实例出现频繁宕机现象，查看gc日志是内存溢出，但打开宕机日志发现并未有特别明显的功能占用大内存，也未有大量线程耗用内存。OOM案例4----硬件资源不合理处理建议：增加机器内存，更换为64位操作系统，使用64位jdk，同步调大实例内存配置OOM案例5----预警后台事务•使用mat工具打开javaheapdump*.hprof文件，有某个后台事务占用约2.5G内存OOM案例5----预警后台事务•打开支配节点树，发现是与forwarn（预警）和personInfo（人员信息）相关OOM案例5----预警后台事务•打开线程概述，左键选择javaBasics中的ThreadDetails查看详细线程OOM案例5----预警后台事务•打开线程概述，左键选择javaBasics中的ThreadDetails，可定位到预警线程OOM案例5----预警后台事务•临时处理方案：到后台事务实例表中去查找，当前有哪些预警相关的后台事务正在跑，或者出现了执行失败的情况，将其状态改为failed，同时修改后台事务触发表，变更为不触发状态，并对导致问题的预警进行禁用。T_JOB_trigger（后台事务触发表）T_JOB_inst（后台事务实例表）•彻底解决方案：针对具体导致问题的预警后台事务的配置规则和业务方法进行分析优化，对于数据量较大的业务，需设置过滤条件或进行分批处理。OOM案例6----查询分析器查询大对象通过ha工具打开heapdump日志，发现JdbcRowSet对象下有4千多个com/kingdee/jdbc/rowset/impl/Row对象OOM案例6----查询分析器查询大对象而展开每个com/kingdee/jdbc/rowset/impl/Row对象，都包含大对象SerialBlobOOM案例6----查询分析器查询大对象通过jdbc和SerialBlob关键字在javacore搜索，可判断是在查询分析器执行查询语句com/kingdee/eas/fm/common/app/FMIsqlFacadeControllerBean._executeSql解决方案：避免在查询分析器中查询大量数据或查询的数据中含有大对象字段（比如附件表、工作流表等）；如确实需查询，建议直接从数据库中进行查询。OOM案例7----web框架bug宕机日志显示存在多个相同线程，每个占用约200MOOM案例7----web框架bug打开发现都是StaticWebPageCollection相关，分析是静态化缓存导致OOM案例7----web框架bug解决方法：820版本打web框架补丁PT128127限制静态化缓存数量上限。OOM案例8----二开实模式取数通过ha工具打开宕机日志，发现112万多条记录集对象占用7百多兆内存，占比总内存50%，且对象是ScrollableResultSet的子对象OOM案例8----二开实模式取数另一处内存占用较大的集合对象RptRowSet中的子对象个数与ScrollableResultSet对象的子对象个数差不多大，可推断这两处集合对象在内存中作类型转换OOM案例8----二开实模式取数使用“RptRowSet”做为关键字在javacore文件中搜索，找到文件中关于堆栈的调用部分。从而定位是二次开发相关功能(AnalysisFacade.getContrastWtMonitor)采用实模式取数方法，一次性取数返回结果集过大导致。OOM案例8----二开实模式取数解决方案：修改二次开发的方法（AnalysisFacade.getContrastWtMonitor），建议可采用虚模式取数方式，控制返回结果集的大小。添加过滤条件，限制一次性返回的数据量，避免返回结果集过大。EASCloud应用服务器实例宕机案例分析EASCloud应用服务器实例宕机修复补丁推荐列表https://vip.kingdee.com/article/142587311610767616非OOM案例1----OraclejdkbugOraclejdk宕机时自动产生的hs_err*.log日志中记录如下内容可判断是jdkbug导致：处理方法：升级Oraclejdk到较新版本或者更换Oraclejdk为Ibmjdk（需注意采用的jdk版本，必须符合产品发版说明要求）非OOM案例2----360软件导致实例java进程异常退出，查看360软件发现有相关防护记录。处理方法：排除中毒的情况下，建议尝试添加白名单或者更换为其它杀毒软件非OOM案例3----应用服务器中毒实例java进程频繁异常退出，查看实例bin目录发现有watch*等异常文件可判断应用服务器中了挖矿病毒处理方法：查杀病毒，必要时重装操作系统；主动防御（修改加强apusic密码，安装对应版本Struts安全补丁）非OOM案例3----应用服务器中毒修改加强apusic密码：820版本在管理控制台选择”工具---Apusic密码修改“可进行修改。特别注意：修改apusic密码后，需选择“工具---部署应用”，分别选择每个实例进行部署操作，在部署的第一个页签admin的密码需与Apusic密码保持一致。各版本Struts安全补丁：8.2版本PT1123858.1版本PT1124368.0版本PT1124357.5版本PT1123718.5及以上版本发版前已修复，无需打补丁非OOM案例4----windows操作系统重启•查看server.trace确认应用服务器的实例宕机是在2019-02-1409:18:13之前•在“系统”-“运行”中输入“eventvwr”打开“事件查看器”查看操作系统日志，发现操作系统在2019-02-1408:49:08发生过重启现象非OOM案例5----AIX操作系统重启•AIX服务器异常，操作系统发生重启。（errpt,errpt-a）•若是linux操作系统，可通过分析/var/log/messages日志进行问题定位•控制台eas\admin\logs\ha.log日志健康度差（Server‘shealthdegreeisbad）包含：线程死锁（Thread_dead_lock）数据库jdbc连接池满（Connection_pool_leakage）响应时间超时（网络问题/gc时间过长，累计5次超时）内存溢出•实例eas\server\profiles\server#\logs下的server.trace文件Autokillserver：群集控制器通知管理控制台重启实例非OOM案例6----健康检查机制自动重启健康检查机制优化补丁（bos运行引擎模块）：V850版本：PT137923V820版本：PT136358非OOM案例6----健康检查机制自动重启•实例自动重启，检查server.trace和ha.log，发现是因数据库jdbc连接满导致•收集jdbc连接日志信息，发现是注册用户相关代码存在连接泄露导致。解决方法：V820版本安装补丁PT112362、PT113987、PT114898可解决该问题。PART3：OOM类宕机日志收集与分析OOM宕机日志如何收集----自动Ibmjdk自动产生的宕机日志格式：heapdump*.phd或core*.dmp存放路径：eas\server\profiles\server#\bin产生前提条件：缺省时在OOM时会自动产生heapdump*.phd格式的宕机日志，此类日志包含的信息较少，需与同个时间点一起产生的4个javacore*.txt堆栈信息联合分析。非windows：在eas\server\profiles\server#\bin\set-server-env.sh中增加一行exportJAVA_DUMP_OPTS="ONOUTOFMEMORY(SYSDUMP,JAVADUMP)"windows：在eas\server\profiles\server#\bin\set-server-env.bat中增加一行setJAVA_DUMP_OPTS=ONOUTOFMEMORY(SYSDUMP,JAVADUMP)方可在OOM时自动输出core*.dmpOOM宕机日志如何收集----自动Oraclejdk（HPjdk）自动产生的宕机日志格式：javaheapdump*.hprof存放路径：eas\server\profiles\server#\bin产生前提条件：1.5版本jdk需在eas\server\profiles\server#\bin\set-server-env.sh(bat)文件中，对参数值添加“-XX:+HeapDumpOnOutOfMemoryError”参数，才会在OOM时自动产生javaheapdump*.hprof格式的宕机日志。1.6和1.7版本jdk，默认会在OOM时自动产生javaheapdump*.hprof格式的宕机日志。OOM宕机日志如何收集----手动Ibmjdk手动产生宕机日志格式：heapdump*.phd或core*.dmp存放路径：eas\server\profiles\server#\binheapdump日志：运行网址http://IP:httpPort/easportal/tools/dump.jsp?type=heapdump（其中IP为服务器ip地址，httpPort为实例的http端口，可从管理控制台应用服务器页签上获取，这两个值需修改为现场环境实际值。）core*.dmp日志：执行kill-6
其中为实例java进程号，可从应用服务器页签获取.或运行网址http://IP:httpPort/easportal/tools/dump.jsp?type=systemdumpOOM宕机日志如何收集----手动Oraclejdk手动产生宕机日志格式：heap*.bin存放路径：oraclejdk的bin目录下Windows系统：jmap–dump:format=b,file=Linux系统：jmap–heap:format=b需先进入oraclejdk的bin目录下再执行上述命令，其中为EAS实例进程号，可在管理控制台应用服务器页签获取，是即将产生的日志文件命名。1.7版本jdk需添加-F参数，举例如下：./jmap-F-dump:live,format=b,file=heap.hprof67697OOM宕机日志如何收集----手动Oraclejdk使用jvisualvm工具手动生成宕机日志eas\oracle-jdk*\bin\jvisualvm.exeOOM宕机日志分析----MAT工具MAT工具介绍：MAT(MemoryAnalyzerTool)工具是eclipse的一个插件，也可以单独使用；该工具可直观看到各个对象在堆空间中所占用的内存大小、类实例数量、对象引用关系，能够快速生成内存泄露报表，方便定位和分析问题。分析的对象为heapdump*，javaheap*，core*等类型的宕机日志文件。工具下载地址：http://pan.baidu.com/s/1kUPmo2V密码：edruOOM宕机日志分析----MAT工具工具要求安装64位1.7版本jdk，并修改MemoryAnalyzer.ini配置jdk路径若提示内存不足，可修改MemoryAnalyzer.ini增大工具所需内存。OOM宕机日志分析----MAT工具Windows双击MemoryAnalyzer.exe，linux通过命令shMemoryAnalyzer.sh可启动OOM宕机日志分析----MAT工具打开后初始界面中，饼形图展示该日志记录的内存整体情况，并弹出如下界面，选择LeakSuspectsReport，点Finish，可进入疑似泄漏对象的分析报告界面。OOM宕机日志分析----MAT工具在疑似泄漏对象分析报告中，可查看占用内存最大的对象的具体内容，包括对象名称，对象个数，占用内存大小，以及占用总内存比例。OOM宕机日志分析----MAT工具浅堆(Shallowheap)：对象自身的大小，不包含其引用的对象。保留堆(Retainedheap)：当对象被释放后，能释放的内存大小。柱状图(Histogramview)：以一张表格展示所有类、数量、浅堆、保留堆大小。OOM宕机日志分析----MAT工具支配节点（Dominator）：如果任何到对象B的引用链都必须经过A，那么A就是B的支配节点。示例：对象引用图转换成支配节点树。(其中C是D/E/H的支配节点)支配节点树（SystemDominatortree）：支配节点及其保留堆对象生成的树。OOM宕机日志分析----MAT工具对象查询语言（OQL）:用类似SQL的语法在dump中进行对象查询操作。OOM宕机日志分析----MAT工具线程概述(thread_overview):可查看所有线程堆栈信息的详细内容。OOM宕机日志分析----MAT工具详细线程信息:可查看当前线程堆栈信息完整内容，可拷贝。OOM宕机日志分析----MAT工具可查看当前线程堆栈操作用户的信息，包括用户名，客户端ip等可查看堆栈对应的具体的业务功能相关信息。OOM宕机日志分析----MAT工具课程回顾0102030405参数设置不合理标准或二开功能导致业务配置不合理导致群集负载不合理硬件资源不合理0102030405Jdkbug健康检查机制自动重启操作系统重启影响杀毒软件误杀系统中毒OOM非OOMGa工具HpjmeterGC_ViewerGCeasyMAT工具Thanksterimakasih感謝谢谢ありがとうขอบคุณ
