Introduction

This document describes the principles, installation, and usage of the OceanBase Log Apply Service (ApplySrv) thread optimization feature.

OceanBase is an enterprise-grade relational database developed by Ant Group. It features a native distributed architecture, high availability, high performance, and compatibility with MySQL/Oracle. OceanBase uses the Paxos protocol to ensure strong consistency among multiple replicas. ApplySrv replays the commit logs (clogs) generated during Paxos replication to the MemTable. It is a key component of the write path, and the number of its threads directly affects the write throughput and system stability.

In native OceanBase, the number of ApplySrv threads is calculated based on the fixed factor of 0.5 times the tenant's unit_max_cpu, with no upper limit imposed. When tenant specifications are large (for example, unit_max_cpu is set to a value of several hundred cores), the number of ApplySrv threads increases linearly, causing the following problems:

• An excessive number of threads increases context switching overhead and reduces effective CPU utilization.
• Thread stacks and related structures consume more memory.
• Under high-concurrency replay, resource contention among threads intensifies, which in turn slows down the replay speed.

Conversely, when tenant specifications are small (for example, unit_max_cpu is set to a value of 32 cores or fewer), the number of ApplySrv threads calculated with the fixed factor of 0.5 is too small (only 16 or fewer). As a result, log replay speed may become a bottleneck in the write path, and CPU resources cannot be fully utilized.

The ApplySrv thread optimization feature introduces the tenant-level parameter log_apply_thread_factor. It allows users to customize the ApplySrv thread calculation factor and caps the maximum number of threads at 128 when the factor is non-zero. For large-specification tenants, you can reduce the factor or use the capping mechanism to prevent excessive thread growth. For small-specification tenants, you can increase the factor to add more ApplySrv threads and alleviate the log replay bottleneck. The tests in this document are conducted on a common 32-core deployment (with OBProxy), which represents a small-specification scenario with insufficient ApplySrv threads. Appropriately increasing the number of ApplySrv threads in this scenario resulted in an approximately 5% improvement in the sysbench insert workload.