O2OA(翱途)服务器故障排查

O2OA(翱途)开发平台针对o2server服务器在运行过程中出现的无响应或响应缓慢的问题,我们可以从多个不同方向进行深入而系统的排查,以确保能够准确识别并解决根本原因。

应用服务器日志

对于o2server服务器我们首要排查的是服务器日志。

服务器日志存放在 o2server目录下

o2server/logs/out.log

首先从该文件定位问题。这里会滚动记录所有服务器的消息,包括错误日志以及错误堆栈。大多数情况下我们从这里入手排查故障。

比如这里日志显示在实现单点登陆过程中访问远程认证服务器返回400错误,导致单点登陆失败。

服务器磁盘繁忙

iostat -dx 10 5

iostat 是一个用于监控系统输入/输出设备和 CPU 使用情况的 Linux 命令。它可以帮助用户分析磁盘性能、识别瓶颈并优化系统性能。

尤其是数据库服务器可能会有io的问题。

这个命令会每 2 秒显示一次扩展 I/O 统计信息,共显示 10 次。

iostat.png

命令输出中的最后一列 %util 表示设备的利用率百分比。它指的是在报告期间设备处于忙碌状态的时间比例。

%util 值范围从 0 到 100。 这个值越高,表示设备在报告期间越频繁地处理 I/O 请求。如果该值接近 100%,说明设备几乎一直在忙于处理读写请求,可能存在 I/O 瓶颈。 如果 %util 值较低(例如低于 50%),则表示设备的使用率较低,可能未充分利用。

检查系统负载

使用 top 命令查看 CPU、内存和进程的使用情况,检查是否有高负载的进程。

top

top 命令是用于实时监控 Linux 系统性能的工具,显示系统的 CPU 使用率、内存使用情况和运行中的进程。以下是 top 命令输出中各部分的详细解释:

top 命令输出中的 load average 表示系统在特定时间段内的平均负载,它通常包括三个数值,分别表示过去 1 分钟、5 分钟和 15 分钟的平均负载。

表示在过去的时间段内,平均有多少个进程正在等待 CPU 处理或正在使用 CPU。这个值越高,表示系统的负载越重。

top.png

如果 load average 高但 CPU 使用率相对低,可能表示 I/O 阻塞,进程在等待 I/O 操作完成。

如果 load average 的值超过 CPU 核心数量,说明系统可能处于高负载状态,可能存在性能问题。

查看系统日志:

检查 /var/log/syslog 或 /var/log/messages 中的错误信息,查看是否有异常记录。

sudo less /var/log/syslog

或者:

sudo less /var/log/messages

在 less 中,按 / 键,然后输入 error 或 fail,按 Enter 搜索。

检查磁盘空间

使用 df -h 命令查看磁盘使用情况,确保没有磁盘已满的情况。

df.png

检查服务器启动脚本

o2server的启动脚本位于o2server目录下

o2server/start_linux.sh
setsid ${current_dir}/jvm/linux_java11/bin/java -javaagent:${current_dir}/console.jar -server -Djava.awt.headless=true -Xms2g -Xmx4g -Duser.timezone=GMT+08 -XX:+HeapDumpOnOutOfMemoryError -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI --module-path=${current_dir}/commons/module_java11 --upgrade-module-path=${current_dir}/commons/module_java11/compiler.jar:${current_dir}/commons/module_java11/compiler-management.jar -jar ${current_dir}/console.jar

默认的启动脚本设置启动脚本设置为-Xms2g -Xmx4g 请检查是否有其他参数影响了服务器。

jvm实际内存占用

如果怀疑服务器内存有泄漏首先确认jvm内存跟踪情况。

在top中显示列"RES"并非实际使用的内存,是jvm申请的内存。

启用内存跟踪需要在服务器启动脚本中手工增加参数:

-XX:NativeMemoryTracking=summary

比如添加后如下:

setsid ${current_dir}/jvm/linux_java11/bin/java -javaagent:${current_dir}/console.jar -XX:NativeMemoryTracking=summary -server -Djava.awt.headless=true -Xms2g -Xmx4g -Duser.timezone=GMT+08 -XX:+HeapDumpOnOutOfMemoryError -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI --module-path=${current_dir}/commons/module_java11 --upgrade-module-path=${current_dir}/commons/module_java11/compiler.jar:${current_dir}/commons/module_java11/compiler-management.jar -jar ${current_dir}/console.jar

重启后可以通过命令:

jcmd <pid> VM.native_memory summary

显示内存占用情况,如果没有安装jvm,可以直接使用o2server自带jvm执行。

为当前o2server服务器进程号,可以通过top进行定位,服务器目录下的pid.log文件也记录了当前服务器的进程号。

jcmd <pid> VM.native_memory summary

native_memory.png

reserved 显示的是申请的内存,也就是top命令中看到的"RES" committed 是jvm当前实际使用的内存。

图中的Java Heap 即对内存,一般就是最大的内存开销部分。

堆内存分析

如果怀疑堆内存泄漏,那么就要进行堆内存分析。 首先要生成 heap Profiling(hprof)文件。

ctl -hd

o2server服务器提供了一个控制台命令可以快速生成hprof文件。

ctl_hd.png

也可以通过jvm提供的jmap来生成 heap Profiling 文件。

jmap -dump:format=b,file=heap.hprof <pid> 

如果没有安装jvm可以使用o2server自带的jvm运行jmap

生成hprof文件后可以通过分析工具进行分析

Memory Analyzer (MAT)

mat.png

请注意这里仅仅是"怀疑"确认还需要进一步分析。

线程分析

如果怀疑线程执行时间过长,或者发生死锁,那么就要进行线程分析。 首先要生成线程转储文件。

ctl -td

o2server服务器提供了一个控制台命令可以快速生成线程转储文件。

ctl_td.png

也可以通过jvm自带的jstack来生成转储文件

jstack <pid> > /tmp/threaddump.txt

如果没有安装jvm可以使用o2server自带的jvm运行jstack

jstack.png

您需要间隔几秒反复执行多次,这样会生成多个线程转储文件,目的是在后续步骤可以对比几个转储文件中的线程信息,判断是否有长时间运行的线程。

生成后的多个文件可以统一由分析工具打开进行分析.

IBM Thread and Monitor Dump Analyzer for Java (TMDA)

对于死锁有直接的DeadLock显示。其他则需要根据业务进一步分析。

nginx故障排查

nginx访问日志

/var/log/nginx/access.log

nginx错误日志

/var/log/nginx/error.log

通过从以上多个方向进行细致的排查和优化,我们可以有效地解决o2server服务器在运行中出现的无响应或响应缓慢的问题,提高其稳定性和性能表现。

上一篇:升级 Windows 后如何恢复丢失的文件-总结


下一篇:一个 Java 语言简化处理 PDF 的框架,提供了一套简单易用的 API 接口,满足多样化需求又能简化开发流程的处理方案(附教程)