谈JVM内存问题分析总结04(200406)

今天我准备继续记录最近2天对该问题的进一步分析过程。

在上篇文章里面我们谈到了另外一款商用的类似MAT的工具，但是有免费的试用期，具体地址为：

https://www.yourkit.com/

于是我下载了该工具，并邮件进行了注册并申请了试用期开始使用该工具。整体试用下来的感受就是感觉并没有比MAT工具强大多少。但是这个 工具 本身强大的地方应该是实时的连接到运行中的Server进行实时的分析，这个功能我没有试用，而只是使用了对Dump出的内存快照进行静态分析功能。

还是从前面一篇文章说起，即我们怀疑是有定时执行的任务和作业再对临时文件目录进行扫描和处理，同时在上面一篇文章里面查到了Oracle有几个定时的物化视图刷新的Job，但是我们初步分析影响的地方应该不是在于这里，即物化视图刷新动作是在数据库服务器完成，没有理由会影响到应用Server服务器，同时从最终的数据库表日志来物化视图刷新全部成功，而且刷新速度也很快。

因此虽然当前刷新频率是1分钟一次，暂时没有对物化视图刷新频率进行调整。

再继续分析前我们还是谈下在进行Dump内存文件分析的时候对Thread-0的一些关键分析。

1. 在一个线程组中启动了Thread-0

2. 对一些基础类进行装载处理，重点就是装载了目录读取，文件读取相关的类

3. 找到了MFT的Control临时目录

4. 读取所有的Get临时文件目录

5. 对Get文件目录里面的所有的临时文件进行读取，并实例化Java.Io.File类

在这个过程之前的Incoming追溯，我们只能够查到线程组ThreadGroup，但是很难找到具体的为何去启动Thread-0线程，以及这个线程究竟要执行什么动作的详细内容。而基于前面我们的分析给出假设。

1. 读取定时的调度和任务配置，这个定时调度很可能是Purge File的清理调度

2. 基于定时任务和调度配置的要求，启动了Thread-0

到了这个地方的时候，我们基本没能找到其它的路径进一步展开我们的分析的，但是回到刚才谈到的新的Java Profile新工具，这个工具有另外一个重要的特点，就是对Dump内存文件进行关键字的全部检索。要知道，我们前面查询了这么多资料点，最关键的就是定时任务Schedule，Purge文件清扫。

那么自然可以想到的就是基于这两个关键字对整个内存文件进行搜索看能发现些什么。

关键字：Schedule，Purge

那么基于这个关键字查询，我们搜索到如下一些关键内容。

oracle.as.scheduler.ejb.RuntimeServiceBean

oracle.tip.mft.j2ee.ejb.MDSServiceImpl.purgeFiles

oracle.as.scheduler.ejb.RuntimeServiceBean.purgeRequest

oracle.as.scheduler.runtime.jdbc.RtsRequestPurgeSession

同时我们发现了一些其它的关键字，包括ESSAPP，ess_delete_request，request_history

基于这些信息，我们跟踪到一个新的内容，就是Oracle Enterprise Schedule 即ESS产品，为何原来没有关注到这个，因为这个ESS产品实际是内嵌在Oracle MFT产品里面，实际我们在安装部署的时候并没有单独安装。但是整个MFT产品实际上是使用了ESS这个产品提供的定时任务和定时调度作业功能。

有了这个信息后，我们进一步开始研究ESS定时作业调度，看能否有信息的发现。

分支一：Oracle的调度任务作业表

在不断的关键字搜索中，我们查询到了Oracle的调度作业表，关键的两种表就是dba_scheduler_jobs，dba_scheduler_job_run_details，这两张表存储了定时调度的Job和Job的执行记录。注意这个是Oracle调度的Job和我们前面谈到的标准Job列表是有差异的。

这个感觉是和ESS产品配合的定时调度作业任务表。因此我们对这两个表的内容进行导出分析，暂时没有看到可以进一步跟踪的内容和线索。

分支二：基于查询到的 Sql 语句出现的和ESS相关的表

根据前面我们查询到的Sql语句，还有两张表，即ess_delete_request，request_history，这个感觉是ESS产品进行的调度任务请求表和执行历史记录表。我们进一步查询，实际上包括了如下多张表。

request_history 

request_property

failed_execution_history

job_incompatibility

request_attribute

request_content

request_metadata 

wait_queue 

这些表可以看到提供看了ESS调度作业的原数据，调度历史记录，失败记录，调度内容，等待队列等各种信息。因此我们进一步查询表里面的数据，特别是request_history表，我们发现了新的关键信息。

即从request_history表的数据，我们发现有MFT的Job实际在运行，具体关键信息为：

定义：JobDefinition://oracle/apps/ess/seeded/mft/MFT_OTHER_JOB

应用：MFTCustomHostingApp

类型：JAVA_TYPE

那么到了这里后，我们实际上关键就是要去查找下这个MFT_OTHER_JOB究竟是干什么用的，具体的内容究竟是什么？具体的触发规则和触发频度又是如何的？因此从数据表的数据来看，虽然每天都在运行，但是每天实际的运行记录数还不一样。是不是和MFT每天实际传输实例的多少有关系，暂时无法确定。

分支三：能否查询到当前运行的Schedule和Job

既然从数据库的表数据已经看到有调度和作业在运行，那么能否查询到当前正在运行的作业和Job。因此我们进一步搜索如何查询当前正在运行的Job，已经如何对这些Job进行管理。当然基于这个搜索能够查询到详细的ESS产品的资料，对于这些资料进行分析。

在Oracle EM管理台有详细的ESS任务管理界面，但是注意这条路不通，因为前面我们已经讲到过，实际上我们安装的是一个内嵌式的ESS产品组件模块，这个组件模块实际在EM管理台上面并没有提供相关的管理功能。

其次，我们进一步对MFT_OTHER_JOB, ESS Schedule相关的关键字进行搜索，发现了另外一个方式，即可以通过WSLT命令来查看有哪些正在运行的Job和任务。即如下两个语句：

manageSchedulerJobDefn('SHOW','MFTCustomHostingApp')

manageSchedulerSchedule('SHOW','MFTCustomHostingApp')

通过如下两个语句运行分析，我们看了实际上一个default schedule在运行，这个schedule实际在我们前台的管控界面是Inactive未激活状态的。实际能够查询到4个Job信息，具体为：

MFT_OTHER_JOB

MFT_TRANSFER_JOB

MFT_SOURCE_JOB

MFT_TARGET_JOB

注意查询到这里，我们进一步可以确认有MFT_OTHER_JOB是在运行状态的，而且有运行日志历史记录已经写入到数据库表，和数据库表我们查询到的具体数据信息是匹配的。对于这里，也提供了对JOb进行停止的操作命令，类似如下：

manageSchedulerJobDefn('DELETE','MFTCustomHostingApp',jobName='mft/MFT_Purge')

但是实际上我们很难决策是否对这个Job进行删除卸载，具体的原因就是我们还是没有搞清楚这个Job里面究竟是什么内容，是在执行什么。简单来说如果我们已经很明确这个Job就是在执行对Purge操作，对Control临时文件目录进行扫描，那么我们就可以大胆的停用该Job，停用后再观察问题是否解决。但是对于生产环境我们很难去执行这种操作，以免引入更多的新问题。

分支四：Job类型->JavaType->查找类和源代码

前面已经谈到这个Job的类型是Java Type，简单来说就是调度作业的实现是通过 Java 代码类实现的，但是我们根据oracle/apps/ess/seeded这个路径并没有找到具体的Job定义，实际上也没有这个路径信息。

那么我们是否能够进一步查找具体的类信息。实际上我们进一步搜索Dump内存文件发现如下信息

com.bea:ApplicationRuntime=MFTCustomHostingApp,

EJBComponentRuntime=ejbs.jar,

Name=MetadataServiceBean,

ServerRuntime=mft_server32,

StatelessEJBRuntime=MetadataServiceBean,

Type=EJBTransactionRuntime" 408 408

我们进一步查找到了类似ejbs.jar, adf-loc.jar, ess.jar这些文件，但是并没有发现相关的Job定义信息。这条路应该是可行的，就是只要找到对应的Jar包，我们就可以反编译工具查看具体的源代码和实现。即，在这里，又下载了一个Java翻译工具，对相关的Jar包和Class文件进行反编译，暂时没有找到有用的信息。

进一步的问题分析点在哪里?

虽然没有得到最终的结论，但是前面的问题分析过程仍然是值得记录，到这里后我们急需要搞清楚的问题就在于ESS产品本身的一些关键功能和特性，其次就是MFT产品本身的各类作业和定时调度任务，Purge文件清理机制。当然最重要的仍然是定时触发的MFT_OTHER_JOB究竟是什么内容？是否关键的问题点就在于这里。

当然在这里也提出了一个新问题，即：在我们对Dump内存问题进行分析的时候，是否能够分析出来某一个Thread线程的启动机制是如何的，在哪里启动？启动的原因是什么？