九游会官网登录入口网页-ag8九游会j9登录入口(翱途)开发平台针对o2server服务器在运行过程中出现的无响应或响应缓慢的问题,我们可以从多个不同方向进行深入而系统的排查,以确保能够准确识别并解决根本原因。
对于o2server服务器我们首要排查的是服务器日志。
服务器日志存放在 o2server目录下
o2server/logs/out.log
首先从该文件定位问题。这里会滚动记录所有服务器的消息,包括错误日志以及错误堆栈。大多数情况下我们从这里入手排查故障。
比如这里日志显示在实现单点登陆过程中访问远程认证服务器返回400错误,导致单点登陆失败。
iostat -dx 10 5
iostat 是一个用于监控系统输入/输出设备和 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.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内存跟踪情况。
在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 vm.native_memory summary
显示内存占用情况,如果没有安装jvm,可以直接使用o2server自带jvm执行。
为当前o2server服务器进程号,可以通过top进行定位,服务器目录下的pid.log文件也记录了当前服务器的进程号。
jcmd vm.native_memory summary
reserved 显示的是申请的内存,也就是top命令中看到的"res" committed 是jvm当前实际使用的内存。
图中的java heap 即对内存,一般就是最大的内存开销部分。
如果怀疑堆内存泄漏,那么就要进行堆内存分析。 首先要生成 heap profiling(hprof)文件。
ctl -hd
o2server服务器提供了一个控制台命令可以快速生成hprof文件。
也可以通过jvm提供的jmap来生成 heap profiling 文件。
jmap -dump:format=b,file=heap.hprof
如果没有安装jvm可以使用o2server自带的jvm运行jmap
生成hprof文件后可以通过分析工具进行分析
请注意这里仅仅是"怀疑"确认还需要进一步分析。
如果怀疑线程执行时间过长,或者发生死锁,那么就要进行线程分析。 首先要生成线程转储文件。
ctl -td
o2server服务器提供了一个控制台命令可以快速生成线程转储文件。
也可以通过jvm自带的jstack来生成转储文件
jstack > /tmp/threaddump.txt
如果没有安装jvm可以使用o2server自带的jvm运行jstack
您需要间隔几秒反复执行多次,这样会生成多个线程转储文件,目的是在后续步骤可以对比几个转储文件中的线程信息,判断是否有长时间运行的线程。
生成后的多个文件可以统一由分析工具打开进行分析.
对于死锁有直接的deadlock显示。其他则需要根据业务进一步分析。
nginx访问日志
/var/log/nginx/access.log
nginx错误日志
/var/log/nginx/error.log
通过从以上多个方向进行细致的排查和优化,我们可以有效地解决o2server服务器在运行中出现的无响应或响应缓慢的问题,提高其稳定性和性能表现。