# OA宕机性能问题排查策略
# 适合人群
本内容适合：实施、运维
# 前言
OA服务不可用时，事态一般比较紧急，此时客户的第一个联系人对于客户来说犹如救命稻草。如何更好的服务客户，在第一时间里让心急如焚的客户压力得以缓解，并给出合理的下一步建议？
本文就OA服务不可用的现象发生时，关于系统环境方面一些基本的排查方法进行讨论。望能帮助大家，在成为客户的第一颗救命稻草时，更从容的应对。或许在逐步排查的过程中，已经理清事项的根本，帮客户当即解决问题。
关于宕机性能问题排查的基础思路大致分以下步骤：
现状确认---->现状保护---->信息收集---->服务恢复---->信息分析---->结果反馈
下面就对以上各步骤逐一展开详述需要做的事项。
# 现状确认
OA服务不可用这个描述与实际情况可能会有出入，现状确认时，不妨询问客户以下问题，并做记录：
是OA服务使用慢？还是OA服务无法访问了（登录页不出现，或系统中任意功能都无法操作）
是个别客户端出现了这样的情况？还是周边同事都出现了此现象？
# 现状保护
在进行了一系列询问后，若协同服务进程此刻是不存在的，可以跳到【服务恢复】步骤，先启动协同服务，再进行【信息收集】等动作。
若协同服务进程仍在，千万不要着急重启服务。对于现状进行保护，才能对当前现象进行有效、完整的信息收集。
# 信息收集
# 检查OA服务进程是否存在
检查方法：
Windows服务器通过桌面查看OA的进程窗口是否存在。
Linux服务器，使用命令检查OA服务的java进程是否存在。
命令：ps -ef |grep ava
PS：服务器上有多个java进程时，注意识别OA的java进程。
# 情况一：OA进程不存在
OA进程不存在可能原因是：内存溢出宕机、虚拟内存不足、第三方插件引起jdk兼容性问题、操作系统更新/异常重启、服务器中毒、认为操作停服等原因导致。按照以下步骤收集相关信息进行分析。
步骤1、检查有没有.hprof文件生成（内存溢出文件）
tomcat中间件检查A8\ApacheJetspeed\bin目录。
信创环境东方通、金蝶、宝兰德中间件，检查中间件的logs目录。
如果存在宕机当天的hprof文件，可判断为内存溢出宕机。
需要取出hprof文件，使用MemoryAnalyzer，俗称MAT工具进行分析。
工具分析方法参考文档：
内存溢出宕机类问题初探-java.lang.OutOfMemoryError: Java heap space (opens new window)
步骤2、检查有没有hs_err_xxx.log文件生成（java进程崩溃日志）
tomcat中间件检查A8\ApacheJetspeed\bin目录。
信创环境东方通、金蝶、宝兰德中间件，检查中间件的logs目录。
如果存在宕机当天的hs_err_xxx.log文件，可判断为java进程崩溃宕机。
hs_err_pid*.log记录java进程崩溃事件，查看log中Problematic frame以及Java frames关键字。
例如，关键字信息：
# The system is out of physical RAM or swap space 可能为操作系统内存/虚拟内存不足，导致进程崩溃。增加服务器内存/虚拟内存解决。
# sigar-amd64-winnt.dll可能为帆软报表或者V7.1SP1版本S1monitor代码触发，更新帆软单点补丁包或者移除帆软（未使用无授权），更新V7.1SP1版本月度修复包或者单点补丁包解决。
# J 52435 C2 oracle.jdbc.driver.OracleResultSet.getObject关键字记录为Oracle驱动导致，oci连接模式切换thin连接模式解决。
# jacob-1.15-x64.dll可能为考勤插件或者第三方客开导致，第三方解决。
详细分析方法参考文档： 系统崩溃日志hs_err_pid快速分析方法 (opens new window)
步骤3、检查操作系统日志
Windows日志查看命令eventvwr，Linux日志查看/var/log/messages
可能问题点：
- 服务器意外关闭、（自动更新后）重启、注销等。
解决办法：
右击"我的电脑"-属性-系统属性-高级-启动和故障恢复-设置-启动和故障恢复-系统失败-取消"自动重新启动"-确定. 检查电池计划，是否存在类似情况。 检查windows更新，改为手动检查更新。
- 虚拟内存不足java进程崩溃，或者被操作系统kill， Linux日志可能记录
kernel: Free swap = 0kB
kernel: Out of memory: Kill process 51617 (java) score 530 or sacrifice child
解决办法：Windows扩展物理内存，临时解决设置虚拟内存为磁盘空间较大分区系统管理的大小（一般占用物理内存1.5倍磁盘空间），linux扩展物理内存，临时解决设置swap分区至少16G。
步骤4、收集应用日志并检查 OA日志获取方法： 1、收集ApacheJetspeed\logs目录下宕机当天的日志，包括：catalina.out、catalina.2024-xx-xx.log、localhost.2024-xx-xx.log 2、收集ApacheJetspeed\logs_sy目录下宕机当天的日志，包括：capability.log、ctp.log、error.log等
步骤5、检查安全软件及日志记录
例如：360杀毒软件误杀，安全拦截日志记录，添加白名单解决
步骤6、检查是否存在病毒木马
1）检查操作系统存在病毒木马进程。Windows通过任务管理器看。Linux通过top命令查看
2）Windows定时任务记录异常操作exe痕迹，Linux发现负载高crontab定时任务记录异常操作。
3）搜索OA服务webapps目录下存在后门.jspx文件。
# 情况二：OA进程存在
OA进程存在但无法访问，可能原因： java年老代超过90%、数据库连接泄漏、客户端网络问题等。按照以下步骤收集相关信息进行分析。
步骤1、服务器本机访问127.0.0.1及端口是否可用
Windows直接用浏览器访问http://127.0.0.1+端口 (opens new window)
Linux使用命令： curl -I http://127.0.0.1:端口/seeyon/main.do (opens new window)
结果出现HTTP/1.1 200判断登录页可以正常打开，考虑防火墙/网络因素导致客户端无法访问。
步骤2、若进程存在，但本机亦不可访问
需要收集如下信息：
- 收集多个线程dump文件，jdk/bin目录，执行命令：
Windows:
jstack.exe [OA服务java进程pid] >> [线程dump文件名01].txt
jstack.exe [OA服务java进程pid] >> [线程dump文件名02].txt
Linux:
./jstack [OA服务java进程pid] >> [线程dump文件名01].txt
./jstack [OA服务java进程pid] >> [线程dump文件名02].txt
- 查看堆内存年老代（Old Gen）使用情况，jdk/bin目录，执行命令：
Windows:
jstat.exe -gcutil [OA服务java进程pid] 1000 10
Linux:
./jstat -gcutil [OA服务java进程pid] 1000 10
查看执行结果中O 这一列的值，代表java年老代使用占比情况。
- 收集堆内存dump文件，jdk/bin目录，执行命令：
Windows:
jmap.exe -dump:format=b,file=[内存dump文件名].bin PID[OA服务java进程pid]
Linux:
./jmap -dump:format=b,file=[内存dump文件名].bin PID[OA服务java进程pid]
导出内存dump文件后，使用MAT工具进行分析。
# 服务恢复
在收集了必要的信息后，所谓一启解千愁，在业务系统允许并充分沟通的情况下，可以对OA服务或操作系统及时进行重启。
# 信息分析
收集了必要的信息，对于信息的分析若有难度，可以及时上报支持流程，将信息交付于研发部门进行问题分析。
# 结果反馈
在对应的支持流程中，每一位研发同事都会将造成此事件的根本原因详述在处理意见中。
