精华内容
下载资源
问答
  • Javacore分析
    万次阅读
    2017-11-09 15:30:02
    转自:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1406_tuzy_javacore/1406_tuzy_javacore.html

    Javacore 与 WebSphere Commerce 性能问题

    近年来,依据 WebSphere Commerce(以下简称为 WC)搭建的电子商务网站系统日益增多。由于系统本身的复杂性,一旦系统出现问题,尤其是性能问题,问题诊断和定位就会非常困难。下图所示为由 WC 系统为核心搭建的电子商务网站的一般逻辑架构 , 如图 1 所示:

    图 1. 电子商务网站的一般逻辑架构

    id="iframe_0.4125776289524481" scrolling="no">

    在整个系统架构中,核心应用逻辑运行在 WebSphere 应用服务器上。当系统出现性能问题时,虽然实际问题的根源可能分布在各个节点上,但是通过在应用服务器上的线程运行状态分析,都有助于对整个系统的当前状态以及可能的问题根源进行快速定位。WebSphere 应用服务器运行在 JVM(Java 虚拟机)之上。所以掌握通过 Javacore 进行 Java 线程分析,对于解决 WC 系统中的性能问题至关重要。

    本文介绍如何通过 Javacore 文件分析线程运行状态,以及辅助分析工具的使用。并通过实例讲解如何利用 Java 线程分析解决 WC 系统中的性能问题。本文所介绍的分析方法对于其他基于 JavaEE 构建的企业应用也有借鉴意义。

     

    如何通过 Javacore 了解线程运行状况

    Javacore 是一个当前 JVM 运行状态的快照。通过对 Javacore 的分析,可以了解在 JVM 中运行的应用程序的当前状态,比如是否“卡”在某一点上,或在某些代码上运行时间太长。

    Javacore 的基本内容

    Javacore,也可以称为“threaddump”或是“javadump”,它是 Java 提供的一种诊断特性,能够提供一份可读的当前运行的 JVM 中线程使用情况的快照。即在某个特定时刻,JVM 中有哪些线程在运行,每个线程执行到哪一个类,哪一个方法。

    应用程序如果出现不可恢复的错误或是内存泄露,就会自动触发 Javacore 的生成。而为了性能问题诊断的需要,我们也会主动触发生成 Javacore。在 AIX、Linux、Solaris 环境中,我们通常使用 kill -3 <PID> 产生该进程的 Javacore。IBM Java6 中产生 Javacore 的详细方法可以参考文章 [1]。

    对于 IBM JVM,AIX 平台上的 Javacore 会被写到 javacore.<date>.<time>.<PID>.<sequence>.txt 中。对于 Oracle JVM,Javacore 被附加到 native_stdout.txt。Javacore 的内容有两列,第一列是“类型”,第二列表示“数据”,如清单 1 所示:

    清单 1
    1TISIGINFO Dump Event "user" (00004000) received 
     1TIDATETIME Date: 2013/12/22 at 23:05:18 
     1TIFILENAME Javacore filename: 
     /usr/WebSphere/AppServer/profiles/demo_solr/javacore.20131222.230518.7995516.0004.txt

    通常情况下,Javacore 中除了线程信息外,还能提供关于操作系统,应用程序环境,线程,程序调用栈,锁,监视器和内存使用等相关信息。

    为了便于分析,Javacores 的每一段的开头,都会用“———-”和上一信息块区分开来。每一信息块的标题会以“=========”来标识,很容易找到,如清单 2 所示:

    清单 2
    NULL ------------------------------------------------------------------------ 
     0SECTION GPINFO subcomponent dump routine 
     NULL ================================ 
     2XHOSLEVEL OS Level : AIX 7.1 
     2XHCPUS Processors - 
     3XHCPUARCH Architecture : ppc64 
     3XHNUMCPUS How Many : 8 
     3XHNUMASUP NUMA is either not supported or has been disabled by user 
     NULL 
     1XHERROR2 Register dump section only produced for SIGSEGV, SIGILL or SIGFPE. 
     NULL

    Javacore 文件中,每行都包含一个标签,这个标签最多由 15 个字符组成。第一位数字表示信息的详细级别,级别越高代表信息越详细。接着的两个字符是段标题的缩写,例如:“CI”表示 Command line interpreter,“CL”表示 Class loader,“LK”表示 Locking,“ST”表示 Storage,“TI”表示 Title,“XE”表示 Execution engine 等。余下的字符表示信息的概述。如下清单 3 所示:

    清单 3
    3XMTHREADINFO "Thread-18" J9VMThread:0x00000000308DA900, 
     j9thread_t:0x0000010016C4F2E0, java/lang/Thread:0x000000004136E3E8, state:P, prio=5

    虽然不同版本的 JVM 所产生的 Javacore 的格式会稍有不同,但基本都包含下面几个内容:

    TITLE 信息块:描述 Javacore 产生的原因,时间以及文件的路径。常见的 Javacore 产生的原因可以参考文章 [2]。最常见的有下面三种:

    user:SIGQUIT 信号

    gpf:程序一般保护性错误导致系统崩溃

    systhrow:JVM 内部抛出的异常

    GPINFO 信息块:GPF(一般保护性错误)信息

    ENVINFO 信息块:系统运行时的环境和 JVM 参数

    MEMINFO 信息块:内存使用情况和垃圾回收情况

    LOCKS 信息块:用户监视器(monitor)和系统监视器(monitor)情况

    THREADS 信息块:所有 java 线程的状态信息和执行堆栈

    CLASSES 信息块:类加载信息

    Javacore 中的线程可分为以下几种状态:

    • 死锁(Deadlock)【重点关注】:一般指多个线程调用间,进入相互资源占用,导致一直等待无法释放的情况。
    • 执行中(Runnable)【重点关注】:一般指该线程正在执行状态中,该线程占用了资源,正在处理某个请求,有可能在对某个文件操作,有可能进行数据类型等转换等。
    • 等待资源(Waiting on condition)【重点关注】:等待资源,如果堆栈信息明确是应用代码,则证明该线程正在等待资源,一般是大量读取某资源、且该资源采用了资源锁的情况下,线程进入等待状态。又或者,正在等待其他线程的执行等。
    • 等待监控器检查资源(Waiting on monitor)
    • 暂停(Suspended)
    • 对象等待中(Object.wait())
    • 阻塞(Blocked)【重点关注】:指当前线程执行过程中,所需要的资源长时间等待却一直未能获取到,被容器的线程管理器标识为阻塞状态,可以理解为等待资源超时的线程。这种情况在应用的日志中,一般可以看到 CPU 饥渴,或者某线程已执行了较长时间的信息。
    • 停止(Parked)

    通过对 Javacore 数据的分析经验,结合对具体应用代码逻辑的理解,有经验的工程师可以直接通过文本编辑器查看原始 Javacore 文件来分析当前应用程序的运行状态。一般初学者则需要通过一些工具进行更直观的分析。

    图形化分析工具 TMDA

    有很多图形化工具可以用于 Javacore 的分析。笔者常用的工具为:IBM Thread and Monitor Dump Analyzer for Java 工具,简称 TMDA。TMDA 提供以下功能:

    • 提供一个简洁的 Javacore 内容的总结,包括一些初步的预警信息,线程柱状图,内存使用情况信息等等。
    • 方便地分析线程栈和监视器(monitor)的用户接口
    • 方便地进行多个 Javacore 中的线程栈和监视器进行比较的用户接口

    无论是初学者还是性能分析专家都可以使用 TMDA 进行 Javacore 的快速分析。关于 TMDA 的更多介绍可以参考它的社区:参考文献 [3]

    WC 线程执行堆栈分析

    不论是否利用 TMDA 工具进行分析,对 Javacore 的分析最终都会落实在具体线程的执行堆栈上。如果对具体应用的代码不熟悉,那么看着一个个长长的执行堆栈,可能会觉得无从下手。本部分介绍 WC 线程执行堆栈的常见代码和对应的功能模块。初学者可以根据这些示例推测某个线程的当前运行状态。需要注意的是,WC 的不同版本,同样的功能模块的具体代码可能会发生变化,经过用户定制的代码就更是千差万别。本部分提供的只是依据 WC FEP7 版本代码的一些示例,读者需要根据自己所处理的系统的实际代码情况灵活掌握,不可拘泥。

    通常一个 Javacore 里面会有上百个线程,这些线程的地位并不一样。有些线程是系统运行的“入口线程”,而其他一些线程只是由这些线程派生出来的辅助线程。所以 Javacore 分析过程中一定要抓住这些主要线程。

    WC 的核心是一个 Web 应用,所以大部分 WC 的 Javacore 以应用服务器的 Web 容器为入口。用来处理前台商店或后台管理端的 JVM 基本类似,但专门运行定时任务的 JVM 会有所区别。下图 2 所示为以 Web 容器为入口线程的一般调用结构:

    图 2. 调用结构

    id="iframe_0.49466702986365507" scrolling="no">

    从 Web 容器入口开始,一般会进入 Servlet 执行。如果有缓存而且命中的话,则会进入 DynaCache 的相关代码。如果无缓存或缓存不命中,如果是 JSP 页面,则会执行 JSP 的相关代码,否则会执行相应的逻辑。代码逻辑处理过程中,经常会访问到数据库(通过 DSL 或 EJB)或 Solr 搜索(通过 BOD 或 REST),还有可能访问到外部系统集成接口(通过 HTTP 同步调用或消息队列)。如果数据库服务器 / 搜索服务器 / 系统集成服务器分布在其他节点上,那么这些调用最终都会转化为网络访问。

    以下为一个正在处理 JSP 页面中的数据库请求的执行堆栈示例,如图 3、4、5:

    图 3. 堆栈实例(1)

    id="iframe_0.08631896789468985" scrolling="no">

    图 4. 堆栈实例(2)

    id="iframe_0.11068397203862923" scrolling="no">

    图 5. 堆栈实例(3)

    id="iframe_0.41694555904447217" scrolling="no">

    自下而上的关键代码:

    1. Web 容器处理请求

      Package 名 / 类名 . 方法名:com.ibm.ws.webcontainer/WebContainer.handleRequest

    2. RuntimeFilter

      Package 名 / 类名 . 方法名:com.ibm.commerce.webcontroller/RuntimeServletFilter.doFilterAction

    3. Servlet 处理

      Package 名 / 类名 . 方法名:com.ibm.commerce.struts/ECActionServlet.doGet

      或者

      Package 名 / 类名 . 方法名:com.ibm.commerce.struts/ECActionServlet.doPost

    4. JSP 处理

      Package 名 / 类名 . 方法名:com.ibm._jsp/_(JSP 文件名 )._jspService

    5. Command 执行(图例为 BOD command)

      Package 名 / 类名 . 方法名:com.ibm.commerce.*/Abstract(*)CmdImpl.performExecute

    6. DSL

      Package 名 / 类名 . 方法名:com.ibm.commerce.foundation.server.services.dataaccess/AbstractDataServiceFacade.*

    7. JDBC

      查询

      Package 名 / 类名 . 方法名:com.ibm.ws.rsadapter.jdbc/WSJdbcPreparedStatement.executeQuery

      或 Package 名 / 类名 . 方法名:com.ibm.ws.rsadapter.cci/WSResourceAdapterBase.executeQuery

      更新

      Package 名 / 类名 . 方法名:com.ibm.ws.rsadapter.jdbc/WSJdbcPreparedStatement.executeUpdate

      或 Package 名 / 类名 . 方法名:com.ibm.ws.rsadapter.cci/WSResourceAdapterBase.executeUpdate

    8. 数据库驱动代码

      DB2

      Package 名:com.ibm.db2.*

      Oracle

      Package 名 / 类名 . 方法名:oracle.jdbc.driver/OraclePreparedStatement.executeInternal

    9. 外部网络访问

      (网络读)Package 名 / 类名 . 方法名:java.net/SocketInputStream.socketRead0

      (网络写)Package 名 / 类名 . 方法名:java.net/SocketOutputStream.socketWrite0

    其他常见的执行堆栈举例:

    • 空闲(Idle)

      这样的堆栈表示当前线程处于空闲状态(对于 Web 容器而言,即当前线程没有接收到 Web 请求)。其调用栈为:

      Package 名 / 类名 . 方法名:java.lang/Object/wait

      Package 名 / 类名 . 方法名:com.ibm.ws.util/ThreadPool$Worker. run

      或者

      Package 名 / 类名 . 方法名:com.ibm.io.async/AsyncLibrary. aio_getioev*

      Package 名 / 类名 . 方法名:com.ibm.ws.util/ThreadPool$Worker. run

      图 6 示例截图
      id="iframe_0.09110710410460099" scrolling="no">
    • 事务(Transaction)处理

      提交(Commit)

      Package 名 / 类名 . 方法名:com.ibm.commerce.server/TransactionManager.commit

      回滚(Rollback)

      Package 名 / 类名 . 方法名:com.ibm.commerce.server/TransactionManager.rollback

    • 缓存(DynaCache)读取

      Package 名 / 类名 . 方法名:com.ibm.ws.cache/Cache.getEntry(或 getCacheEntry)

      基于 WXS 的缓存则为

      Package 名 / 类名 . 方法名:com.ibm.ws.objectgrid.dynacache/RemoteCoreCacheImpl.get

    • MultiClick 处理

      Package 名 / 类名 . 方法名:com.ibm.commerce.webcontroller.doubleclick/MultiClickRequestHandler. waitForResponse

    • 消息处理(MQ)

      Package 名 / 类名 . 方法名:com.ibm.mq.jmqi.remote.internal/RemoteRcvThread.run

    • 搜索(Solr)处理

      Package 名 / 类名 . 方法名:org.apache.solr.client.solrj/SolrServer.query

    • REST 处理

      Package 名 / 类名 . 方法名:com.ibm.commerce.foundation.internal.client.util/RESTHandler.execute

    前面作者已经强调,不同版本的 WC 代码或者经过定制的代码会有不同。读者必须在实际系统开发运维过程中积累经验,形成自己的代码样例“库”。这样才能在长长的执行堆栈中迅速抓住关键信息。

     

    案例分析

    本部分通过两个具体实例讲解如何通过 Javacore 分析来分析解决 WC 系统中的性能问题。当系统出现性能问题的时候,通常系统的工作状态会发生某些异常。我们的任务就是通过 Javacore 分析来找出系统关键线程的运行状态变化。这里一般都需要获取多次 Javacore 并进行比较,发现哪些是“变”的部分,哪些是“不变”的部分。所以,谁和谁比,比什么,是分析问题的关键。

    逻辑死锁问题

    Javacore 分析经常用于解决逻辑死锁问题。使用 TMDA 工具,可以在图形界面中快速找出不同线程之间的等待关系,如图 7 所示:

    图 7. TMDA 工具图形界面

    id="iframe_0.5969394649309345" scrolling="no">

    如果在同一个 JVM 内部出现了线程之间循环等待的状况,就会进入线程之间的死锁(Deadlock)状态。对于未定制的 WC 系统而言,直接出现这样的死锁问题的可能性比较小。较常见的是在整个系统的不同节点之间出现的逻辑死锁问题,这种问题一般不能直接在 Javacore 中识别出来。本节通过一个 WC 内部测试过程中遇到的案例介绍如何分析解决这种逻辑死锁问题。

    这是一个随机浏览产品目录的测试场景。在这个场景中,WC 应用服务器接收请求,并调用搜索服务器上的索引进行处理。简化后的系统架构图(省略了 Web 服务器)如图 8 所示:

    图 8. 简化的系统架构图

    id="iframe_0.9402593001150616" scrolling="no">

    这里,搜索服务器在处理过程中会有一次回调到应用服务器,通过应用服务器获取某些搜索所需的数据。

    我们对这个测试场景进行了用户数递增的压力测试,正常情况下,我们期望看到的结果是随着用户数的增加,系统的吞吐量逐渐上升,最后达到一个平稳状态(达到 CPU 瓶颈)。但是实际测试过程中看到的现象却是,当并发用户数增加到某个数值的时候,系统吞吐率突然下降,最终降低到 0,如图 9、10。

    图 9. 并发用户数

    id="iframe_0.9068308539700805" scrolling="no">

    图 10. 吞吐率

    id="iframe_0.5260137961988516" scrolling="no">

    此时,我们监控两个节点上的 CPU 使用状况。发现吞吐量降低为 0 的同时,CPU 使用率也几乎降低为 0。因此,初步可以判断系统出现了逻辑死锁问题。反之,如果某个节点上的 CPU 使用率(或其他资源使用率)很高,则有可能是逻辑死循环或其他代码实现问题。

    要想进一步分析就需要通过 Javacore 分析获取当前 JVM 的运行状态信息。这里我们需要分别在应用服务器和搜索服务器端获取 Javacore(采样的时间点要同步)。采样点可以做三次,在吞吐率下降前采样一次,下降后采样两次(中间间隔 30 秒以上)。然后对这三次 Javacore 进行对比分析。

    在 TMDA 中打开采样到的 Javacore 文件。TMDA 提供的“Compare Threads”功能可以用来比较这些 Javacore 文件:

    图 11. TMDA 比较菜单

    id="iframe_0.07041544352797224" scrolling="no">

    先来看 WC 应用服务器端的 Javacore 文件。前文已经解释过 Web 容器通常是整个应用的入口,所以我们重点关注 Web 容器相关线程的状态。TMDA 比较的结果如图 12 所示:

    图 12. TMDA 比较结果

    id="iframe_0.641163012861927" scrolling="no">

    用黄底色表示(TMDA 的不同版本显示效果可能略有区别)的线程表示在两次采样中的状态相同(执行堆栈相同)。这里可以很清楚地看到在第二次和第三次采样点上,所有 Web 容器的线程执行状态都相同,系统已经进入了假死(HANG)状态(注意这两次采样发生在系统吞吐率降为 0 之后)。

    这里需要注意,在第一个采样点(系统吞吐率下降之前),还有很多线程处于“阻塞”(Blocked)状态。而在第二、第三个采样点上,除了个别线程处于阻塞状态外,多数线程都处于“执行中”(Runnable)状态。由此可见,不能完全依赖 Javacore 中标明的线程状态来判断当前系统的状态,关键还是要看执行堆栈中实际在执行的代码。处于“执行中”状态的线程可能实际在等待,而处于“等待资源”(Waiting on condition)状态的线程可能实际是“执行中”状态。

    我们进一步分析第二、第三个采样点上,Web 容器各线程的执行堆栈。我们发现,虽然下层处理的页面(JSP)各有不同,但是顶层处于运行中的代码都一样:

    图 13. 执行堆栈

    id="iframe_0.3632988700762445" scrolling="no">

    基本上所有的 Web 容器线程都在等待 REST 请求的网络返回。根据前面描述的简化后的系统结构图,可以推断所有线程都在等候搜索服务器的处理结果。这是作者根据对系统结构的理解进行的判断,如果读者在实际问题分析过程中无法确定,可以使用 netstat 进行网络监控,根据 HTTP 链接的建立情况进一步确认。

    下一步,我们再比较搜索服务器端的三个时间点上的 Javacores 文件。结果是类似的,同样第二个和第三个采样点上 Web 容器的所有线程都进入了假死(HANG)状态:

    图 14. 三个采样点比较结果

    id="iframe_0.935364639862307" scrolling="no">

    我们再来看看搜索服务器端处于“执行中”的线程都在干什么。基本上所有执行堆栈的顶端都在执行如下代码:

    图 15. 执行堆栈代码

    id="iframe_0.9808389498230974" scrolling="no">

    经过代码分析,我们发现这是搜索服务器端在通过 REST 回调 WC 应用服务器,获取 BCS(BusinessConextService)相关的数据。

    这样的调用关系为什么会导致逻辑上的死锁呢?关键在于对 Web 容器的线程池资源的竞争上。每个 WC 端接收到的请求在处理过程中需要占用 Web 容器的线程池的一个线程资源,而这个处理逻辑在处理过程中请求了搜索服务器端,又通过搜索服务器端回调到 WC 端,这就需要占用 Web 容器的线程池的另一个线程资源。

    这个逻辑关系可以简化为图 16:

    图 16. 简化逻辑关系图

    id="iframe_0.37029405586605635" scrolling="no">

    在应用服务器的 Web 容器线程池资源上,通过搜索服务器的回调形成了一个闭环。这类似于标准的“哲学家就餐问题”,如果所有的请求都占用了第一个线程资源,而请求第二个线程资源,那么所有的线程都会阻塞在这个状态上,形成死锁。要解决这个线程死锁问题,必须消除这个资源占用上的闭环。可以采取的方案包括消除从 Search 端的 REST 回调,建立一个独立的线程池专门负责处理 Search 端的回调,等等。

    寻找性能瓶颈

    除了分析逻辑死锁问题外,Javacore 分析也可以用于寻找性能瓶颈。一般来说,寻找代码逻辑中的性能瓶颈,需要对代码的执行路径进行 Profiling(执行统计分析)。Profiling 工具一般有两种。能够提供完整执行堆栈的工具一般都是侵入式的,运行开销很高,并不适于在高负载的生产环境中使用。基于采样(sampling)的工具运行开销很小,但通常都不提供完整的执行堆栈。这里其实可以把 Javacore 分析当作辅助的 Profiling 工具来用。每个 Javacore 都提供了在某一时刻正在运行的代码的执行堆栈,这可以看作一个采样点。如果多做几次采样点,那么根据这些 Javacore 数据就可以进行一个执行路径的粗略 Profiling(不过总体采样点数量比真正的 Profiling 工具少很多)。

    我们仍以一个 WC 产品测试过程中遇到的问题为例介绍这种分析方法。

    我们在某个产品开发的版本测试过程中发现,搜索结果页面(SearchResultDisplay)的性能比前一个版本下降了很多。为了找出性能下降的原因,我们对该页面进行了单场景压力测试。当系统性能进入稳定状态后,我们在 WC 应用服务器端做了 Javacore 数据采样。

    同样,我们的入口线程仍是 Web 容器的线程。这里要解决的是性能下降问题(系统 CPU 占用率很高),而不是逻辑死锁问题。所以我们关注的重点是同一次采样内部线程之间的横向比较,而不是多次采样之间的横向比较,所以只需要用到 TMDA 的线程分析功能,而不需要使用线程比较功能。

    如果关注于执行堆栈的顶部代码,我们发现 Web 容器各线程的执行状况比较分散,似乎没有什么规律。但是如果从执行堆栈的底部往上看,就会发现某些规律。这里我们发现在 Web 容器的 25 个线程(等于线程池的大小)中,有一半以上的执行堆栈在执行如下图 17 代码:

    图 17. 执行代码

    id="iframe_0.34766661677378274" scrolling="no">

    由于这是单场景压力测试,基本上所有的 Web 容器线程都在执行相同的 JSP:SearchBasedCategoryPage。如果这个 JSP 里面没有明显的性能瓶颈,那么 Web 容器的 25 个线程应该随机运行在这个 JSP 的不同代码逻辑之中。我们实际观察到的现象则是有一半以上的线程都在执行如下代码:

    com/ibm/commerce/infrastructure/facade/client/AbstractInfrastructureFacadeClient.getOnlineStore

    为了排除代码执行随机性的影响,我们又在随后的系统执行过程中多做了几次采样,仍然得到了类似的结果。

    这就表示该代码有可能是整个 JSP 逻辑中的性能瓶颈(当然还不能完全确定)。另一方面,通过与前一个版本的 Javacore 进行对比分析,发现前一版本的 Javacore 中并没有出现该代码。这说明该代码是当前版本新引入的代码。通过进一步的代码分析发现,这是在当前版本中新加入的一段处理客户定制逻辑的新代码。我们屏蔽了该端代码后,重新进行了性能测试,发现性能基本上可以恢复到前一版本的水平。因此最终可以确定是这段代码导致了当前版本的性能下降问题。

    如何解决这类性能问题呢?首先应该是评估原始的实现逻辑,是否需要在每一个页面请求的处理过程中执行这段逻辑。如果不需要,则可以直接屏蔽该代码段。如果这一段逻辑必须在每一个页面请求中执行,则可以考虑引入适当的缓存机制,降低重复执行时的开销。

    这种分析方法也可以用于在客户生产系统中快速定位整个系统的性能瓶颈。生产系统执行的页面请求是多种多样的,通常情况下,在生产系统上做 Javacore 应该找不到什么规律。反之,如果多次采样可以发现系统在高负载运行状态下,Web 容器线程的执行堆栈存在某些规律,比如:大部分线程都在执行目录页面(CategoryDisplay)显示。而页面访问统计的结果显示,目录页面的访问频率并不比其他页面高很多。这种情况下就很有可能在 CategoryDisplay 页面有性能瓶颈。下一步就可以进行单场景的压力测试来进一步寻找 CategoryDisplay 页面逻辑中的性能瓶颈。

    如果能将 Javacore 分析的结果,与其他基于采样的 Profiling 工具的分析结果相结合,则更容易快速找到代码中的性能瓶颈。

    更多相关内容
  • javacore分析工具

    热门讨论 2014-02-10 10:23:30
    IBM Thread and Monitor Dump Analyzer for Java 2014年1月最新发布 可以分析weblogic或was当机生成的javacore和dump文件 使用方法在命令行输入 java -Xmx500m -jar jca452.jar
  • windows下websphere如何生成javacore文件

    千次阅读 2019-03-05 15:06:40
    Javacore是分析性能问题的重要工具之一,在linux/unix/aix操作系统下,生成javacore的方法很简单,执行kill -3 java进程号即可。在windows下,对于tomcat/weblogic这种有输出控制台的系统,可以将焦点定位在控制台上...

    一、问题描述

    Javacore是分析性能问题的重要工具之一,在linux/unix/aix操作系统下,生成javacore的方法很简单,执行kill -3 java进程号即可。在windows下,对于tomcat/weblogic这种有输出控制台的系统,可以将焦点定位在控制台上,然后通过组合键ctr+break,即可在控制台输出javacore的信息,但是windows下的websphere启动后并没有控制台输出,将如何生成javacore呢?

    二、解决方案

        Websphere提供了一个wsadmin.bat工具,可以解决此问题。操作步骤如下:

         1.进入cmd命令窗口,进入到WAS安装目录,例如:

    E:\program\IBM\WebSphere\AppServer\bin,然后执行命令

    wsadmin.bat -profileName AppSrv01,如下所示

    其中AppSrv01是概要文件名。通过以上命令连接到了AppSrv01对应节点localhostNode01的server1进程上。

    2.接着输入如下命令

    set jvm [$AdminControl completeObjectName type=JVM,process=server1,*],

           如下所示:

             其中只有server1表示server的名称,根据实际情况进行替换。

        3.最后输入如下命令

              $AdminControl invoke $jvm dumpThreads,如下所示:

          

          这样就在E:\program\IBM\WebSphere\AppServer\profiles\AppSrv01的目录下生成了javacore文件。

        此方法不仅仅在windows下有效,在linux/unix/aix下同样有效,只不过在非windows操作系统下我们可以直接通过kill -3的方式生成javacore,更加快捷方便。

    三、总结

    wsadmin工具提供了很多功能,生成javacore只是其中一个,它还可以用来生成heapdump文件,关于wsadmin的用途和用法需要在今后的工作实践中逐渐学习和运用。

     

    补充:

    手动生成heapdump的方法与生成javacore的方法类似,第1步相同,第2和第3步如下:

    2.wsadmin>set objectName [$AdminControl queryNames WebSphere:type=JVM,process=server1,*]

    其中只有server1表示server的名称,根据实际情况进行替换。

    3.wsadmin> $AdminControl invoke $objectName generateHeapDump

    展开全文
  • IBM JDK生成Javacore的方法

    千次阅读 2018-06-30 00:07:46
    根据IBM JDK的文档,有以下的方法可以选择生成Javacore:1. JVM执行异常时,自动生成Javacore1.1 发生了引起JVM停止运行的本地错误时,会自动产生Javacore文件1.2 JVM内存不足时,会自动产生Javacore文件2. 触发JVM...

    什么是IBM SDK, Java Technology Edition

        IBM SDK, Java Technology Edition是IBM对Java标准的实现。如下图所展示的JDK,JRE,JVM和JIT之间的关系,Java实现“Write once, run anywhere”,是因为JVM处理了不同硬件平台的差异。IBM有自己独特的操作系统,AIX,Z/OS,因此有必要在此之上实现自己的JVM。另一方面,IBM的中间件WebSphere Application Server基于IBM自有的JDK,Oracle JDK的目标是即面向桌面应用也面向企业应用、甚至包括移动应用,IBM自有的JDK主要面向企业应用,针对企业应用的特性做了优化,也形成了自己独特的竞争优势。

    如何生成javacore

        javacore在诊断Java相关的问题时非常重要。根据IBM JDK的文档,有以下的方法可以选择生成Javacore:
    1. JVM执行异常时,自动生成Javacore
    1.1 发生了引起JVM停止运行的本地错误时,会自动产生Javacore文件
    1.2 JVM内存不足时,会自动产生Javacore文件
    2. 触发JVM生成JDK
    2.1 (常用)从命令行中发出kill -3 <pid>指令,生成Javacore
    2.2 在应用中调用com.ibm.jvm.Dump.JavaDump()方法,生成Javacore
    2.3 使用WAS wsadmin utility命令生成Javacore, 以Jython语言为例:
    jvm = AdminControl.completeObjectName('type=JVM,process=server1,*')
    AdminControl.invoke(jvm, 'dumpThreads')
    2.4 可以配置dump agent触发生成Javacore
    dump agent提供了一些可配置的选项,详细见文档
    生成Javacore可以响应的事件列表如下:
    • gpf: A General Protection Fault (GPF) occurs.
    • user: The JVM receives the SIGQUIT (Linux, AIX®, z/OS®, and i5/OS™) or SIGBREAK (Windows) signal from the operating system.
    • abort: The JVM receives the SIGABRT signal from the operating system.
    • vmstart: The virtual machine is started.
    • vmstop: The virtual machine stops.
    • load: A class is loaded.
    • unload: A class is unloaded.
    • throw: An exception is thrown.
    • catch: An exception is caught.
    • uncaught: A Java™ exception is not caught by the application.
    • systhrow: A Java exception is about to be thrown by the JVM. This is different from the 'throw' event because it is only triggered for error conditions detected internally in the JVM.
    • thrstart: A new thread is started.A new thread is started.
    • blocked: A thread becomes blocked.
    • thrstop: thrstopA thread stops.
    • fullgc: A garbage collection cycle is started.
    • slow: A thread takes longer than 50ms to respond to an internal JVM request.
    • allocation: A Java object is allocated with a size matching the given filter specification
    • traceassert: An internal error occurs in the JVM

    2.5 可以使用trigger trace选项生成Javacore

    例如:-Xtrace:trigger=method{java/lang/String.substring,javadump}
    Trace trigger的配置是 -Xtrace:trigger=trigger=<clause>[,<clause>][,<clause>]...
    条件可以是:
    method{<methodspec>[,<entryAction>[,<exitAction>[,<delayCount>[,<matchcount>]]]]}
    On entering a method that matches <methodspec>, the specified <entryAction> is run. On leaving a method that matches <methodspec>, the specified <exitAction> is run. If you specify a <delayCount>, the actions are performed only after a matching <methodspec> has been entered that many times. If you specify a <matchCount>, <entryAction> and <exitAction> are performed at most that many times.
    group{<groupname>,<action>[,<delayCount>[,<matchcount>]]}
    On finding any active tracepoint that is defined as being in trace group <groupname>, for example Entry or Exit, the specified action is run. If you specify a <delayCount>, the action is performed only after that many active tracepoints from group <groupname> have been found. If you specify a <matchCount>, <action> is performed at most that many times.
    tpnid{<tpnid>|<tpnidRange>,<action>[,<delayCount>[,<matchcount>]]}
    On finding the specified active <tpnid> (tracepoint ID) or a <tpnid> that falls inside the specified <tpnidRange>, the specified action is run. If you specify a <delayCount>, the action is performed only after the JVM finds such an active <tpnid> that many times. If you specify a <matchCount>, <action> is performed at most that many times.

    参考文献

    1. IBM SDK, Java Technology Edition, Version 6官方文档

    2. https://javapapers.com/core-java/differentiate-jvm-jre-jdk-jit/

    展开全文
  • 关于javacore和dump文件

    千次阅读 2020-01-04 15:09:42
    Dump 就是对程序运行时内存上的信息进行转储, ...Java 运行时对象分配在堆内存上, Heap dump 就是对堆内存进行转储. 生成 jmap 通过命令jmap -dump:live,format=b,file=***.hprof pid eg:jmap -dump:live,format=b,...

    Dump 就是对程序运行时内存上的信息进行转储, 让我们可以查看程序当时的运行情况. Dump 对于调优和排错是非常有用的工具.

    Heap Dump

    Java 运行时对象分配在堆内存上, Heap dump 就是对堆内存进行转储.

    生成

    jmap

    通过命令jmap -dump:live,format=b,file=***.hprof pid

    eg:jmap -dump:live,format=b,file=dump.hprof 48671

    环境变量

    -XX: HeapDumpOnOutOfMemoryError
    当OutOfMemoryError发生时自动生成 Heap Dump 文件

    -XX:HeapDumpPath=d:\test.hprof
    指定 dump 文件存储路径

    eclipse参数

    eclipse中运行参数添加运行参数

    -XX: HeapDumpOnOutOfMemoryError ##dump出当前的内存堆转储快照
    -XX:HeapDumpPath=E:\job   ##指定路径(转储文件还是挺大的)
    

    jconsole

    image-20200103010601431

    ps:好像生成dump文件,然后把后缀改成hprof也可以(忘了从哪里看到的了,用它须谨慎࿰

    展开全文
  • 产生时间Java程序运行时,有时会产生JavaCore及HeapDump文件,它一般发生于Java程序遇到致命问题的情况下。有时致命问题发生后,Java应用不会死掉,还能继续运行;但有时致命问题发生,Java进程会死掉;为了能够保留...
  • JAVACORE与HEAPDUMP生成大法

    万次阅读 2016-11-01 10:52:41
    JAVACORE篇: Windows平台: ORACLE JDK:HOTSPOT IBM JDK:V9 LINUX平台:  HEAPDUMP篇: Windows平台: ORACLE JDK:HOTSPOT IBM JDK:V9 LINUX平台: 前言 在项目上我们经常要生成javacore和heapdump...
  • Javacore和Heapdump生成和获取(2)

    千次阅读 2018-10-10 20:19:34
    上文 Javacore和Heapdump生成和获取(1) 重点介绍Javacore和Heapdump是啥 本文重点介绍利用jvisualvm生成Threaddump(Javacore)和Heapdump这2个文件 jvisualvm 在jdk目录中 启动 jvisualvm 选择1个java...
  • JavaCore文件分析

    千次阅读 2012-07-25 11:43:51
     Java程序运行时,有时会产生JavaCore及HeapDump文件,它一般发生于Java程序遇到致命问题的情况下。  有时致命问题发生后,Java应用不会死掉,还能继续运行;  但有时致命问题发生,Java进程会死掉;  ...
  • 如何产生javacore和heapdump文件

    千次阅读 2015-06-28 23:28:49
     修改运行脚本的javaw 到java,并且添加参数-XX:+HeapDumpOnCtrlBreak。 运行程序后,按ctrl+break, 就可以得到heapdump文件。 -Djava.awt.headless=true -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDump...
  • IBM WebSphere Javacore分析

    万次阅读 2012-11-27 17:19:11
    今天公司的服务器宕机了,抛出很多的javacore 文件,这个文件比较好分析,下面我们讲一下什么是javacore ,以及如何通过分析javaCore文件找出问题。 参考 ... 一、什么是JavacoreJavacore是Java应用程序在某一
  • 问题说明每次Tomcat重启的时候,都会生成一个JVM崩溃的文件hs_err_pid.log和将近4G的core文件。...Java Core文件生成原因从日志文件中,可以明显看到,4G大小的core文件是因为hs_err_pid.log的产生而产生的
  • 如何查看javacore和heapdump文件

    千次阅读 2015-06-28 23:36:48
    查看javacore文件  1.下载ThreadDumpAnalyser,graphviz,svgviewer  2.运行runall.bat javacore.txt,会产生三个文件dumps.xml,locktree1.svg,sidebyside.html 二。查看heapdump文件  1.从IBM网站...
  • linux 系统 jdk为weblogic10.3.5自带的oracle jRockit 1.6 kill -3weblogic 或其它 java进程都不能生成javacore文件,求指教
  • websphere如何产生javacore和heapdump

    千次阅读 2015-10-13 09:55:14
     在生产环境中一旦有内存溢出情况发生,系统会自动生成javacore和heapdump文件,但是有时候我们为解决cpu使用率较高或其它问题时,需要手工生成javacore和heapdump文件,这时我们该如何手动触发生成javacore和heap...
  • JavaCore/HeapDump文件及其分析方法

    万次阅读 2012-05-22 22:01:37
    Java程序运行时,有时会产生JavaCore及HeapDump文件,它一般发生于Java程序遇到致命问题的情况下。 有时致命问题发生后,Java应用不会死掉,还能继续运行;但有时致命问题发生,Java进程会死掉; 为了能够保留...
  • WAS生成的常见文件有哪些?...javacore.***.txt : 关于cpu的,javacore文件是java进程的快照,主要保存的是Java应用各线程在某一时刻的运行的位置,即JVM执行到哪一个类、哪一个方法、哪一行上。也即threaddump文件。
  • javacore文件及heapdump文件分析

    千次阅读 2015-06-28 23:38:11
    java程序运行时,有时会产生javacore及heapdump文件,为什么会产生这些文件呢?产生后应该如何分析呢?本文将回答上面的问题。 java程序在遇到致命问题时,就会产生这两个文件,有时产生时,java应用不会死掉,还...
  • JavaCore/HeapDump文件分析工具

    万次阅读 2013-06-19 22:47:11
    在一些平台上,在有些情况下,javacore也被称为javadump,它包含jvm和应用程序相关的在特定时刻的一些诊断信息,如操作系统,应用程序环境,线程,native stack本地堆,锁,和内存的信息。在生成heapdump文件的时候...
  • 如何手动生成heapdump和javacore文件

    千次阅读 2015-08-12 20:19:53
    一、生成javacore文件 安装目录WebSphere\AppServer\bin\wsadmin.bat输入命令 wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]  输入命令 wsadmin>$AdminControl invoke $jvm ...
  • Heapdump javacore文件分析工具

    千次阅读 2011-06-15 14:49:00
    这个一定要记下来,以备不时之需: ...不知道能不能分析HP-UX产生的javacore文件,期待中,目前没有对应的javacore,所以也没法研究。    切记: javacore文件是关于cpu的,heapdump文件是关于内存的
  • java产生core文件分析

    千次阅读 2019-11-12 15:18:43
    在c语音和c++语言编写的程序里,core文件比较常见,但是java程序产生core文件还是比较少见的,最近在一个dubbo项目中发现了一个core文件,这样的情况下一般是jvm自身的异常退出,因此我们可以使用gdb命令执行jvm路径...
  • javacore\heapdump文件分析工具

    热门讨论 2010-07-29 22:44:26
    websphere javacore与heapdump文件分析工具,jca是javacore分析工具,ha是heapdump分析工具,需要用jdk1.6打开
  • Java程序运行时,有时会产生JavaCore及HeapDump文件,它一般发生于Java程序遇到致命问题的情况下。 有时致命问题发生后,Java应用不会死掉,还能继续运行; 但有时致命问题发生,Java进程会死掉; 为了能够...
  • javacore.***.txt : 关于cpu的,javacore文件是java进程的快照,主要保存的是Java应用各线程在某一时刻的运行的位置,即JVM执行到哪一个类、哪一个方法、哪一行上。也即threaddump文件。 heapdump.***.phd : ...
  • 如何产生javacore文件和heapdump文件

    千次阅读 2010-07-01 08:09:00
    如何产生javacore文件和heapdump文件 如何产生javacore文件(关于cpu的)和heapdump文件(关于内存的)1 choose one cluster member, set the following before this server start:在was启动前设置下面环境变量(可以...
  • Java核心技术(第9版)是英文版pdf!包含卷I、卷II Core Java(Volume I--Fundamentals 9th Edition) Core Java(Volume II--Advanced Features 9th Edition)
  • 2. 如何产生javacore文件(关于cpu的)和heapdump文件(关于内存的)2.1 choose one cluster member, set the following before this server start:在was启动前设置下面环境变量(可以加在启动脚本中)export IBM_...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 810,119
精华内容 324,047
关键字:

javacore

java 订阅
友情链接: Sigma5.rar