WAS常见问题处理与系统维护建议.PPT

上传人:国*** 文档编号:503646 上传时间:2018-10-16 格式:PPT 页数:55 大小:1.34MB
下载 相关 举报
WAS常见问题处理与系统维护建议.PPT_第1页
第1页 / 共55页
WAS常见问题处理与系统维护建议.PPT_第2页
第2页 / 共55页
WAS常见问题处理与系统维护建议.PPT_第3页
第3页 / 共55页
WAS常见问题处理与系统维护建议.PPT_第4页
第4页 / 共55页
WAS常见问题处理与系统维护建议.PPT_第5页
第5页 / 共55页
点击查看更多>>
资源描述

1、WAS常见问题处理与系统维护建议,IBM WebSphere技术支持工程师,Page 2, | ,议程,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 3, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 4, | ,WAS是什么?,三层电子商务环境中的Web中间件(中间层)IBM实现的J2E

2、E 平台Java 运行时环境(JRE),Page 5, | ,WAS是什么? Web中间件,第一层:HTTP服务器,处理并转发客户端发来的请求第二层:WAS,处理执行请求,连接前端HTTP服务器和后台系统第三层:商业数据库和其他业务逻辑,Page 6, | ,WAS是什么? J2EE 平台,Page 7, | ,WAS是什么? Java 运行时环境,Page 8, | ,WAS拓扑中的基本概念,单元(Cell):由一组节点组成的一个管理域节点(Node):在一台物理机上若干应用服务器配置和运行时管理的集合应用程序服务器(Application Server):所有配置中最主要的运行时组件,是应

3、用程序真正运行的环境部署管理器(Deployment Manager或dmgr):Network Deployment (ND) 环境中管理整个单元的进程节点代理(Nodeagent):Network Deployment (ND) 环境中管理某个节点的进程集群(Cluster):一起管理的一组应用程序服务器,用来进行负载均衡,Page 9, | ,WAS的基本组件,Page 10, | ,如何管理WAS,基于web的管理工具 - 管理控制台基于脚本编制的管理工具 - wsadmin,Page 11, | ,如何管理WAS 管理控制台,单机环境:运行在本server上,只能管理自己ND环境:运

4、行在dmgr上,可管理单元中所有的server,通过“同步”操作将配置更改同步到各个节点http:/:9060/ibm/console (or /admin)https:/:9043/ibm/console (or /admin),Page 12, | ,如何管理WAS wsadmin,通过脚本方式管理WAS的运行时环境和配置支持两种脚本编制语言:Jacl 和Jython三种使用方式:执行单个命令:C:profilesbinwsadmin -c AdminControl.getNode()进入交互式环境:C:profilesbinwsadminwsadmin执行脚本文件:C:profilesb

5、inwsadmin -f myScript.py,Page 13, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 14, | ,WAS问题的分类和特点,配置相关问题安装/升级失败HTTP请求转发失败类加载异常应用程序发布及访问异常性能相关问题内存溢出响应慢/线程挂起高CPU宕机,进程退出处理性能问题和性能调优对于系统运维部门来说是一项长期、重要的工作,配置问题多出现在新环境刚上线后的一段时间问题相对比较明确解决一次即可性能问题通常会伴随系

6、统较长时间有些问题需要积累很长时间才会体现出来,如内存溢出有些问题可能只在某些特殊条件下才会出现,如宕机有些问题是随着新的业务高峰的到来而出现的有些问题是应用程序变更后引起的性能瓶颈,Page 15, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 16, | ,WAS使用的内存,Java 堆内存(Java heap)存放Java对象的内存空间通过-Xms(初始堆大小)和-Xmx(最大堆大小)设置,并在运行过程中由JVM动态调整本地内存(n

7、ative memory)Java对象之外使用的一些内存不能手动设置,等于进程可用总内存(User Space)减去Java最大堆内存32-bit WASAIX: 2.75G-Xmx (Xmx64KB 即为大对象可添加JVM参数找出大对象:-Xdump:stack:events=allocation,filter=#5m堆内存碎片化(主要是V6.0及以前的版本)pinned objects 不可移动的对象,Page 18, | ,Java堆内存溢出 内存泄漏,监控和调整 - 性能查看器 - 当前活动 - (服务器名字)- 性能模块 堆内存使用量持续增长,当增长到最大堆后,将无法分配新内存,出现

8、内存溢出,Page 19, | ,Java堆内存溢出 内存泄漏,正常情况下堆内存的大小应该是均值稳定的锯齿状图形,Page 20, | ,Java堆内存溢出 需要收集的数据,堆内存转储 heapdump文件分析堆内存的具体使用情况默认生成在下详细垃圾回收日志 native_stderr.log分析出现内存溢出的过程确认触发内存溢出的直接原因评估垃圾回收性能,找出合适的GC策略和调优参数需要手动启用Java线程转储 javacore文件Java线程信息,环境变量及Java变量设置,类加载信息java.lang.OutOfMemoryError/logs目录下的其他日志和server.xml文件M

9、ustGather: Out of Memory errors with WebSphere Application Server on AIX, Linux, or Windowshttp:/ 21, | ,本地内存溢出,常见原因最大堆设置过大java.lang.ThreadLocal泄漏本地内存AIO:DirectByteBuffer 泄漏本地内存JIT(Just-In-Time)编译器内存泄漏Classloader及其他JNI调用内存泄漏通常不会生成heapdump,生成系统core,导致crash64-bit环境可能表现为WAS进程的总内存不断增大MustGather: Native

10、Memory Issues on Linuxhttp:/ Native Memory Issues on AIXhttp:/ 22, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 23, | ,WAS响应慢 性能瓶颈在哪里?,HTTP服务器和插件Java堆内存配置不合理WebContainer线程池数据源连接池网络质量数据库性能,Page 24, | ,线程挂起 现象和成因,线程挂起是JVM不再响应客户端请求的一种状态,现象可能表现为:应

11、用程序首页无法打开WAS访问端口(9080)连接数高SystemOut.log日志中出现WSVR0605W,可能导致线程挂起的原因:线程死锁:A线程等待B线程正在使用的某个资源,同时,B线程也在等待A线程正在使用的某个资源应用程序代码问题:部分代码效率不高,在业务压力大的时候成为性能瓶颈线程池和/或数据源配置不合理数据库和/或其他后台系统存在性能问题垃圾回收效率低下,GC开销过大系统物理资源瓶颈:物理内存不足,出现换页;I/O高;,Page 25, | ,线程挂起 需要收集的数据,用kill -3生成三个javacore,每两个间隔两分钟(问题发生时收集)线程信息监控锁信息详细垃圾回收日志na

12、tive_stderr.log垃圾回收效率有没有OutOfMemoryError及其他JVM异常/logs目录下所有日志运行时日志SystemOut.log,SystemErr.logffdc日志netstat an端口使用情况MustGather: Performance, hang, or high CPU issues on Linux (linperf.sh)http:/ Performance, hang, or high CPU issues on AIX (aixperf.sh)http:/ 26, | ,WebSphere Application Server (WAS) 介绍

13、 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 27, | ,WAS高CPU常见原因,高CPU,性能下降,线程挂起几个问题常常相互伴随出现分析方式和收集数据有类似的地方,又各有侧重点造成WAS高CPU的主要原因包括:垃圾回收消耗大量CPU资源应用程序出现死循环/复杂递归调用/消耗资源的操作不恰当的配置系统CPU资源不足,Page 28, | ,WAS高CPU问题分析思路,垃圾回收消耗大量CPU资源通过tprof/top定位问题分析垃圾回收日志找出消耗资源的原因通过-Xgcpolicy设置合适的垃圾回收策略调整其他垃圾回

14、收相关的JVM参数应用程序出现死循环/复杂递归调用/消耗资源的操作通过tprof/top定位问题线程对应到javacore里找到问题线程的Java堆栈信息将此堆栈信息提供给程序开发人员,继续排查程序问题不恰当的配置单个线程消耗的CPU都不高垃圾回收基本正常线程数量很多系统CPU资源不足物理CPU个数太小CPU处理出现排队等待(vmstat),Page 29, | ,WAS高CPU处理办法 AIX,数据收集方式:自动方式:aixperf.sh需要以root用户来执行确保脚本有执行权限输出:aixperf_RESULTS.tar.gz 手动方式: ps avwwwg ps.outkill -3 P

15、IDvmstat 5 12 vmstat.outtprof -skex sleep 60kill -3 PID(等待两分钟)kill -3 PID MustGather: Performance, hang, or high CPU issues on AIX (aixperf.sh)http:/ 30, | ,WAS高CPU处理办法 Linux,数据收集方式:自动方式:linperf.sh需要以root用户来执行确保脚本有执行权限输出:linperf_RESULTS.tar.gz 手动方式: top -bc -d 60 -n 5 top.out &top -bH -d 5 -n 48 -p

16、PID topdashH.out &ps -eLf ps.outkill -3 PIDvmstat 5 12 vmstat.out (等待一分钟)ps -eLf ps.outkill -3 PIDvmstat 5 12 vmstat.out(等待一分钟) ps -eLf ps.outkill -3 PIDvmstat 5 12 vmstat.out,收集的数据:linperf_RESULTS.tar.gz三个javacore/logs三个javacore/logstop.outvmstat.outtopdashH.outps.outMustGather: Performance, hang,

17、or high CPU issues on Linux (linperf.sh)http:/ 31, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 32, | ,什么是WAS crash(宕机),应用程序服务器因为软件方面的原因进程意外终止的一种故障。要区分crash和线程挂起crash进程不在线程挂起进程还在两个问题收集的数据有不小的差别,Page 33, | ,WAS crash的常见原因,Segmentation Violation

18、 应用程序访问了错误的内存地址Native Stack Overflow栈指针超出线程栈的限制本地内存溢出OutOfMemoryError,无法使用malloc方法分配到内存,Page 34, | ,WAS crash的常见原因,垃圾回收异常垃圾回收过程中出现异常垃圾回收后出现异常,说明可能存在内存故障JIT(Just-In-Time)异常编译过程中出现异常编译输出的本地代码异常,导致WAS执行时出错JNI(Java Native Interface)调用异常程序中调用到了本地库文件,或程序中的第三方代码使用了本地库文件如JDBC驱动,MQ库文件,CM库文件,Page 35, | ,Crash

19、问题需要收集的数据,最主要的数据:javacore通常会自动生成/logs下的全部日志运行时日志:SystemOut.log SystemErr.logJVM日志:native_stderr.log native_stdout.logffdc日志系统core文件目录下,系统/tmp目录下,目录下用jextract处理完整数据收集请参考Must Gather文档:AIX: http:/ 36, | ,特定操作系统需要收集的数据,AIXerrpt 记录系统事件和系统报错dbx输出 提供native堆栈信息Linuxgdb输出libsgrabber,Page 37, | ,Crash的预防措施,及时

20、升级JDK安装较新的操作系统补丁如果用到本地库文件(JDBC驱动,MQ库,CM库等),保证这些文件版本足够新,Page 38, | ,Crash问题的应对和处理,发生之前确认kill -3 能够生成javacore系统ulimit设置成unlimited确认WebSphere和/tmp所在的文件系统有足够大的剩余空间关于core不完整或没有生成core的处置文档AIX:http:/ http:/ 发生之后查看native_stderr.log,确认javacore和系统core生成的位置按照Must Gather文档的步骤收集完整的数据收集的数据一定要完整,便于分析文件在问题解决/原因找到之前

21、,暂时保留生成的系统core文件,Page 39, | ,故障处理 总结与建议,系统配置要合理,预防可以规避大量问题软件版本要更新,不要被已经解决的问题绊倒垃圾回收要打开,解决多种问题都用到收集脚本要拷贝,收集数据快且全诊断工具要安装,避免无米之炊干着急(gdb,dbx )发生故障要冷静,区分故障类型,定位问题收集数据要及时,在“正在发生”时收集,错过还需等重现收集数据要完整,节省诊断时间,减少重复收集,Page 40, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题

22、管理补丁管理Q&A,Page 41, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 42, | ,健康检查有什么用?,统一配置,规范管理排查不合理的配置与设置,规避“愚蠢”的问题监控系统运行状况,提早发现可能存在的性能瓶颈与故障隐患,Page 43, | ,健康检查查什么?,全部配置信息OS信息,network信息,WAS全部配置重点配置核实WAS重点配置(通过管理控制台和xml配置文件)运行时日志中的报错和异常SystemOut.log

23、,SystemErr.log, ffdc日志JVM运行健康状况native_stderr.log其他性能相关数据手动生成javacore,heapdump,Page 44, | ,健康检查分类,日常运行监控 周检及时了解系统运行状况主要节假日前检查降低节日期间出现故障的概率重要时段健康检查两会,大型国内、国际赛事,重要业务高峰新系统上线前检查规避不合理配置,标准化配置,可以避免大量问题的发生新系统上线后跟踪检查以排查运行时异常和性能问题为主重要系统定期深度健康检查,Page 45, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题

24、响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 46, | ,问题管理管什么? 示例,五分之一操作系统类问题,五分之四中间件问题。WAS问题占据了整个问题数的50% !,Page 47, | ,问题管理管什么? 示例,44%的问题跟内存溢出相关,Page 48, | ,问题管理管什么? 示例,内存耗尽导致的堆内存溢出 (A系统)应用程序优化代码,化整为零业务角度优化,减少幵发、集中大的内存申请增大JVM最大堆大小大对象引起的堆内存溢出 (B系统)通过增加WAS参数明确哪个应用程序使用了大对象禁止使用已知的引起大对象问题的第三方组件,如Jxl内存泄露

25、(C系统)修改应用程序,解决泄露问题加强监控,部署GC监控脚本,定期重启WASNative内存溢出 (D系统)应用程序优化配置WAS相关参数(固定的3个方法)减小堆内存,增加本地内存使用大对象模型迁移32 bit WAS到64bit WAS频繁的SysGC (E系统)过于频繁引起WAS hang尽量从应用角度禁用从系统角度增加屏蔽参数,Page 49, | ,问题管理管什么? 示例,为什么WAS的问题如此多,处理时间比较长?1.产品性质:WAS是基于java的具有很强灵活性、复杂性、开放性的商业中间件a)WAS性能不稳定性受其上运行的应用程序的影响很大,丌像操作系统等有些产品自身封装的很严(开

26、放性)b)WAS处于电子商务IT架构标准三层体系结构的中间层,其性能受到前端网络/负载均衡器、后端信息系统(如数据库),以及其运行的操作系统等众多因素的影响(复杂性)c)WAS是基于j2ee的运行时环境,j2ee相关标准复杂庞大,可编程性极强,WAS环境可以调整/设置成各种丌同的特点(灵活性)2.当前处于集中上线和运维的阶段,客户程序尚不稳定,WAS相关的问题会比较多WAS环境对于每一个丌同特点的应用程序都需要迚行定制的调优,没有所谓“通用”的配置,这个调整的过程会一直伴随着应用的变化,压力大变化而丌断迚行,直到每个环境都趋于稳定,出现问题的数量和频率才会有明显的下降3.处理WAS问题的特点决

27、定了处理周期会比较长a)数据收集比较复杂:WAS很多问题提前丌好预防,而丏问题出现后,现有的数据(日志和配置等)通常丌足以诊断问题,需要有针对性的配置跟踪和调试参数b)分析需要逐步深入:很多难题需要重现时收集数据,而丏有时需要收集多次数据,收集数据的内容需要根据分析迚展迚行调整,很难一蹴而就c)等待采纳建议时间长:很多时候给出建议,等待项目组修改程序(如内存溢出和挂起的问题)。如果修改的丌好,还会重现或出现类似问题,就要再次收集数据迚行分析,Page 50, | ,问题管理的意义,明确整个IT环境运行状况,故障分布了解主要产品出现机会较高的问题有针对性的进行集中分析和整治挖掘故障发生的背景和深

28、度根源为下一步工作指明方向,Page 51, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Page 52, | ,补丁管理,制定补丁维护策略新搭建环境安装产品最新补丁已投产环境最新版本策略:安装最新版本补丁最大稳定性策略:“T-1”策略,安装最新版本之前的一个版本每年升级一次策略:减少升级次数补充策略因升级软件或硬件而必须按照的补丁解决已发生问题的补丁分析最新版本的补丁和升级必要性制定实施策略建议:准生产环境安装,保证有核心业务运行情况下测试生产

29、环境安装,Page 53, | ,生产系统IT运维心得,不是没出故障的系统就是好系统技术不精同样可以把系统维护好对系统和业务熟悉的技术人员才是出色的管理员运维规范化、流程化、工作结果量化是运维部门价值的重要体现,Page 54, | ,WebSphere Application Server (WAS) 介绍 WAS常见性能问题处理内存问题响应慢/线程挂起高CPUcrash宕机系统维护建议健康检查问题管理补丁管理Q&A,Thank You,Merci,Grazie,Gracias,Obrigado,Danke,Japanese,English,French,Russian,German,Italian,Spanish,Brazilian Portuguese,Arabic,Traditional Chinese,Simplified Chinese,Thai,Korean,

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 重点行业资料库 > 1

Copyright © 2018-2021 Wenke99.com All rights reserved

工信部备案号浙ICP备20026746号-2  

公安局备案号:浙公网安备33038302330469号

本站为C2C交文档易平台,即用户上传的文档直接卖给下载用户,本站只是网络服务中间平台,所有原创文档下载所得归上传人所有,若您发现上传作品侵犯了您的权利,请立刻联系网站客服并提供证据,平台将在3个工作日内予以改正。