---
title: "问题自查 - 导数工具 V4.3.3.1 | OceanBase 文档中心"
description: 问题自查 本文档旨在帮助用户在使用导数工具时，可以自助查看导数工具的运行状态与问题分析。但不包括操作系统以及 OceanBase 数据库内核的状态分析与问题排查。 查看 JDK 的安装路径 步骤 1：查看 JDK 的安装路径 通常情况下，有两种方法安装 JDK： 方法 1：下载 JDK 压缩包，解压即用。 方法 2：…
---
切换语言
- 中文站 - 简体中文
- International - English
- 日本站 - 日本語
文档反馈 导数工具V 4.3.3.1
# 问题自查
更新时间：2026-04-07 17:00:52
[编辑](https://github.com/oceanbase/obdumper-loader-doc/edit/V4.3.3.1/zh-CN/900.obloaderobdumper-self-help-guide.md)
本文档旨在帮助用户在使用导数工具时，可以自助查看导数工具的运行状态与问题分析。但不包括操作系统以及 OceanBase 数据库内核的状态分析与问题排查。
## 查看 JDK 的安装路径
### 步骤 1：查看 JDK 的安装路径
通常情况下，有两种方法安装 JDK：
- 方法 1：下载 JDK 压缩包，解压即用。
- 方法 2：使用 RPM 包管理器安装 OpenJDK。
#### 方法 1：查看 JDK 压缩包的安装路径
打开 JDK 压缩包（开箱即用），查看 Java 安装包主目录。如下图所示：
- 运行 `which java` 命令，查看 Java 程序所在的路径。
- 切换到 Java 程序所在路径的父目录，运行 `ls` 查看内置的工具。
#### 方法 2：查看 OpenJDK 的安装路径
通过下述方法查看 Java 安装包主目录。如下图所示：
- 运行 `which java` 命令，查看 Java 程序所在的路径。
- 运行 `ls -lrt /usr/bin/java` 命令，查看软链接到 `/etc/alternatives/java` 文件。
- 运行 `ls -lrt /etc/alternatives/java` 命令，查看软链接到 `/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-1.1.alios7.x86_64/jre/bin/java` 文件。
- 图中，`/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-1.1.alios7.x86_64/jre` 为 Java 安装包主目录，该示例中服务器仅安装 JRE，所以 `bin` 目录下无 jps、jstat、jmap 和 jstack 等工具。
### 步骤 2：配置 JAVA_HOME 环境变量
1. 在 Java 安装包主目录的 `~/.bash_profile` 或者 `/etc/profile` 文件中配置 `JAVA_HOME` 环境变量。
```shell
export JAVA_HOME={Java 安装包主目录}
export PATH=$PATH:$JAVA_HOME/bin
```
2. 保存 `~/.bash_profile` 或者 `/etc/profile` 用户配置文件。
3. 重新进入终端窗口或者使用 `source` 命令使环境变量生效，运行 `java -version` 命令确认是否正常运行。
#### 说明
- JDK 与 JRE 是不同的概念，JRE 仅提供 Java 程序的运行环境，JDK 除了内置 JRE 外，还提供一系列命令行工具，通常位于 `{JAVA_HOME}/bin/` 目录下。例如，jps、jstat、jmap 和 jstack 等。
- **如果服务器只安装 JRE，用户无法使用 JDK 内置的命令行工具。**
## 查看垃圾回收
- `jps` (Java Virtual Machine Process Status Tool) 命令是 JDK 内置用于查看 Java 进程的工具。
```shell
jps
```
- `jstat -gc pid interval count` 命令是 JDK 内置用于监控 Java 应用程序的资源和性能的工具。
```shell
jstat -gc 进程号 1000 1000
```
实时捕捉的监控指标如图所示：
重点关注 FGC 和 FGCT 两项指标，用于描述 Full GC 总次数和总耗时。通常程序运行期间发生 Full GC 可能是内存比较紧张，用户可以调整 JVM 内存参数（默认：-Xms4G -Xmx4G）。使用 OpenJDK V1.8 部分的小版本，可能还会出现 JVM Crash 或者夯住的现象。要求使用 OpenJDK V1.8.0_3.x.x 之后的版本。
## 查看内存占用
`jmap -dump:format=b,file=./pid.hprof pid` 命令是将进程内存状态转储到 `./pid.prof` 文件中，再使用 MAT 工具进行分析。
#### 说明
pid 是指进程号。为了便于识别，二进制文件也使用进程号命名。通常用户需要将采集的文件提供给技术支持人员进行分析。
## 查看线程堆栈
`jstack pid >> pid.txt`
#### 说明
为了保留堆栈信息或者将堆栈信息提供给技术支持人员分析，建议用户将堆栈信息重定向导文件中。
`jstack` 不仅可以捕获到工具内的线程堆栈信息，也可以捕获到 JVM 内部的线程堆栈信息。部分用户反馈在大规格机器上运行导数工具时，进程内部产生许多线程，资源消耗严重，实际上 JVM 内部也会产生一些线程。详情请参见下表的介绍。
| **线程名** | **线程描述** |
| --- | --- |
| GC task thread | 默认情况下，JVM 根据逻辑核心数 n CPUs，采用以下公式来计算默认值： - n CPUs < 8，ParallelGCThreads 默认是 n CPUs - n CPUs >= 8，ParallelGCThreads = 8 + (n CPUs - 8 ) * (5/8) `-XX:ParallelGCThreads=N` 可以设置 GC 并行线程数量。 |
| C1 CompilerThread | 默认情况下，使用服务端编译则线程数为 2；使用客户端编译则线程数为 1；如果使用分层编译则线程数会达到 CPU 核心数。 终端执行 `java -XX:+PrintFlagsInitial \| grep 'CICompiler'` 和 `java -XX:+PrintFlagsFinal \| grep 'CICompiler'`查看分层编译参数启动的初始值和最终值。 用户指定`-XX:CICompilerCount=N` 设置编译线程数时，JVM 自动按照 C1:C2=1:2 比例分配线程。 |
| C2 CompilerThread | 描述同 C1 CompilerThread。 |
#### 说明
- 除 ParallelGCThreads 参数外，还有两个重要的参数：`-XX:ConcGCThreads`，`-XX:CICompilerCount`。
- ConcGCThreads 是指并发标记线程数，为了减少 GC 的停顿时间，CMS 和 G1 两种回收算法都需要并发标记。
- ConcGCThreads 的默认值是由 GC 算法决定：
- G1 回收算法：ParallelGCThreads / 4 四舍五入。
- CMS 回收算法：(ParallelGCThreads + 3) / 4 向下取整。
- JVM 根据 CPU 核心数计算 CICompilerCount，但是开启 `-XX:+CICompilerCountPerCPU`（JDK7 默认关闭，JDK8 默认开启）时，再指定 `-XX:CICompilerCount=[n]` 参数将不会生效。
JDK V1.8.0_131 之前的版本 JVM 无法感知 Docker 的资源限制的问题，导致 ConcGCThreads、CICompilerCount 默认值计算错误。**强烈建议**将 JDK 升级到 V1.8.0_131 及之后版本，特殊情况需要使用低版本 JDK 时，请指定 JVM 参数：`-XX:-CICompilerCountPerCPU -XX:CICompilerCount=[n]`。
- 上述线程仅从 Intel(R) Xeon(R) Platinum (32c) CentOS 安装的 Hotspot JVM 虚拟机中捕获的堆栈中提取。启用不同的 JVM 参数或者安装不同平台的 JVM 可能产生不同的线程堆栈信息。
## 查看运行日志
导数工具的运行日志默认是按照 INFO、WARN 和 ERROR 三个级别的日志文件进行存储。默认的日志路径位于 `-f` 指定的目录下，但是用户也可以指定 `--log-path` 设置日志输出的路径。
日志文件名分别是 `ob-loader-dumper.info`、`ob-loader-dumper.warn` 和 `ob-loader-dumper.error`。
- INFO 日志：用于打印正常的运行信息。
- WARN 日志：用于打印警告信息，警告信息基本上不会影响程序的功能和正确性，但是可能会影响性能。
- ERROR 日志：用于打印明确的错误信息，可能是程序运行错误或者是正确性相关的错误。
另外，OBLOADER 可能会产生与数据相关的日志文件：`ob-loader-dumper.discard`、`ob-loader-dumper.bad`，此类日志分别用于记录重复数据和坏数据。如果需要对日志的输出进行调整，请参考下一节 **配置运行日志** 内容。导入导出日志文件中的关键信息包括性能监控、进度监控、内核监控和最后统计。
### 性能监控
上图表示导入数据时 `ob-loader-dumper.info` 日志文件中实时打印的日志。 日志信息包括 `Enqueue Performance Monitor`（入队监控）和 `Dequeue Performance Monitor`（出队监控）。
导入程序参考“生产者-消费者”模型设计：
- 生产者线程负责读取文件并解析数据投放至内存队列，解析阶段非常消耗 CPU 资源，所以入队的性能指标可以反应出文件的解析性能。
- 消费者线程负责将数据插入数据库，写入阶段比较消耗 IO 资源，出队的性能指标可以反应出网络、数据库等整个链路的处理能力。
其中 Tps 指标用于描述每秒解析的行数，Throughput 指标用于描述每秒解析的字节数，Buffer 用于描述队列的实际的容量。上述指标会根据一秒钟/一分钟计算均值以及总和。当 Buffer 的容量较小时，表示队列比较空闲，文件解析速度较慢，可以提高文件解析的并发数；当 Buffer 容量接近饱和时，表示内存中的数据存在积压，可以考虑优化数据库写入性能。优化工作请参见 [性能调优](https://www.oceanbase.com/docs/common-oceanbase-dumper-loader-1000000002781919) 相关的文档。
### 进度监控
上图表示导入数据时，整个导入进程的处理进度。导入程序的任务划分粒度是文件切分后的总数量，每次成功导入一个子文件，内存中的进度会及时更新。为了体验上显示相对精确的进度信息，通常将文件切分地更小。默认值：64MB，用户无需修改。
### 内核监控
上图表示导入数据时，表/分区的分布以及数据库的内存水位。OceanBase 是分布式数据库，表/分区可能分布在不同的节点上，日志中会记录每个节点的合并状态，内存使用率。`Merge Status: true` 表示数据库正在合并，工具停止导入，等待合并结束，工具恢复导入。`Mem Used Ratio` 租户内存使用率超过 75%，工具进入限流，`Load Mode: SLOW` 表示慢速导入；`Mem Used Ratio` 租户内存使用率超过 85%，工具停止导入，`Load Mode: PAUSE` 表示停止导入；等待内核转储完毕，内存正常释放，工具才会恢复导入，`Load Mode: FAST` 表示快速导入。性能监控是实时采集和计算的，停止导入时监控指标可能会出现下降的趋势，恢复导入时监控指标会逐渐上升，所以从使用者的体验上来看，给用户的表现是一会快一会慢。
### 最后统计
上图表示导入数据结束后，整个过程的统计。表格中记录的是表名，解析的记录数和导入的记录数以及导入状态。其次记录整个导入过程的总记录数 `Total Count`，以及结束时间 `End Time`。最后记录整个导入的总耗时 `Total Elapsed`，以及进程的退出码（0 表示正常退出，非 0 表示异常退出）。
#### 说明
以上仅对数据导入的日志进行简单的介绍。模式导入导出，数据导出等运行日志可以参考上述解释。
## 配置运行日志
导数工具使用的是 log4j2 日志框架。`{ob-loader-dumper}/conf/log4j2.xml` 为日志的配置文件。下述为配置文件的简要说明，以及介绍如何调整配置。
### 关闭控制台输出
关闭日志内容在控制台中输出，即要求所有的日志输出到文件中。请编辑 `log4j2.xml` 配置文件，步骤如下：
1. 将 Logger 节点下 `` 注释掉。
2. 将 Root 节点下 `` 改成 ``。
## 实时打印 SQL 日志
导数工具 V4.3.1 及之后版本支持实时打印下发 SQL 的日志，默认输出路径：`<默认日志路径>/sql-monitor.log`。您可以通过 `<工具根目录>/conf/log4j2.xml` 自定义其配置。
上一篇 下一篇 [AI](https://www.oceanbase.com/obi) 咨询热线