Unveiling PolarDB's Fully Asynchronous Execution Architecture: A Performance Powerhouse for High-Concurrency Scenarios

By Jiangyi and Hualuo

1. Introduction

To address the performance issues caused by CPU contention and frequent context switching in traditional multi-threaded database scheduling models, Alibaba Cloud's cloud-native database, PolarDB for MySQL has designed a fully asynchronous execution architecture based on coroutines. It is the industry's first MySQL database product to truly implement a fully asynchronous execution architecture, dramatically improving PolarDB for MySQL's high-concurrency processing capabilities, with a more than 70% increase in general-purpose write performance and a reduction in tail latency by over 60%. Based on this asynchronous architecture, the database's foreground threads can focus on executing code instructions, avoiding unnecessary context switching overhead. Compared to the traditional MySQL thread model, this represents a tremendous leap forward and a complete revolution.

The PolarDB for MySQL fully asynchronous execution architecture has already been deployed in several customer scenarios. As the feature matures and gains wider adoption, this technology will be applied to even more customer use cases.

Figure 1: Performance comparison of various write models in sysbench

1.1 The CPU Resource Consumption "Black Hole" in Traditional Database Architectures

In typical OLTP core business scenarios (such as Taobao transactions and payment systems), Buffer Pool hit rates commonly exceed 99%. The performance bottleneck is primarily concentrated in CPU-intensive operations, meaning I/O latency from the storage layer is no longer the main issue. In high-concurrency scenarios, the traditional MySQL architecture exposes inefficiencies in thread scheduling, redundant context switching, and transaction lock contention. These kernel-level problems often prevent CPU resources from being effectively converted into actual business throughput.

Therefore, in OLTP business systems, database performance loss mainly occurs at the kernel level in the following areas:

Thread Scheduling Storms: In high-concurrency situations, traditional database kernels can generate hundreds of thousands of context switches per second, ineffectively fragmenting CPU time slices.
Synchronous Blocking Pitfalls: Critical paths like transaction commits and lock waits contain synchronization points, causing threads to spin idly while waiting.
Atomic Operation Avalanches: Contention for global resources (such as the Lock Manager) triggers an exponential increase in Compare-and-Swap (CAS) operations.
The "Memory Wall" Effect: In NUMA architectures, cross-node memory access latency can be as high as 300+ cycles. Traditional thread migration exacerbates locality-of-reference failures.

The coroutine-based fully asynchronous execution architecture in PolarDB for MySQL directly targets these core pain points by re-architecting the database kernel's scheduling module, breaking through the inefficient CPU utilization model of traditional threads.

1.2 This is Not an Isolated Trend: DeepSeek is Doing Something Similar

The 3FS distributed file system, the grand finale of DeepSeek's open-source week, further validates the revolutionary value of coroutine-based architectures in the storage domain. This file system innovatively adopts a fully asynchronous I/O stack. Through a deep, coroutine-based redesign of the user-space protocol stack and RDMA network, it achieves lock-free pipelined processing for metadata operations and the data plane. Its core "Coroutine-Aware Zero-Copy" mechanism reduces the number of context switches in the I/O path by two orders of magnitude, achieving measured performance of millions of IOPS with microsecond-level latency. This type of full-stack asynchronous architecture based on coroutines is reshaping the design paradigm of database systems—from the database engine to the underlying file system, and from the network protocol stack to the hardware acceleration layer, end-to-end non-blocking execution will become the standard for next-generation infrastructure.

It is foreseeable that this asynchronous I/O paradigm, which breaks the constraints of the traditional thread model, will inevitably drive cloud computing infrastructure toward higher throughput, lower latency, and greater elasticity.

2. Analysis of High-Concurrency Performance Issues

Take write requests as an example. Transaction log persistence is required when a transaction is committed. This synchronous I/O logic causes threads to either spin idly or switch contexts frequently. The MySQL community has made many optimizations to address this, such as group commit, which merges multiple transaction commit write operations. In this context, improving write throughput requires increasing the concurrency of foreground write operations.

However, increasing concurrency introduces its own problems:

In the traditional one-thread-per-connection model, high concurrency introduces a series of issues, such as lock contention in non-I/O scenarios (e.g., within lock_sys and trx_sys). Furthermore, under high concurrency, CPU contention and frequent context switching also degrade thread execution efficiency.
In the thread pool model, limiting the number of concurrent threads can reduce lock contention in non-I/O scenarios. The problem, however, is that it is difficult to determine the optimal number of threads. If the limit is too low, write performance cannot be maximized. If it is too high, the same problems as the one-thread-per-connection model reappear.

3. Why "Asynchronous Task" Mechanisms Don't Solve the High-Concurrency Problem

The asynchronous task designs in other databases, such as PostgreSQL, are mostly based on client-side asynchronous processing. Here, "asynchronous" means that the client sends a request via a specific API and can then proceed with other logic before the request has actually finished executing.

However, from the perspective of the database kernel:

The execution of an asynchronous request task within the DB kernel is still bound to a thread or process.
A high concurrency of asynchronous request tasks leads to thread resource exhaustion. The kernel must either create more threads to handle user requests or allow tasks to pile up.

Therefore, the asynchronous task processing mechanisms in some other databases only allow the client to execute SQL tasks asynchronously; they do not represent true asynchronous execution within the database kernel's threads and thus cannot solve kernel-level performance problems under high concurrency.

4. The PolarDB Asynchronous Execution Solution Design

Retrofitting the historical MySQL codebase for asynchronous execution is an enormous challenge, involving multiple core modules such as connection management, SQL execution, and transaction processing. It requires improving system throughput and reducing tail latency while maintaining transactional integrity. The core of the PolarDB for MySQL asynchronous execution solution is to use coroutine technology to decouple user requests from threads, utilizing eventfd for inter-coroutine communication.

Request Coroutinization: Transaction requests are encapsulated as independent coroutines managed by a user-space scheduler.
Proactive Yielding Mechanism: A suspended coroutine yields its execution rights, allowing the scheduler to immediately switch to another ready coroutine.
Efficient Resource Reuse: A single thread can handle hundreds of coroutines in parallel, reducing thread scheduling overhead.

Figure 2: PolarDB for MySQL Fully Asynchronous Execution Flowchart

4.1. Coroutine-based Request Handling

In existing designs, whether using the one-thread-per-connection or thread-pool model, the lifecycle of a user request is tied to a single thread. This means a request is handled by one fixed thread from start to finish. If the thread encounters a lock or I/O wait, it is suspended by the operating system and resumes execution only after the OS schedules it again when the wait is over. A more rational execution logic would be: when a thread executing a SQL request encounters a wait, it should proactively suspend the current SQL task and use the remainder of its CPU time slice to execute another SQL request. This requires that database threads must be decoupled from user requests.

To decouple SQL execution from threads, the PolarDB for MySQL asynchronous execution framework introduces coroutine technology, encapsulating user requests for execution within coroutines. The request lifecycle is bound to a coroutine, allowing a single kernel thread to process multiple coroutine requests concurrently.

4.2. Eventfd-based Coroutine Notification Mechanism

The core problem of executing database requests with coroutines is how to synchronize operations between them. The existing method for synchronization between threads is os_event_t (using pthread_mutex + pthread_cond). For example, Thread A enters a wait state using os_event_t, and after Thread B completes an I/O operation or releases a resource, it wakes up Thread A using pthread_cond_broadcast. However, in our asynchronous execution model, a user request (coroutine) will proactively suspend itself and cannot respond to pthread_cond_broadcast. Therefore, a completely new wait-and-wakeup mechanism for thread-coroutine and coroutine-coroutine interaction was needed within MySQL.The PolarDB for MySQL solution is as follows:

▶Coroutine Wait Mechanism

To solve the coroutine state synchronization problem, we introduced eventfd[1]. Each coroutine object creates an efd object for communicating with other threads or coroutines. When a coroutine suspends, it registers its efd with an epoll instance, which is monitored by a unified background thread. The coroutine then enters a suspended state, awaiting an event.

[1] https://man7.org/linux/man-pages/man2/eventfd.2.html

▶Coroutine Wake-up Mechanism

When a background thread completes an I/O request, or another coroutine releases a resource, it writes to the corresponding eventfd to notify the waiting coroutine. The background listening thread captures all ready coroutine tasks and either processes them directly or places them in a queue for other threads to handle.

This mechanism overcomes the limitations of traditional thread broadcast wake-ups, achieving three major improvements: zero spurious wake-ups, nanosecond-level responsiveness, and the ability to manage millions of concurrent connections.

4.3. Request Scheduling.

In the PolarDB for MySQL fully asynchronous execution architecture, requests (tasks) are prioritized based on multiple dimensions, such as the client IP address, user type, request type, transaction type, and the current suspension point. The scheduler automatically places tasks into different queues for scheduling based on their priority. A starvation prevention mechanism is also designed, which allows for thread over-provisioning and cross-thread scheduling.

4.4. Dynamic Toggling Design

In designing PolarDB for MySQL's asynchronous execution architecture, we not only focused on the benefits of the new solution but, more importantly, on how to introduce it safely into a production environment. Therefore, a dynamic toggle is crucial. The PolarDB asynchronous execution solution allows users to globally toggle the feature on or off with a single command via a global variable. It also allows for granular control over whether specific critical paths—such as authentication, binlog/redo log writes, and row lock waits—use asynchronous execution.

5. Benefits of the PolarDB for MySQL Asynchronous Execution Framework

The following is a summary of test results based on the latest PolarDB for MySQL 8.0.2 version. With the current asynchronous execution capabilities, there are very significant optimizations in write throughput and tail latency.

5.1 OLTP Insert Scenario

Figure 3: sysbench oltp_insert Performance Comparison

5.2 OLTP Non-Indexed Update Scenario

Figure 4: sysbench oltp_update_non_index Performance Comparison

5.3 OLTP Indexed Update Scenario

Figure 5: sysbench oltp_update_index Performance Comparison

5.4 OLTP Write-Only Scenario

Figure 6: sysbench oltp_write_only Performance Comparison

6. Conclusion

Driven by continuous innovation and a deep understanding of the difficult challenges in high-concurrency database technology, PolarDB has introduced a revolutionary, fully asynchronous execution architecture into the MySQL ecosystem, aimed at solving the kernel-level concurrency bottlenecks that traditional solutions cannot handle. This fully asynchronous architecture is still under rapid iteration. With further performance testing and optimization, the PolarDB asynchronous execution solution will continue to demonstrate its technical advantages across an even wider range of application scenarios.

Community

Unveiling PolarDB's Fully Asynchronous Execution Architecture: A Performance Powerhouse for High-Concurrency Scenarios

1. Introduction

1.1 The CPU Resource Consumption "Black Hole" in Traditional Database Architectures

1.2 This is Not an Isolated Trend: DeepSeek is Doing Something Similar

2. Analysis of High-Concurrency Performance Issues

3. Why "Asynchronous Task" Mechanisms Don't Solve the High-Concurrency Problem

4. The PolarDB Asynchronous Execution Solution Design

4.1. Coroutine-based Request Handling

4.2. Eventfd-based Coroutine Notification Mechanism

▶Coroutine Wait Mechanism

▶Coroutine Wake-up Mechanism

4.3. Request Scheduling.

4.4. Dynamic Toggling Design

5. Benefits of the PolarDB for MySQL Asynchronous Execution Framework

5.1 OLTP Insert Scenario

5.2 OLTP Non-Indexed Update Scenario

5.3 OLTP Indexed Update Scenario

5.4 OLTP Write-Only Scenario

6. Conclusion

Read previous post:

Read next post:

ApsaraDB

You may also like

Comments

ApsaraDB

Related Products

PolarDB for MySQL

PolarDB for PostgreSQL

PolarDB for Xscale

AnalyticDB for MySQL