weblogic日常维护总结与故障诊断

中间件故障诊断总结 一 步骤 1 准确描述现象 客户说的和自己查看到的 平台 版本 操作 信息等 特 别是 故障前是否有做过什么操作 网络调整 设备调整 主机参数调整 配 置文件修改 反正将这一切都列入排查的对象 2 使用工具收集数据 收集配置文件 日志 dump 文件等等 3 使用分析数据 根据问题或收集的数据 使用适当的工具分析数据 当然 包括了在网上和在官方支持站点搜索类似的问题的解决办法 4 尝试解决问题 根据找到的问题点 尝试解决 如修改错的 复原正确的 运行有问题的 适当调整运行的环境和运行的参数等等 5 给出最佳解决方案 一般就是继续观察了 6 总结经验并加以重用 知识积累 二 通过前台收集基本的信息 1 重点是故障前做过的操作 2 比对运行平台是否在官方的兼容性列表中 一般就是关注各个版本 特别是 一些比较怪异的问题 3 检查环境和参数 如能打开控制台 就在控制台中初步观察 一般进入控制 台的格式是 http ip 地址 端口 console 如 http 192 168 0 89 7001 console 常用的留意点如下 A 域运行状态 域 监视 健康状况 一般为 running 状态 如果不是 running 那这些界面就没有了 B 服务器运行状态 域 环境 服务器 正常的为 running C 各个 server 性能 JVM 状态 域 环境 服务器 点击具体的 serve 后 进入 监视 健康状况 留意 JVM 堆中当前可用的内存量 不同的 JVM 所显示的内容可能不一样 以下为 sun 的 D 各个 server 线程状态 域 环境 服务器 点击具体的 serve 后进入 监视 线程 一般来说 空闲线程要多 健康状况为 ok 如下图 health 状态为 Warning 这个是有线程阻塞的 阻塞线程的内容为 Servers 右侧菜单 AdminServer admin logging 只找到 examplesServer log access log 配置 如图 4 其他 如果日志太少 里面没有记载相关信息 可参照日志文件的回滚设置 在 滚动类型 属性页中可以设置这些日志文件的回滚方式 当日志文件到一定 得大小或过了设定的时间后 把日志信息保存到一个新的文件中 WebLogic 提 供按文件大小和时间两种方式 如下面的设置种 选择 Rotation Type 为 BY SIZE 也就是当日志文件的大小达到 500K 时 重新写一个新的文件 假如 Rotation Type 为 BY TIME 那么是每隔一段时间重新写一个新的文件 并且 对这些文件编号设置日志文件名如 yyyy MM dd hh mm 5 日志的处理 查看日志中输出的具体内容 再进行处理 如 BEA 下面是一个线程阻塞的一个信息 STUCK ExecuteThread 1 for queue weblogic kernel Default self tuning has been busy for 2 503 seconds working on the request weblogic work SelfTuningWorkManagerImpl WorkAdapterImpl deab5f which is more than the configured time StuckThreadMaxTime of 2 400 seconds Stack trace 四 产生 hread Dump 来分析问题 hread Dump 是非常有用的诊断 Java 应用问题的工具 每一个 Java 虚拟机都有 及时生成显示所有线程在某一点状态的 thread dump 的能力 虽然各个 Java 虚 拟机 thread dump 打印输出格式上略微有一些不同 但是 Thread dumps 出来的 信息包含线程 线程的运行状态 标识和调用的堆栈 调用的堆栈包含完整的 类名 所执行的方法 如果可能的话还有源代码的行数 Thread Dump 特点 能在各种操作系统下使用 能在各种 Java 应用服务器下使用 可以在生产环境下使用而不影响系统的性能 可以将问题直接定位到应用程序的代码行上 Thread Dump 能诊断的问题包括 查找内存泄露 常见的是程序里 load 大量的数据到缓存 发现死锁线程 收集收集 ThreadThread DumpDump 进行 Thread Dump 的方法取决于安装挂起服务器实例的操作系统 有关 在不同的操作系统上进行 Thread Dump 的信息 Solaris OS Control Backslash kill QUIT LinuxLinux Linux 操作系统查看线程的方式不同于其它操作系统 该操作系统将每个线程 视为一个进程 若要在 Linux 上进行 Thread Dump 查找通过其启动所有其它 进程的进程 ID 使用命令 若要获得根 PID 使用 ps efHl grep java 使用一个作为字符串的 grep 参数 可在与服务器启动命令匹配的进程堆栈中 找到该字符串 如果 ps 命令还没有管道传送到另一个例程 则报告的第一 个 PID 将是根进程 IBM AIX 在 AIX 上用 IBM 的 JVM 内存溢出时默认地会产生 javacore 文件 关于 cpu 的 和 heapdump 文件 关于内存的 执行 kill 3 命令可以生成 javacore 文件和 heapdump 文件 pid 为 was java 进程的 id 号 可以用 ps ef grep java 查到 可以多执行几次 有些 Java 应用服务器是在控制台上运行 如 Weblogic 为了方便获取 threaddump 信息 在 weblogic 启动的时候 最好将其标准输出重定向到一个 文件 用 nohup sh startWebLogic sh start log r doit 10000 Exception in thread main java lang StackOverflowError class Recursive public int doit int t if t 1 return 1 return t doit t 1 ProgramProgram countercounter 每个运行中的 Java 程序 每一个线程都有它自己的 PC 寄存器 也是该线程启 动时创建的 PC 寄存器的内容总是指向下一条将被执行指令的饿地址 这里的地址可以是一个本地指针 也可以是在方法区 中相对应于该方法起始指令的偏移量 NativeNative methodmethod stackstack 对于一个运行中的 Java 程序而言 它还能会用到一些跟本地方法相关的数据区 当某个线程调用一个本地方法时 它就进入了一个全新的并且不再受虚拟机限 制的世界 本地方法可以通过本地方法接口来访问虚拟机的运行时数据区 不 止与此 它还可以做任何它想做的事情 比如 可以调用寄存器 或在操作系 统中分配内存等 总之 本地方法具有和 JVM 相同的能力和权限 这里出现 JVM 无法控制的内存溢出问题 native heap OutOfMemory 旧系统 2 服务器挂起 问题描述 在出现以下情况时怀疑服务器挂起 服务器不响应新的请求 请求超时 请求处理的时间越来越长 其最终结果可能是挂起 通常 服务器挂起不会表现为服务器崩溃 但服务器挂起之后可能会崩溃 资源濒临枯竭 内存 工作线程 数据库连接池 故障排除 请注意 并非下面所有任务都需要完成 有些问题仅通过执行几项任务就可以 解决 快速链接 为什么发生此问题 服务器挂起的可能原因 基本步骤 已知的 WebLogic Server 问题 收集 Thread Dump Thread Dump 分析 为什么发生此问题 服务器挂起有多种原因 一般而言 服务器挂起是因为缺少某种资源 缺少资 源会阻止服务器响应服务请求 例如 由于故障 死锁 或者大量请求的缘故 可能没有任何可用的执行线程来完成工作 所有执行线程都被占用或忙于处理 以前的请求 引起引起 Server Hang 的原因的原因 工作线程太少 垃圾回收占用时间太多 JVM 代码优化问题 应用程序死锁 JDBC 死锁 Remote JNDI lookups JSP 编译 JSP 不正确的设置 PageCheckSeconds JVM bug 服务器挂起的可能原因 主题模式名称链接 RMI RJVM 响应 所有绑定线程等待 RJVM RMI 响应 EJB RMI 服务器挂 起 EJB RMI 服务器挂起 应用程序死锁 线程锁定资源 1 然后等待锁定资源 2 另一个线程锁定资 源 2 然后等待锁定资源 1 应用程序死锁导致服务器挂起待定 线程全部被占用 没有线程可用于新工作 线程占用导致服务器挂起待定 垃圾回收花费太多时间 垃圾回收导致服务器挂起待定 servlet 时间的 JSP 错误设置 比如 PageCheckSeconds JSP 导致服务器挂 起 待定 死锁造成 JDBC 挂起 JDBC 中的服务器挂起待定 代码优化 过程中的 JVM 挂起类似于服务器挂起 代码优化中服务器挂起 待定 在大量负载情况下 JSP 编译造成服务器挂起 JSP 编译导致服务器挂起待 定 SUN JVM 错误 比如轻量型线程库 Sun JVM 错误导致服务器挂起待定 返回页首 基本步骤 当服务器挂起时 首先使用 java weblogic Admin t3 server port PING 来 ping 该服务器 如果服务器能够响应此 ping 则可能是应用程序正在挂起而 不是服务器自身 确保服务器确实正在挂起 而不是在做垃圾回收 若要验证挂起 启用 verbosegc 重新启动服务器 然后将 stdout 和 stderr 重定向到一个文件中 当服务器停止响应时 可以判断它是正在收集无用信息还是确实挂起 WebLogic Server 使用 Default 线程队列响应客户端服务请求 这些是在发 生服务器挂起时应当检查的线程 下面是其中一个线程在 Thread Dump 中的形 式示例 Execute Thread 14 正在等待任务 该线程调用的最后方法是 Object wait ExecuteThread 14 for queue default daemon prio 5 tid 0 x8b0ab30 nid 0 x1f4 waiting on monitor 0 x96af000 0 x96afdc4 at java lang Object wait Native Method at java lang Object wait Object java 420 at weblogic kernel ExecuteThread waitForRequest ExecuteThread java 94 at weblogic kernel ExecuteThread run ExecuteThread java 118 确定 Default ExecuteThread 队列是否超载 利用控制台确定 Default 队列中的所有 ExecuteThreads 是否空闲 如果没有一个空闲 则应用程序可 能需要一个更大的 ExecuteThread 数来配置 可以通过控制台更改该值 并将 其保存在 config xml 文件中 如果执行队列有空闲线程 则可能没有分配足够的 Socket Reader 线程 缺省 情况下 WebLogic Server 实例在启动时创建三个 Socket Reader 线程 如果 群集系统在高峰期使用的 Socket Reader 线程超过三个 则增加 Socket Reader 线程的数量 通常 Socket Reader 线程的数量应当较小 但是 如果 Weblogic Serve 充 当正在挂起的服务器实例的客户端 则应当为每个 Weblogic Serve 配置一个 线程 如果使用 JDBC 连接池 确保池中已经配置的 JDBC 连接数量与同时请求 即 执行线程 的数量相等 已知的 WebLogic 问题 JDBC 产生死锁问题的可能性存在 检查在 weblogic log 开头找到的服务器的 版本和 Service Pack 级别 然后对已经应用于服务器类路径的所有临时修补 程序检查以上版本和 Service Pack 行 修补程序将指明已经解决了什么问题 Thread Dump 分析 分析服务器挂起的最有用的工具是一系列 Thread Dump Thread Dump 提供关 于每个线程在特定时刻正在执行什么操作的信息 一系列 Thread Dump 一般 每隔 5 到 10 秒进行三个或更多 Thread Dump 可以帮助分析每个线程从一个 Thread Dump 到另一个 Thread Dump 过程中的状态变化或所缺少的变化 挂起 服务器 Thread Dump 一般显示线程状态从第一个 Thread Dump 到最后一个 Thread Dump 中变化很小 在 Thread Dump 中查看的内容 所有请求都通过 ListenThread 进入 WebLogic Server 如果 ListenThread 丢失 就无法接收任何工作 因此也无法完成任何工作 确认在 Thread Dump 中存在 ListenThread ListenThread 应当在 socketAccept 方法中 下面示 例说明监听线程 Listen Thread 的形式 ListenThread Default prio 10 tid 0 x nid 93 lwp id runnable 0 x 1a81b000 0 x1a81b530 at PlainSocketImpl socketAccept Native Method at PlainSocketImpl accept PlainSocketImpl java 353 locked a PlainSocketImpl at ServerSocket implAccept ServerSocket java 439 at ServerSocket accept ServerSocket java 410 at weblogic socket WeblogicServerSocket accept WeblogicServerSocket java 2 4 at weblogic t3 srvr ListenThread accept ListenThread java 713 at weblogic t3 srvr ListenThread run ListenThread java 290 Socket Reader 线程接受来自监听线程队列的传入请求 并将该请求放入执行 线程队列 如果 Thread Dump 中没有 Socket Reader 线程 则在某个地方存 在导致 Socket Reader 线程消失的错误 应当始终保持至少有三个 Socket Reader 线程 一个 Socket Reader 线程一般用于轮询功能 另外两个用于处 理请求 下面是一个 Thread Dump 示例中的 Socket Reader 线程 ExecuteThread 2 for queue weblogic socket Muxer daemon prio 10 tid 0 x nid 75 lwp id waiting for monitor entry 0 x1b12f000 0 x1b12f530 at weblogic socket PosixSocketMuxer processSockets PosixSocketMuxer java 9 2 waiting to lock a java lang String at weblogic socket SocketReaderRequest execute SocketReaderRequest java 32 at weblogic kernel ExecuteThread execute ExecuteThread java 178 at weblogic kernel ExecuteThread run ExecuteThread java 151 ExecuteThread 1 for queue weblogic socket Muxer daemon prio 10 tid 0 x00035fc8 nid 74 lwp id runnable 0 x1b1b0000 0 x1b1b0530 at weblogic socket PosixSocketMuxer poll Native Method at weblogic socket PosixSocketMuxer processSockets PosixSocketMuxer java 9 9 locked a java lang String at weblogic socket SocketReaderRequest execute SocketReaderRequest java 32 at weblogic kernel ExecuteThread execute ExecuteThread java 178 at weblogic kernel ExecuteThread run ExecuteThread java 151 ExecuteThread 0 for queue weblogic socket Muxer daemon prio 10 tid 0 x00035e68 nid 73 lwp id waiting for monitor entry 0 x1b 0 x1b at weblogic socket PosixSocketMuxer processSockets PosixSocketMuxer java 9 2 waiting to lock a java lang String at weblogic socket SocketReaderRequest execute SocketReaderRequest java 32 at weblogic kernel ExecuteThread execute ExecuteThread java 178 at weblogic kernel ExecuteThread run ExecuteThread java 151 ThreadPoolPercentSocketReaders 属性设定要用于从 java Socket 中读取消 息的执行线程的最大