O2OA（翱途）开发平台针对o2server服务器在运行过程中出现的无响应或响应缓慢的问题，我们可以从多个不同方向进行深入而系统的排查，以确保能够准确识别并解决根本原因。
应用服务器日志
对于o2server服务器我们首要排查的是服务器日志。
服务器日志存放在 o2server目录下
o2server/logs/out.log
首先从该文件定位问题。这里会滚动记录所有服务器的消息，包括错误日志以及错误堆栈。大多数情况下我们从这里入手排查故障。
比如这里日志显示在实现单点登陆过程中访问远程认证服务器返回400错误，导致单点登陆失败。
服务器磁盘繁忙
iostat -dx 10 5iostat 是一个用于监控系统输入/输出设备和 CPU 使用情况的 Linux 命令。它可以帮助用户分析磁盘性能、识别瓶颈并优化系统性能。
尤其是数据库服务器可能会有io的问题。
这个命令会每 2 秒显示一次扩展 I/O 统计信息，共显示 10 次。
命令输出中的最后一列 %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。这个值越高，表示系统的负载越重。
如果 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 命令查看磁盘使用情况，确保没有磁盘已满的情况。
检查服务器启动脚本
o2server的启动脚本位于o2server目录下
o2server/start_linux.shsetsid ${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
reserved 显示的是申请的内存，也就是top命令中看到的"RES" committed 是jvm当前实际使用的内存。
图中的Java Heap 即对内存，一般就是最大的内存开销部分。
堆内存分析
如果怀疑堆内存泄漏，那么就要进行堆内存分析。 首先要生成 heap Profiling(hprof)文件。
ctl -hdo2server服务器提供了一个控制台命令可以快速生成hprof文件。
也可以通过jvm提供的jmap来生成 heap Profiling 文件。
jmap -dump:format=b，file=heap.hprof <pid>
如果没有安装jvm可以使用o2server自带的jvm运行jmap
生成hprof文件后可以通过分析工具进行分析
Memory Analyzer (MAT)
请注意这里仅仅是"怀疑"确认还需要进一步分析。
线程分析
如果怀疑线程执行时间过长，或者发生死锁，那么就要进行线程分析。 首先要生成线程转储文件。
ctl -tdo2server服务器提供了一个控制台命令可以快速生成线程转储文件。
也可以通过jvm自带的jstack来生成转储文件
jstack <pid> > /tmp/threaddump.txt如果没有安装jvm可以使用o2server自带的jvm运行jstack
您需要间隔几秒反复执行多次，这样会生成多个线程转储文件，目的是在后续步骤可以对比几个转储文件中的线程信息，判断是否有长时间运行的线程。
生成后的多个文件可以统一由分析工具打开进行分析.
IBM Thread and Monitor Dump Analyzer for Java (TMDA)
对于死锁有直接的DeadLock显示。其他则需要根据业务进一步分析。
nginx故障排查
nginx访问日志
/var/log/nginx/access.lognginx错误日志
/var/log/nginx/error.log通过从以上多个方向进行细致的排查和优化，我们可以有效地解决o2server服务器在运行中出现的无响应或响应缓慢的问题，提高其稳定性和性能表现。
