---
title: "Oracle Store 性能调优 | OceanBase 文档中心"
description: Oracle Store 性能调优 本文介绍 Oracle Store 性能相关的参数以及调整这些参数的时机和方法。 connector.log 日志中 Metric 说明 Oracle Store 每隔 10s 会在 connector.log 中打印一次监控日志，用于监控各个队列中的数据积压情况，协助排查处理的瓶…
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*L03BS6f-o40AAAAAAAAAAAAADiGDAQ/original) 迁移服务 OMSV 4.2.1 企业版

# Oracle Store 性能调优

更新时间：2024-10-28 14:05:28

本文介绍 Oracle Store 性能相关的参数以及调整这些参数的时机和方法。

## connector.log 日志中 Metric 说明

Oracle Store 每隔 10s 会在 `connector.log` 中打印一次监控日志，用于监控各个队列中的数据积压情况，协助排查处理的瓶颈。您可以通过 `grep` 命令搜索以下关键字找到对应的队列信息，统计一段时间内的变化，每个队列默认的大小为 20000。

![metric](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/oms/oms-enterprise/metric.png)

- `log_entry_queue_size`：从 logminer 获取的数据直接入该队列，如果一直为 0，则表示 OMS 从 Oracle 服务端拉取增量数据有瓶颈，可能的原因如下：

     - Oracle 服务器的负载太大，导致 logminer 执行慢。
     - OMS 机器和 Oracle 服务器之间的网络不太稳定，或者两个服务器不在同一个地域，导致数据传输较慢。
     - 如果没有上述两种情况，在 `connector.log` 中搜索 `start loading log entries from log file` 查看当前正在分析的日志文件是否为归档文件。如果为归档文件，则可能是单线程的 logminer 达到了性能极限，需要配置为并发拉取归档，参数为 `deliver2store.logminer.fetch_arch_logs_max_parallelism_per_instance` 和 `deliver2store.logminer.max_actively_staged_arch_logs_per_instance`。其中 `deliver2store.logminer.max_actively_staged_arch_logs_per_instance` 应配置为 `2 * deliver2store.logminer.fetch_arch_logs_max_parallelism_per_instance`。

  例如，您可以配置为 `deliver2store.logminer.fetch_arch_logs_max_parallelism_per_instance=3，deliver2store.logminer.max_actively_staged_arch_logs_per_instance=6`，由于并发拉取会占用更多的内存，因此调这两个参数的时候，应同时调大对应 Oracle Store 的 JVM 内存。
 - `log_analyse_queue_size`：Oracle Store 会将 logminer 返回的结果进行解析，该队列表示解析完成后的出口队列的长度。如果队列为空，则表示瓶颈在解析上，否则表示瓶颈暂时不在这里。
 - `log_aggregator_queue_size`：在组装中的记录数，单从这个指标没法判定性能情况，需要结合下面的 `log_converter_queue_size` 来看。
 - `log_converter_queue_size`：数据转换的出口队列，如果队列为 0，则表示瓶颈在 convert 和 aggregator 两个点上，具体再看上一个指标分析，如果 `log_aggregator_queue_size` 接近 20000，则需要增加 converter 的线程数，参数为 `deliver2store.logminer.converter_thread_num`，默认值为 8。
 - `log_select_queue_size`：回查入口队列，如果队列接近 20000，则表示回查存在瓶颈，需要增加回查线程数，参数为`deliver2store.logminer.selector_thread_num`，默认值为 32。
 - `connect_task_queue_size`：logminer reader 出口队列，如果为 0，则表示下游无瓶颈，否则表示 store 框架处理存在瓶颈。
 - `log_aggregator_local_store_size`：Oracle Store 缓存的未提交事务记录的数量。Oracle 未提交事物的记录数越多，该值会越大，可收集一段时间内的值，假如这个值一直维持在一个很大的值，在某一时刻突然降了下去，则说明 Oracle 中有大事务。大事务只有在提交之后，Oracle Store 才会开始处理，所以产生一定的延迟，此时应从业务上看能否把大事务拆分开来，使 Oracle Store 能够及时处理数据，将数据输出。
 - `log_aggregator_in_disk_transaction_num`：缓存到磁盘的事务数量。当一个事务的记录数超过 `deliver2store.logminer.max_num_in_memory_one_transaction` 参数的值（默认值为 1000）时，会将事务缓存到磁盘中。当存在大事务，并且 JVM 内存支持调大时，您可以调大`deliver2store.logminer.max_num_in_memory_one_transaction`，使事务尽可能放在内存中，提高处理效率。

## 查看 Oracle Store 是否有垃圾回收

当效率低时，首先查看 Oracle Store 是否发生垃圾回收，因为垃圾回收可能会使 Oracle Store 处理变慢，最终所有的处理队列都挤满，导致进程卡死。

### 通过 connector.log 日志查看垃圾回收

搜索 `connector.log` 中 `gc.G1-Old-Generation.count` 和 `gc.G1-Young-Generation.count`关键字，当这两个数字一直在增加时，特别要关注 `gc.G1-Old-Generation.count` 是否增大，就可判断进程在垃圾回收，需要调大 JVM 内存。

### 使用 jstat 命令查看实时垃圾回收

登录到 OMS 所在容器中，用下述命令查看对应 Oracle Store 的实时垃圾回收情况。执行之前注意要把 storexxxx 替换为需要查看的那个 Oracle Store，命令执行后会每隔 3s 打印一次实时的垃圾回收，重点关注 FGC 和 FGCT，即自进程启动以来 FULL GC 的次数和消耗的时间，当FULL GC 次数在不断增加或者时间占用进程的运行时间比例超过 10% 时，就需要增大Oracle Store 的 JVM 内存。

```shell
jstat -gcutil `ps -ef | grep storexxxx | grep java | awk '{print $2}'` 3000

```

![GC](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/oms/oms-enterprise/GC.png)

## 调节 Oracle Store JVM 内存

### 调节指定的 Oracle Store

1. 停止 Store。

      1. 登录 OMS 控制台。
      2. 在左侧导航栏，单击 **运维监控** > **组件**，默认进入 **Store** 页面。
      3. 在 **Store** 页面，单击目标 Store 后的 **暂停**，该 Store 需要是 **运行中** 的状态。

             - 如果是单地域部署，**Store** 右侧会显示地域信息。
             - 如果是多地域部署，您可以在地域列进行筛选，暂停目标地域下运行中的 Store。
      4. 单击对话框中的 **确定**。
 2. 到 OMS 机器上 `/home/ds/store/storeXXX/kafka/bin` 修改 JVM 内存，`connect-drcdeliver.sh` 文件里修改 `KAFKA_HEAP_OPTS` 的值。例如，修改为 `-Xms32g -Xmx32g -Xmn8g`。通常这三个值的大小比例为 4:4:1，您可以根据机器内存调整为合理的值。
 3. 在 OMS 控制台的 **运维监控** > **组件** > **Store** 页面启动 Store。

### 调节所有的 Oracle Store

进入 OMS 机器的 `/home/ds/kafka/bin` 修改 JVM 内存，修改方法同上一步中的步骤 2，修改完成后，后面新启动的 Oracle Store 都会使用该 JVM 配置。

## 配置 Store 参数

1. 登录 OMS 控制台。
 2. 在左侧导航栏，单击 **数据迁移**。
 3. 在 **迁移项目** 页面，单击目标项目的名称，进入详情页面。
 4. 单击页面右上角的 **查看组件监控**。
 5. 在 **查看组件监控** 对话框中，单击目标组件后的 **更新**。
 6. 在 **更新配置** 对话框中，鼠标悬停至目标配置，单击显示的编辑图标。
 7. 在文本框中输入修改后的参数后，单击确认图标。

   您还可以鼠标悬停至 root 后的空白处，单击添加图标，新增 Key 和 Value 值。
 8. 修改完成后，单击 **更新**。

   完成更新后，Oracle Store 会自动重启，使改动的参数配置生效。

 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线