Oracle Store 性能调优

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

connector.log 日志中 Metric 说明

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

• 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 内存。

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

调节 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 会自动重启，使改动的参数配置生效。