某应用服务器中间件-Weblogic节点健康状态（Not Reachable）应用访问缓慢

1、2019/11/29 17时30分 接到某应用系统管理员及应用厂家通知告警-应用服务器csoms_env1_domain域中间件节点登录控制台访问缓慢且部分业务受到影响，业务呈现卡死现象，由于系统比较重要，访问用户量大概在50W+，与系统厂家协商后，优先处理故障，依照先抱着释放线程的侥幸心理，恢复业务优先，重启管理节点登录控制台依旧访问缓慢，但过一段时间可以登录到控制台查看节点健康情况。
2、咨询应用厂家，近期有没有做过发布？有没有做过其它变更？应用厂家描述都没有做过，应用也是接收到告警信息后，客户投诉后受理检查csoms_env1_domain。
3、登陆服务器控制台，观察控制台中间件各节点信息，中间件节点状态RUNNING，部分节点健康状况为（Not Reachable）通信不可达，个别节点健康状态还为OK。中间件节点受影响服务器为 (xx.xx.xx.xx)，应用描述本次业务已经受到影响，部分功能模块访问缓慢或不可用，且受到客户方投诉，接到业务部门及相关领导要求，需要尽快恢复应用。
4、由于业务部门要求及信息中心相关领导要求，需尽快恢复应用，确保业务正常运营，故作为中间件系统管理员，系统操作员，采取如下临时处理措施：

**措施一：**先配合应用厂家进行中间件健康状态呈现呈现（Not Reachable）通信不可达节点进行分批次重启，此时业务还未全部丢失情况下。
**措施二：**服务器后台日志检查，服务器GC及负载性能观察。
后台日志检查分别检查那些日志就不做相关叙述了，这里玩过中间件的都知道域里面相关日志作用的含义。查看GC及负载运行情况 涉及命令：jstat -gcutil pid 5000 10 观察FGC的运行情况 ，时间是否跨度比较大
列如：

**措施三：**保留个别（Not Reachable）通信不可达节点获取快照文件进行分析。
获取快照方法：
生成内存快照： jmap -dump:format=b,file=/weblogic/dump.dump pid

生成现场快照: jstack -l pid > /weblogic/dump.log
措施四：通过各节点日志检查分析，Dump文件分析初步确定引起本次故障根本原因。
线程快照可以用 IBM JCA_457 等工具进行分析
内存快照可以用MemoryAnalyzer 等工具进行分析
这些工具的点点都需要平时的很多积累才能看懂里面的具体干了些什么，都需要一个过程。
5、登陆服务器检查个别节点日志(异机节点)日志信息，各节点日志中均有发现存在内存溢出（OutOfMemoryError）现象。日志如下：
####<2019-11-29 下午05时39分02秒 CST> <> <> <> <1575020342829> java.lang.OutOfMemoryError: GC overhead limit exceeded

分析过程 ：先取下内存快照进行分析
1）涉及命令：jmap -dump:format=b,file=/weblogic/heap.dump 41007
2）工具： MemoryAnalyzer（使用分析方法可以自己去查）
通过分析（地址是@0x600064940 STUCK线程达到了4.7GB）
weblogic.work.ExecuteThread @ 0x600064940 [STUCK] ExecuteThread: ‘3’ for queue: ‘weblogic.kernel.Default (self-tuning)’
Shallow Size: 208 B Retained Size: 4.7 GB
3）@0x600064940 [STUCK]
The thread weblogic.work.ExecuteThread @ 0x600064940 [STUCK] ExecuteThread: ‘3’ for queue: ‘weblogic.kernel.Default (self-tuning)’ keeps local variables with total size 5,069,483,296 (69.81%) bytes.
The memory is accumulated in one instance of “java.util.LinkedHashMap” loaded by “”.
The stacktrace of this Thread is available. See stacktrace.
Keywords
java.util.LinkedHashMap

4）Dominator_tree
5）查看Dominator Tree LinkedHashMap可以看到累积了3616598个Entry，这是可能存在问题的根源问题
6）堆栈分析
Thread Stack
[STUCK] ExecuteThread: ‘18’ for queue: ‘weblogic.kernel.Default (self-tuning)’
at weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_ForwardOnlyResultSet.getBigDecimal(Ljava/lang/String;)Ljava/math/BigDecimal; (Unknown Source)
at org.hibernate.type.BigDecimalType.get(Ljava/sql/ResultSet;Ljava/lang/String;)Ljava/lang/Object; (BigDecimalType.java:46)
at org.hibernate.type.NullableType.nullSafeGet(Ljava/sql/ResultSet;Ljava/lang/String;)Ljava/lang/Object; (NullableType.java:184)
at org.hibernate.type.NullableType.nullSafeGet(Ljava/sql/ResultSet;[Ljava/lang/String;Lorg/hibernate/engine/SessionImplementor;Ljava/lang/Object;)Ljava/lang/Object; (NullableType.java:173)
at org.hibernate.type.AbstractType.hydrate(Ljava/sql/ResultSet;[Ljava/lang/String;Lorg/hibernate/engine/SessionImplementor;Ljava/lang/Object;)Ljava/lang/Object; (AbstractType.java:105)
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(Ljava/sql/ResultSet;Ljava/io/Serializable;Ljava/lang/Object;Lorg/hibernate/persister/entity/Loadable;[[Ljava/lang/String;ZLorg/hibernate/engine/SessionImplementor;)[Ljava/lang/Object; (AbstractEntityPersister.java:2114)
at org.hibernate.loader.Loader.loadFromResultSet(Ljava/sql/ResultSet;ILjava/lang/Object;Ljava/lang/String;Lorg/hibernate/engine/EntityKey;Ljava/lang/String;Lorg/hibernate/LockMode;Lorg/hibernate/persister/entity/Loadable;Lorg/hibernate/engine/SessionImplementor;)V (Loader.java:1404)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Ljava/sql/ResultSet;ILorg/hibernate/persister/entity/Loadable;Ljava/lang/String;Lorg/hibernate/engine/EntityKey;Lorg/hibernate/LockMode;Lorg/hibernate/engine/EntityKey;Ljava/lang/Object;Ljava/util/List;Lorg/hibernate/engine/SessionImplementor;)Ljava/lang/Object; (Loader.java:1332)
at org.hibernate.loader.Loader.getRow(Ljava/sql/ResultSet;[Lorg/hibernate/persister/entity/Loadable;[Lorg/hibernate/engine/EntityKey;Ljava/lang/Object;Lorg/hibernate/engine/EntityKey;[Lorg/hibernate/LockMode;Ljava/util/List;Lorg/hibernate/engine/SessionImplementor;)[Ljava/lang/Object; (Loader.java:1230)
at org.hibernate.loader.Loader.getRowFromResultSet(Ljava/sql/ResultSet;Lorg/hibernate/engine/SessionImplementor;Lorg/hibernate/engine/QueryParameters;[Lorg/hibernate/LockMode;Lorg/hibernate/engine/EntityKey;Ljava/util/List;[Lorg/hibernate/engine/EntityKey;Z)Ljava/lang/Object; (Loader.java:603)
at org.hibernate.loader.Loader.doQuery(Lorg/hibernate/engine/SessionImplementor;Lorg/hibernate/engine/QueryParameters;Z)Ljava/util/List; (Loader.java:724)…(日志太多)
7）访问AdminServer中间件控制台运行缓慢现象
####<2019-11-29 下午02时03分20秒 CST> <> <> <> <1575007400246>
以上访问中间件控制台节点AdminServer缓慢现象根本原因受其他节点影响导致,当控制台重启后尝试连接其它节点信息获取节点状态信息，由于其它节点没有更多的连接资源或达到最大或达到最大线程约束值，线程一直处于请求活动状态导致，后面将节点重启后资源得到释放，控制台AdminServer访问正常
8）日志分析
####<2019-11-29 下午02时03分20秒 CST> <> <> <> <1575007400246>
####<2019-11-29 下午06时51分13秒 CST> <> <> <> <> <1575024673868>
####<2019-11-29 下午06时51分14秒 CST> <> <> <> <> <1575024674135> CryptoJDefaultPRNG=true.>
####<2019-11-29 下午06时51分14秒 CST> <> <> <> <> <1575024674206> <

---

以上日志体现，2019-11-29 下午02时03分20秒 就已至2019-11-29 下午06时51分14秒恢复节点日志正常写入（此时中间件节点进行重启恢复应用），咨询应用方，并未收到任何告警信息，建议排查接入监控系统是否正常。
6、通过工具相关分析故此类问题需要代码层面进行业务优化，将分析报告反馈应用厂商组织开发进行，业务层面测试优化，本次故障分析处理完成。