巡检问题归总

问题归总

weblogic控制台修改密码

登陆控制台>安全领域>myrealm（默认）>用户和组>weblogic（默认）> 口令------->保存并激活

然后注销，使用新密码登陆

weblogic启动机制会读取boot.properties配置信息，更改密码后也需要同时更改boot.properties配置文件信息，否则下次启动就会报错。

使用weblogic用户登陆服务器，停止服务，修改相应的boot.properties配置文件信息（一定要weblogic用户，且管理服务和受管理服务都必须修改）！

注意：

整体流程：控制台修改密码>登陆服务停止服务>修改配置文件信息（weblogic用户）

root用户启动weblogic

注意：root用户启动只能以root用户kill进程，weblogic运维人员没有root用户信息

解决办法：

主机人员以root用户kill掉weblogic进程，并重新赋予weblogic安装目录及子目录的weblogic用户和组。

之前的文档中给出的解决办法：

1、主机人员用root用户kill掉weblogic进程

2、hastop -local -force // root用户

3、weblogic用户启动 //weblogic 用户

4、hastart -onenode //root用户

控制台访问缓慢

设置jdk随机数JAVA_HOME/jre/lib/security/java.security

将random改为urandom或前面加/./random

在weblogic启动脚本中添加一下参数：

JAVA_OPTIONS="-Djava.security.egd=file:/dev/./urandom ${SAVE_JAVA_OPTIONS}"

重启weblogic服务进行生效。

CPU异常高

情况1

top -Hp

查看高CPU进程中线程占用CPU情况

如果线程都为100%，或者0%（都一样）

使用jdk自带的jstack工具做做进程的线程转储文件，并查看：

jstack -l <PID> >> threaddumps.log
或者
$JAVA_HOME/bin/jstack <PID> >/weblogic/threaddump_<PID>.out

用法：

用法：

jstack[-l]<pid>（连接到正在运行的进程）
jstack-F[-m][-l]<pid>（连接到挂起进程）
jstack[-m][-l]<executable><core>（连接到核心文件）
jstack[-m][-l][server_id@]<远程服务器IP或主机名>（连接到远程调试服务器）

选项：

-F强制执行线程转储。当JStA*PID不响应（进程挂起）时使用

-m打印java和本机帧（混合模式）

-我的名单很长。打印有关锁的其他信息

-h或-help打印此帮助消息

情况2：案例

使用ps查找出相应7144进程，这个是gis-server-8002节点的进程，查看gis-server-8002节点日志，发现日志报java.lang.OutOfMemoryError: GC overhead limit exceeded

####<2018-4-18 下午04时05分27秒 CST> <Error> <HTTP> <GISWEB02> <gis-server-8002>
 <[ACTIVE] ExecuteThread: '17' for queue: 'weblogic.kernel.Default (self-tuning)'>
<<WLS Kernel>> <> <> <1524038727238> <BEA-101017> <[ServletContext@804077561[app:GSgis module:GSgis path:/GSgis spec-version:2.5]] Root cause of ServletException.
java.lang.OutOfMemoryError: GC overhead limit exceeded
>

查看节点堆内存配置是否过小，增大内存后重启服务，恢复应用

注意：询问客户修改参数时是否需要审批，或他们自己修改

把之前做的135.149.64.187主机7144进程的threaddump拿下来分析。把7144进程高CPU线程7149、7146、7148、7147转换成16进制，在threaddump文件中匹配，发现这4个线程都在做gc垃圾回收。终于找到CPU高的原因，是这四个一直做gc垃圾回收的线程导致的，这也说明了堆内存不够用才会一直做垃圾回收。

修改参数后CPU高故障分析

应用那边把修改参数后的WebLogic节点启起来之后，主机又出现了用户CPU居高不下的现象，CPU高的进程还是WebLogic进程，应用那边又增加堆内存-Xms2048m -Xms2048m，重启，结果无济于事，同样的现象再次出现了。

经过上一轮的分析把目标锁定到堆内存的使用上，之前加的参数也起作用了，在/weblogic目录下生成了heapdump文件。用jmap查看当前JVM内存使用情况发现Eden区和Old区内存使用高达99%以上。了解到应用做过代码更新，断定问题出在代码上。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-49y1gb3X-1610078240775)(C:\Users\geray\AppData\Roaming\Typora\typora-user-images\image-20200909103137678.png)]

分析占用987.4M堆内存的对象，程序执行的sql查询结果太多，生成大量的对象，占用较多的堆内存。

造成本次CPU高故障的原因是之前打开一个页面，一次把页面所有的页签的数据全部加载出来，会有20多次数据库的请求，请求涉及到的大表关联比较多，生成了大量的对象把堆内存撑爆了，无堆内存可用就会一直做gc垃圾回收，导致用户CPU过高。现在分多次把页面的数据加载出来解决了此问题。

2018年4月19日，应用修改了部分代码，现在系统运行正常，没有出现CPU高的问题。

连接池泄露

日志信息中出现大量JDBC警告：

<2018-7-30 上午10时23分22秒 CST> <Warning> <JDBC> <BEA-001153> <Forcibly releasing inactive/harvested connection "weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_T4CConnection@6850403" back into the data source connection pool "JKWEB", currently reserved by: java.lang.Exception
	at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:367)

根据Oracle官方解释，造成该类问题主要原因为：业务系统代码程序获取数据库连接，当完成业务处理后，没有使用代码显式地对该连接进行关闭（即还回池中，并非关闭物理连接），从而导致分配出去的连接不能回收到连接池中进行重用，最后引发数据库连接不足，应用出现无法使用或响应缓慢的问题。建议应用人员检查上述红色标注代码的业务主线，将调用连接的代码编写finally语句块进行关闭处理。

联系业务人员进行代码检查并优化

控制台服务健康状况和连接池容量问题

控制台服务出现亚健康或不健康时，查看日志文件分析

$JAVA_HOME/bin/jmap -heap 8848	# 查看进程使用堆内存情况

使用MAT工具把生成的heapdump拿下来分析发现有两个对象占用内存较高，且这两个对象都是在执行相同的代码。

情况1

如果大量出现异常信息：连接池容量以达到最大，需要1个新的连接而创建了0个

解决办法：

连接池中的最大连接数已不满足生产需求，需调大最大连接数

通知业务人员调整报数据源中报错异常数据源调整其连接池大小。

情况2

健康状态为警告（warning）

查看日志，并做线程转储文件

分析是否存在hashmap，hashset等

发现很多线程同时对HashMap和HashSet进行操作，java中常用的HashSet、HashMap都是线程不安全的, 如果多条线程访问他们,而且多于一条的线程试图修改它们,则可能出错。

据源调整其连接池大小。

情况2

健康状态为警告（warning）

查看日志，并做线程转储文件

分析是否存在hashmap，hashset等

发现很多线程同时对HashMap和HashSet进行操作，java中常用的HashSet、HashMap都是线程不安全的, 如果多条线程访问他们,而且多于一条的线程试图修改它们,则可能出错。

建议开发人员检查相关代码，使用ConcrrentHashMap替代HashMap。