Database thread pool control method and apparatus, electronic device, and computer medium

Abstract

The present disclosure provides a database thread pool control method and apparatus. A specific implementation of the method comprises: loading, in an operating system of a database, a dynamic runtime library allowing for replacement of a thread with a coroutine, and generating at least one coroutine scheduling thread; receiving a connection request sent by a client to the database; detecting whether a request for creating a new thread of the database is a request for processing the connection request; and in response to detecting that the request for creating the new thread of the database is the request for processing the connection request, creating a coroutine corresponding to the connection request, and scheduling the coroutine by means of the at least one coroutine scheduling thread to complete an access task corresponding to the connection request.

Description

Database thread pool control method and device, electronic device, and computer medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to the Chinese patent application filed on July 28, 2023, with application number 202310942845.1 and invention name “Database thread pool control method and device, electronic device, computer medium”, the full text of which is incorporated by reference into this application. Technical Field

[0003] The present disclosure relates to the field of computer technology, and in particular to a database thread pool control method and device, an electronic device, and a computer-readable medium. Background Art

[0004] The default concurrent connection model for the MySQL database uses a "one thread, one connection" model, creating a thread for each connection. A major drawback of this database model is that in high-concurrency scenarios, frequent thread creation and destruction can cause the database to freeze or crash. Furthermore, even when using persistent connection mode, a large number of threads significantly increases the task scheduling burden.

[0005] Summary of the Invention

[0006] Embodiments of the present disclosure provide a database thread pool control method and apparatus, an electronic device, and a computer-readable medium.

[0007] In a first aspect, an embodiment of the present disclosure provides a database thread pool control method, the method comprising: loading a dynamic runtime library capable of replacing threads with coroutines in the database operating system, generating at least one coroutine scheduling thread, the coroutine scheduling thread being used to schedule at least one coroutine; receiving a connection request sent by a client to a database; detecting whether the database's request to create a new thread is a request to process the connection request; in response to detecting that the database's request to create a new thread is a request to process the connection request, creating a coroutine corresponding to the connection request, and scheduling the coroutine through at least one coroutine scheduling thread to complete an access task corresponding to the connection request.

[0008] In some embodiments, the above-mentioned loading of a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database and generating at least one coroutine scheduling thread includes: in response to the database being unable to modify the source code and not having a connection management plug-in mechanism, starting the database; loading and initializing the dynamic runtime library, generating at least one coroutine scheduling thread, the dynamic runtime library having a hook function for creating a thread, the hook function for creating a thread being used to replace the connection processing thread generated by the native runtime library of the database with a coroutine; when the database is initialized, overloading the hook function for creating a thread to determine whether the currently created thread is a connection processing thread through the hook function for creating a thread, and when the currently created thread is a connection processing thread, converting the connection processing thread into a coroutine.

[0009] In some embodiments, the above-mentioned loading of a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database and generating at least one coroutine scheduling thread includes: starting the database in response to the database having a connection management plug-in mechanism; loading and initializing the dynamic runtime library to generate at least one coroutine scheduling thread; initializing the database; loading and initializing the plug-in so that the plug-in receives a connection request sent to the database, and when the thread construction request of the database is a request for processing the connection request, controlling the operation of the hook function for creating a thread in the dynamic runtime library, the hook function for creating a thread is used to determine whether the currently created thread is a connection processing thread, and when the currently created thread is a connection processing thread, converting the connection processing thread into a coroutine.

[0010] In some embodiments, the above method also includes: dividing at least one coroutine scheduling thread into an IO-intensive scheduling thread and a compute-intensive scheduling thread; the above scheduling of the coroutine by at least one coroutine scheduling thread to complete the access task corresponding to the connection request includes: detecting whether the coroutine corresponding to the connection request is in a state between a first state and a second state, wherein the first state is the state when the coroutine is waiting for a data packet to execute a database command, the data packet has arrived, and the coroutine needs to be awakened; the second state is the state when the coroutine is in a compute-intensive scheduling thread, and the coroutine initiates a specific write request for a specific file; if it is detected that the coroutine corresponding to the connection request is in a state between the first state and the second state, the compute-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request; if it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, the IO-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request.

[0011] In some embodiments, if it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, the IO-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request, including: in response to the coroutine corresponding to the connection request being in the stage of creating a connection, the coroutine is placed in the current IO-intensive scheduling thread, and the current IO-intensive scheduling thread is determined based on a load balancing algorithm; in response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, and completing the submission of the IO request to write the specific file and before letting the coroutine enter IO waiting, the coroutine is migrated to the current IO-intensive scheduling thread.

[0012] In some embodiments, the above-mentioned database is a MySQL database, and the above-mentioned response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, and before completing the submission of the write specific file IO request and letting the coroutine enter IO wait, migrating the coroutine to the current IO intensive scheduling thread includes: responding to the coroutine corresponding to the connection request being in a write operation on a binary log file, and before completing the submission of the write file IO request and letting the coroutine enter IO wait, migrating the coroutine to the current IO intensive scheduling thread.

[0013] In some embodiments, the above method also includes: detecting whether there is a coroutine that drives batch submission in the IO-intensive scheduling thread; if there is a coroutine that drives batch submission in the IO-intensive scheduling thread, migrating the coroutine awakened by the coroutine that drives batch submission to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which the coroutine awakened by the coroutine that drives batch submission migrates is determined based on the load balancing algorithm.

[0014] In some embodiments, the above-mentioned database is MySQL and a database with group submission enabled. The above-mentioned detection of whether the IO-intensive scheduling thread has a coroutine that drives batch submission includes: detecting whether the IO-intensive scheduling thread has a group leader coroutine that drives the group submission process for writing to the binary log file; the IO-intensive scheduling thread has a coroutine that drives batch submission, and migrating the coroutine awakened by the coroutine to the IO-intensive scheduling thread includes: if a group leader coroutine that writes to the binary log file is detected, migrating the group member coroutine awakened by the group leader coroutine to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which each group member coroutine is migrated is determined based on the load balancing algorithm.

[0015] In a second aspect, an embodiment of the present disclosure provides a database thread pool control device, which includes: a loading unit, configured to load a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database, and generate at least one coroutine scheduling thread, which is used to schedule at least one coroutine; a receiving unit, configured to receive a connection request sent by a client to a database; a detection unit, configured to detect whether the request for the database to create a new thread is a request to process a connection request; a creation unit, configured to create a coroutine corresponding to the connection request in response to detecting that the request for the database to create a new thread is a request to process a connection request, and schedule the coroutine through at least one coroutine scheduling thread to complete the access task corresponding to the connection request.

[0016] In some embodiments, the above-mentioned loading unit is configured to: start the database in response to the database being unable to modify the source code and not having a connection management plug-in mechanism; load and initialize the dynamic runtime library, generate at least one coroutine scheduling thread, the dynamic runtime library has a hook function for creating a thread, and the hook function for creating a thread is used to replace the connection processing thread generated by the native runtime library of the database with a coroutine; when the database is initialized, overload the hook function for creating a thread to determine whether the currently created thread is a connection processing thread through the hook function for creating a thread, and when the currently created thread is a connection processing thread, convert the connection processing thread into a coroutine.

[0017] In some embodiments, the above-mentioned loading unit is configured to: start the database in response to the database having a connection management plug-in mechanism; load and initialize the dynamic runtime library to generate at least one coroutine scheduling thread; initialize the database; load and initialize the plug-in so that the plug-in receives the connection request sent to the database, and when the database thread construction request is a request for processing the connection request, control the operation of the hook function for creating a thread in the dynamic runtime library, and the hook function for creating a thread is used to determine whether the currently created thread is a connection processing thread, and when the currently created thread is a connection processing thread, convert the connection processing thread into a coroutine.

[0018] In some embodiments, the above-mentioned device also includes: a division unit, configured to divide at least one coroutine scheduling thread into an IO-intensive scheduling thread and a compute-intensive scheduling thread; the above-mentioned creation unit is further configured to: detect whether the coroutine corresponding to the connection request is in a state between a first state and a second state, wherein the first state is a state in which the coroutine is waiting for a data packet to execute a database command, the data packet has arrived, and the coroutine needs to be awakened; the second state is a state in which the coroutine is in a compute-intensive scheduling thread, and the coroutine initiates a specific write request for a specific file; if it is detected that the coroutine corresponding to the connection request is in a state between the first state and the second state, the compute-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request; if it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, the IO-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request.

[0019] In some embodiments, the above-mentioned creation unit is further configured to: in response to the coroutine corresponding to the connection request being in the stage of creating a connection, place the coroutine on the current IO-intensive scheduling thread, and the current IO-intensive scheduling thread is determined based on the load balancing algorithm; in response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, and completing the submission of the IO request to write the specific file and before letting the coroutine enter IO waiting, migrate the coroutine to the current IO-intensive scheduling thread.

[0020] In some embodiments, the database is a MySQL database, and the construction unit is further configured to: in response to the coroutine corresponding to the connection request being in the writing operation of the binary log file, and completing the submission of the write file IO request and before letting the coroutine enter IO waiting, migrate the coroutine to the current IO intensive scheduling thread.

[0021] In some embodiments, the above-mentioned device also includes: a batch drive unit, which is configured to: detect whether there is a coroutine that drives batch submission in the IO-intensive scheduling thread; if there is a coroutine that drives batch submission in the IO-intensive scheduling thread, the coroutine awakened by the coroutine that drives batch submission is migrated to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which the coroutine awakened by the coroutine that drives batch submission is migrated is determined based on a load balancing algorithm.

[0022] In some embodiments, the above-mentioned database is MySQL and a database with group submission enabled, and the above-mentioned batch drive unit is further configured to: detect whether there is a leader coroutine in the IO-intensive scheduling thread that drives the group submission process for writing to the binary log file; if a group leader coroutine that writes to the binary log file is detected, the group member coroutines awakened by the group leader coroutine are migrated to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which each group member coroutine is migrated is determined based on the load balancing algorithm.

[0023] In a third aspect, an embodiment of the present disclosure provides an electronic device comprising: one or more processors; a storage device on which one or more programs are stored; when the one or more programs are executed by one or more processors, the one or more processors implement the method described in any embodiment of the first aspect.

[0024] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Other features, objects and advantages of the present disclosure will become more apparent from a reading of the detailed description of non-limiting embodiments made with reference to the following drawings:

[0026] FIG1 is a flowchart of an embodiment of a database thread pool control method according to the present disclosure;

[0027] FIG2 is a schematic diagram of a database structure disclosed in the present invention;

[0028] FIG3 is a flowchart of another embodiment of a database thread pool control method according to the present disclosure;

[0029] FIG4 is a schematic structural diagram of an embodiment of a database thread pool control device according to the present disclosure;

[0030] FIG5 is a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure. DETAILED DESCRIPTION

[0031] The present disclosure will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are intended only to illustrate the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the relevant invention are shown in the accompanying drawings.

[0032] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in the present disclosure may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0033] In traditional database technology, Percona has introduced a thread pool solution. By executing SQL (Structured Query Language) instructions in different connections in the thread pool in a time-sharing manner, it effectively controls the number of threads and reduces thread switching, thereby ensuring system performance and stability to a certain extent.

[0034] When the thread pool is enabled, client connections are placed into different priority queues based on the task priority policy and the type of SQL instruction to be executed. When there are tasks in the high-priority queue, tasks in the low-priority queue will not be executed.

[0035] Generally, when there are tasks available in the task queue but no idle worker threads, new worker threads are started to schedule these tasks. The number of worker threads will not exceed the upper limit specified by the thread pool; the parameter "thread_pool_max_threads" sets the maximum number of threads allowed to be created in the entire thread pool. If a worker thread remains idle for longer than the time set by the parameter "thread_pool_idle_timeout", it will automatically exit.

[0036] However, if the scheduled tasks generally take a long time to execute, and the number of worker threads has reached its upper limit, then the tasks in the task queue will not be scheduled for execution for a long time. A similar situation occurs when a large number of tasks continuously flood the high-priority task queue, and tasks in the lower-priority queue will also be unable to execute for a long time. This situation is a common phenomenon in concurrent task scheduling and is figuratively referred to as task "starvation."

[0037] In the existing database thread pool technology, MySQL's thread pool has a "starvation" problem. To alleviate "starvation", it is necessary to relax the limit on the number of threads exceeding the limit, or to create connections through "extra ports". However, if the excessive use of excess threads and extra ports, the so-called "upper limit on the number of threads" of the thread pool becomes meaningless. Therefore, the database thread pool implementation in the existing public technology generally has the dilemma of "starvation" and uncontrolled upper limit on the number of threads. Even when the number of thread pools is not limited, the timeout response mechanism controlled by the "thread_pool_stall_limit" parameter (default 10ms) will extend a SQL that originally only takes a few microseconds to more than 10ms (triggering a timeout using excess threads), thereby causing severe jitter in the SQL response speed.

[0038] The core issue behind this "starvation" phenomenon is that a long-running SQL, or one in a long-waiting state (such as a thread suspended due to a lock wait), cannot be swapped out of the thread currently running the SQL until it completes. This means that even if a worker thread is suspended (lock wait) while executing a SQL, it cannot be reused to schedule other SQL tasks. To execute other SQLs simultaneously, another thread must be used.

[0039] In order to better understand traditional technology, some terms are introduced below:

[0040] MariaDB: One of the most popular open source relational databases, it can be considered a fork of the MySQL database. It was created by the original developers of MySQL and is guaranteed to remain open source forever.

[0041] Percona: An open source relational database. Percona's thread pool is based on the porting of MariaDB thread pool source code, with enhanced functionality and performance optimization.

[0042] Thread pool: As the name suggests, a thread pool creates several executable threads in advance and stores them in a pool (container). When a task needs to be executed, instead of creating a new thread for the task, an existing thread in the thread pool is used. This solution reduces the number of thread creation and destruction, reduces the scheduling burden, and thus improves system performance.

[0043] Binlog: A binary log file records the history of user updates to a database. It is often used to implement incremental replication in a master-slave database architecture. The master database continuously generates binlogs and synchronizes incremental updates to the slave database. The slave database then continuously applies these logs to achieve master-slave consistency.

[0044] Semi-sync: Semi-synchronous replication is a master-slave replication mode in MySQL. Its performance and reliability lie between fully synchronous and fully asynchronous replication. Unlike fully synchronous replication, semi-sync does not pursue real-time consistency of data visibility between the master and slave. Instead, it only ensures that log loss will not occur between the master and slave (that is, it guarantees eventual consistency of data visibility between the master and slave). By relaxing the consistency requirement, semi-sync improves master-slave replication performance.

[0045] Relay logs: In a binlog-based database master-slave synchronization solution, slaves (i.e., binlog receivers) can achieve asynchronous log reception and application through a strategy called relay logs. When receiving binlogs from the master, slaves can store the log streams in local files. The background log application thread continuously reads these local log files, achieving asynchronous log application. These local log files generated by the slaves are called relay logs.

[0046] Group commit: When a database performs a commit operation, it needs to write to the log file, and the log file needs to be written serially. In the scenario of large-scale concurrent writes, if each transaction performs a log write, the actual write speed will be slowed down to the speed of serial writes to the log file. Group commit is a performance optimization solution for the above problem. When a large number of concurrent writes are performed, the logs of multiple transactions submitted at almost the same time can be merged, so that this group of transactions only requires a single log write, thereby improving concurrency performance. In MySQL, each binlog group commit will select the transaction with the smallest transaction number in the group as the group leader, and this group leader is responsible for driving the entire commit process.

[0047] The present disclosure provides a database thread pool control method. Through dynamic runtime library injection, the database connection processing thread can be transparently replaced with a coroutine without the database's awareness. This ensures that the number of threads executing connection requests does not exceed the number of scheduled threads, thereby improving the concurrency performance of the database thread pool. FIG1 shows a process 100 of an embodiment of the database thread pool control method according to the present disclosure. The database thread pool control method includes the following steps:

[0048] Step 101: Load a dynamic runtime library capable of replacing threads with coroutines into the operating system of the database to generate at least one coroutine scheduling thread.

[0049] In this embodiment, the coroutine scheduling thread is used to schedule at least one coroutine.

[0050] In this embodiment, the dynamic runtime library is a runtime library that supports the operation of the database and can provide a programming interface for the interaction between the database and the operating system during operation.

[0051] In this embodiment, the dynamic runtime library is a dynamic runtime library that stores compiled functions. The dynamic runtime library provides an API interface to the database through these functions, and the database calls the functions in the dynamic runtime library through this API interface. Based on the native runtime library, the dynamic runtime library can be obtained by hooking the library functions related to thread scheduling in the native runtime library. After loading, the dynamic runtime library can have scheduling capabilities equivalent to threads.

[0052] In this embodiment, the C runtime library can be fully hooked to obtain a dynamic runtime library. The dynamic runtime library provides a runtime virtualization environment, and the database runs in the runtime virtualization environment to simulate the threads implemented in the native runtime library in a coroutine manner, thereby achieving the purpose of coroutine simulation of threads and scheduling coroutines through coroutine scheduling threads.

[0053] In this embodiment, loading the dynamic runtime library involves dynamically injecting the dynamic runtime library into the database when the operating system starts the database. Runtime injection of the dynamic runtime library involves loading a dynamic runtime library and running the initialization code within it before the operating system starts the database and loads the program into memory. This program loading method allows the pre-loaded dynamic runtime library to establish a runtime virtualization environment. Within this runtime virtualization environment, the database or operating system can call functions in the dynamic runtime library in real time. In this embodiment, after the database is started, the corresponding coroutine scheduling thread can be started.

[0054] In this embodiment, the coroutine scheduling thread includes: a scheduler and a lock-free queue for placing at least one coroutine. The specific steps of the coroutine scheduling thread scheduling at least one coroutine include: the scheduler obtains a coroutine in a ready state from the lock-free queue in at least one coroutine; synchronizes the coroutine context of the coroutine with the thread context in the thread control block; after the coroutine voluntarily gives up, the scheduler obtains the next coroutine in a ready state from the lock-free queue, and synchronizes the coroutine context of the next coroutine with the thread context in the thread control block; after the next coroutine voluntarily gives up, the scheduler continues to obtain coroutines from the lock-free queue and synchronize the thread control block until there is no coroutine in the lock-free queue.

[0055] In this embodiment, the thread control block (TCB) is a thread data structure within the native runtime library, known as a thread control block (TCB). It also serves as the thread context structure. DTV and specific array are the data structures within the TCB that store TLS data. DTV is used to store TLS variables defined during the coding phase. This data increments as new dynamic runtime libraries are loaded from the database, as TLS variables may also exist within the dynamic runtime library.

[0056] Specific: Dynamically created TLS (the library functions for creating and deleting TLS keys are pthread_key_create and pthread_key_delete, respectively; the library functions for reading and modifying TLS values ​​are pthread_getspecifix and pthread_setspecific, respectively). This type of TLS is maintained using a set of pointer arrays (specific arrays), so there is an upper limit on the number of dynamic TLS connections (Linux supports a maximum of 1024).

[0057] In this embodiment, when the database source code is open source, a dynamic runtime library is generated by directly modifying and recompiling the database source code. After loading the dynamic runtime library, the database can be operated in a new virtualized environment. Optionally, when the database supports plug-in development, the plug-in interface can be used to implement connection responses. When responding to a new connection, the connection management plug-in calls a hook function for creating a coroutine, thereby achieving the purpose of converting the connection thread to a coroutine. The hook function for creating a coroutine is injected when the database is started, and the plug-in can be loaded at any stage desired by the user.

[0058] Step 102: Receive a connection request sent by the client to the database.

[0059] In this embodiment, the connection request is a connection request sent by the client to the database after the dynamic runtime library is running.

[0060] In this embodiment, in order to separate the coroutine scheduling thread from other background threads of the database, when mounting the dynamic runtime library during the database startup phase, it is necessary to set the default thread creation mode through environment variables and set the default behavior to start the system native thread.

[0061] Step 103: Detect whether the request for the database to create a new thread is a request for processing a connection request.

[0062] In this embodiment, after loading the dynamic runtime library, the hook function in the dynamic runtime library directly replaces the connection manager module in the database. This hook function allows the database's newly created connection processing thread (session) to be directly converted into a coroutine. When loading the dynamic runtime library as a plug-in, the connection handler is replaced by mounting a thread pool plug-in. After the thread pool plug-in replaces the connection manager module, the newly created connection processing thread is directly converted into a coroutine by the thread pool plug-in. When uninstalling the thread pool plug-in, it is necessary to ensure that all coroutine-based connection processing threads are closed; otherwise, a "plug-in resource busy" error will be reported.

[0063] In this embodiment, the request to create a new thread is a thread creation request issued by the database. After receiving the client's connection request, the database will create a corresponding connection processing thread for each client connection. The request to create a connection processing thread is a request to create a new thread, that is, a request to create a new thread is issued to the application program interface of the dynamic runtime library. The execution subject on which the database thread pool control method of this embodiment runs can, after receiving the request to create a new thread as a request to process the connection request, construct a connection processing thread and establish a connection with the client through the constructed connection processing thread. Optionally, after receiving the request to create a new thread as a request to process the connection request, the execution subject can also use a coroutine to replace the constructed connection processing thread and establish a connection with the client by scheduling the execution of the coroutine through the coroutine scheduling thread.

[0064] Step 104 , in response to detecting that the database request to create a new thread is a request to process a connection request, create a coroutine corresponding to the connection request, and schedule the coroutine through at least one coroutine scheduling thread to complete the access task corresponding to the connection request.

[0065] In this embodiment, by injecting the dynamic runtime library and generating a coroutine scheduling thread, all threads in the database can be completely scheduled by the coroutine scheduling thread. At the same time, by utilizing the yieldability of the coroutine and the time-sharing multiplexing scheduling thread time slice properties, it can be ensured that the database will not have tasks "starved" or response time jitter caused by tasks being unable to be scheduled for a long time.

[0066] In this embodiment, the process of handling a user's connection processing thread (from connection creation to continuous SQL reception and execution, all the way to connection closing) is considered an access task. The coroutine created corresponding to the connection request is the carrier of this task. Coroutines can be continuously created in response to connection requests. The only constant is the coroutine scheduling thread. To this end, this disclosure requires a limited coroutine scheduling thread to schedule the continuously created coroutines.

[0067] As shown in Figure 2, a structural diagram of the database of the present invention is shown. In Figure 2, a method for creating a new connection in the database is: after receiving a thread construction request for processing the connection, the database connection processing thread is converted into a coroutine through the hook of the library function for creating a thread in the native runtime (such as the pthread_create() hook in Figure 2). The generated coroutine can be used to process the connection in the database, and the generated coroutine can be scheduled by multiple coroutine scheduling threads, achieving the effect of a database "thread pool". In this embodiment, the thread construction request for processing the connection is a request for the database to create a new thread to process the connection request. After the request is approved, the database can create a connection processing thread to process the client connection request, and the connection processing thread is the thread that processes the client connection request; further, through the hook function in the dynamic runtime, after having the thread construction request for processing the connection, a coroutine to replace the connection processing thread can be directly constructed.

[0068] The database thread pool control method provided by the embodiment of the present disclosure first loads a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database, generates at least one coroutine scheduling thread, and the coroutine scheduling thread is used to schedule at least one coroutine; secondly, receives a connection request sent by the client to the database; thirdly, detects whether the request for the database to create a new thread is a request to process the connection request; finally, in response to detecting that the request for the database to create a new thread is a request to process the connection request, creates a coroutine corresponding to the connection request, and schedules the coroutine through at least one coroutine scheduling thread to complete the access task corresponding to the connection request. Thus, the present disclosure transparently replaces the connection processing thread used to process the connection in the database with a coroutine through the injection of the dynamic runtime library. The created coroutine corresponding to the connection request runs in the form of a time-sharing call. When a time-consuming operation such as suspending and waiting occurs in a coroutine, the current coroutine scheduling thread can be actively given up, and the coroutine scheduling thread can be switched to another executable coroutine, which can solve the problems of increased delay of low-priority tasks and jitter of task response speed, thereby improving the concurrency performance of the database.

[0069] With respect to the above embodiment, by injecting and running the dynamic runtime library, all connection processing threads of the database can be converted into connection processing coroutines, and the connection processing coroutines are completely scheduled by the coroutine scheduling thread, realizing a thread model similar to the thread pool solution through the native runtime library. However, there are two different types of loads when the database is running. These loads can generally be divided into compute-intensive and IO-intensive. As shown in FIG3 , in a three-node MySQL database cluster with a one-master (Z) and two-slave (C1, C2) architecture, the time series of SQL execution on the master node includes: receiving SQL instructions -> executing SQL instructions -> writing the modified content to the binlog -> synchronizing the binlog increments to the two slave nodes -> completing SQL submission. Currently, most deployments of MySQL master-slave replication use MySQL cluster and high availability-semi-synchronous mode. In this mode, the process of the master-slave replication stage (for group submission (binlog group commit) when enabled, the process of the group leader is described below) is as follows:

[0070] 1) The master database writes the transaction to the binlog;

[0071] 2) The master database transfers the binlog to the slave database;

[0072] 3) The slave receives the binlog from the master, writes its contents to the relay log (receiving the relay log in Figure 3), and then sends a confirmation response to the master.

[0073] 4) The master database waits for the confirmation character response from the slave database until all slave databases have responded;

[0074] 5) The master database completes the transaction commit and returns "commit OK" to the client.

[0075] A MySQL connection processing coroutine (obtained by coroutine conversion from a connection processing thread) repeats the above process repeatedly to execute SQL statements initiated by the client. The entire process shows that only the SQL instruction execution phase is compute-intensive, resulting in high CPU usage; the other phases involve initiating I / O or waiting for I / O completion, representing an I / O-intensive workload. While I / O-intensive workloads consume very little CPU, the frequent I / O waits trigger a large number of coroutine swaps. If I / O-intensive and compute-intensive workloads are executed on the same scheduling thread, the frequent swapping of the I / O-intensive workload will disrupt the scheduling rhythm of the compute-intensive tasks, increasing the scheduling burden and reducing overall performance. Because coroutines achieve simulated parallelism by time-sharing the scheduling thread's time slices, the scheduling thread's swapping in and out also consumes CPU time. Therefore, the more CPU time the scheduling thread spends swapping in and out, the less CPU time is available for computing tasks.

[0076] In this embodiment, after the dynamic runtime library is loaded, the management of threads in all databases converts all threads into coroutines by default. As a result, different types of coroutines (such as IO coroutines for master-slave replication, coroutines for receiving response signals, etc.) and different types of loads in database commands are scheduled by the same batch of coroutine scheduling threads, resulting in mixed scheduling of different types of coroutine loads. IO-intensive loads need to perform IO waiting in a swap-out / swap-in manner, which will disrupt the scheduling rhythm of compute-intensive loads and increase the burden on threads to handle coroutine swapping in and out.

[0077] In order to solve the above performance problems, the present disclosure provides another embodiment of a database thread pool control method, which includes the following steps: loading a dynamic runtime library capable of replacing threads with coroutines in the database operating system, generating at least one coroutine scheduling thread, and the coroutine scheduling thread is used to schedule at least one coroutine; dividing the at least one coroutine scheduling thread into an IO-intensive scheduling thread and a computing-intensive scheduling thread; receiving a connection request sent by a client to a database, detecting whether the connection request is a thread construction request for processing a connection; in response to detecting that the connection request is a thread construction request for processing a connection, creating a coroutine corresponding to the connection request, and detecting whether the coroutine corresponding to the connection request is A state between a first state and a second state, wherein the first state is a state in which the coroutine is waiting for a data packet to execute a database command, the data packet has arrived, and the coroutine needs to be awakened; the second state is a state in which the coroutine is located in a computationally intensive scheduling thread, and the coroutine initiates a specific write request for a specific file; if it is detected that the coroutine corresponding to the connection request is in a state between the first state and the second state, the computationally intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request; if it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, the IO intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request.

[0078] In this embodiment, the coroutine scheduling threads are divided into two groups: computation-intensive scheduling threads and IO-intensive scheduling threads. The computation-intensive scheduling threads are used to schedule the execution of computation-intensive loads, and the IO-intensive scheduling threads are used to schedule the execution of IO-intensive loads.

[0079] In this embodiment, at least one coroutine scheduling thread can be divided into an IO-intensive scheduling thread and a compute-intensive scheduling thread based on a preset division rule, wherein the preset division rule is: the ratio of the number of IO-intensive scheduling threads to the number of compute-intensive scheduling threads is a fixed value (such as 1:4). Optionally, the above-mentioned preset division rule can also be: determine the type of database, and based on the type of database, determine the ratio of the number of IO-intensive scheduling threads to the number of compute-intensive scheduling threads. For databases with more IO operations, the ratio of the number of IO-intensive scheduling threads can be set to a larger value in the setting of the division rule; for databases with more compute operations, the ratio of the number of compute-intensive scheduling threads can be set to a larger value through the setting of the division rule.

[0080] In this embodiment, the coroutine corresponding to the connection request is the coroutine that executes the connection request. This coroutine can be in different stages of executing the connection request, for example, receiving a database instruction, executing the database instruction, submitting the instruction processing results to other libraries, and returning the database instruction execution results to the client. The state between the first and second states belongs to the database instruction execution stage, which requires a large amount of computing operations. Migrating the coroutine to a compute-intensive scheduling thread for scheduling can achieve separation from I / O-intensive loads.

[0081] In this embodiment, the state between the first and second states defines the period between the point at which the operation waiting for a packet to execute a database command is about to be awakened and the point at which a specific write operation occurs on a specific file. When the packet arrives during the waiting for a packet to execute a database command, a computationally intensive scheduling thread is required to wake up the coroutine.

[0082] For MySQL databases, the state between the first and second states refers to the state where SQL request packet data has arrived and the I / O operation waiting for the SQL request packet is about to be awakened from the waiting state. By monitoring the state between the first and second states, the coroutine in this state can be migrated to a compute-intensive scheduling thread. When the coroutine resumes, it executes in the compute-intensive scheduling thread and begins processing the newly received SQL request packet.

[0083] Taking the MySQL database as an example, the working principle of the execution subject running on the database thread pool control method disclosed in the present invention is explained as follows:

[0084] 1) For a newly created connection, since handshake confirmation and connection context initialization work (i.e., the connection creation phase) need to be performed, several round-trip communications with the client are required during this period, which is an IO-intensive operation. Therefore, the connection processing coroutine corresponding to the new connection needs to be handled by an IO-intensive scheduling thread. The connection processing coroutine is placed in the IO-intensive scheduling thread, so that the IO-intensive scheduling thread schedules the coroutine corresponding to the new connection.

[0085] 2) Once the connection is established, the MySQL connection processing coroutine waits for the SQL command data packet sent by the client (MySQL implements this through polling). When the polling operation ends (i.e., a data packet is available for reception) and the connection processing coroutine is about to be awakened, it is migrated to the computationally intensive scheduling thread. During the SQL operation execution, the current coroutine remains in the computationally intensive scheduling thread.

[0086] 3) When the connection processing coroutine calls the write operation to start writing to the binlog file, it means that the connection processing coroutine has entered the master-slave synchronization and transaction commit phase (if binlog group commit is enabled, this coroutine is the "group leader"). At this time, before completing the submission of the write file I / O request and letting the coroutine enter the I / O wait state, the current connection processing coroutine is migrated to the I / O-intensive scheduling thread.

[0087] From binlog writing, binlog sending, ACK waiting, and transaction commit completion until new SQL commands are available, the current connection processing coroutine always remains in the I / O-intensive scheduling thread.

[0088] Based on the above process 1)-3), it is repeated until the connection processing thread exits, and the separation of IO-intensive load and computing-intensive load can be achieved.

[0089] In this embodiment, the logic for scheduling thread migration can be injected through the callback interface of the dynamic runtime library. The specific logic is as follows:

[0090] First, assume that 40 coroutine scheduling threads are started when the dynamic runtime library is mounted. Since IO-intensive tasks have a very low CPU usage, fewer threads are required. The 32 coroutine scheduling threads with IDs from 0 to 31 are classified as compute-intensive scheduling threads, and the 8 coroutine scheduling threads with IDs from 32 to 39 are classified as IO-intensive scheduling threads.

[0091] Secondly, when migrating coroutines to different coroutine scheduling threads, the thread pool plug-in needs to use a load balancing algorithm to balance the migrated coroutine scheduling threads to avoid load skew. Optionally, in the MySQL database, the hash value of the connection processing thread ID can be used as the selection factor for the scheduling thread to implement the load balancing algorithm.

[0092] Based on the above premise, the present disclosure only needs to implement a callback function for waking up the coroutine operation and a callback function for the write operation. These two callback functions can realize the coroutine group scheduling mechanism mentioned above.

[0093] When executing a file write operation, if the current coroutine is determined to be writing to a binlog file, its scheduling thread ID is set to a value between 32 and 39 (i.e., I / O intensive). Before waking up the coroutine, if it is determined that the coroutine is about to enter the SQL instruction execution phase, its scheduling thread ID is set to a value between 0 and 31.

[0094] The database thread pool control method provided by the embodiments of the present disclosure can divert IO-intensive scheduling loads to dedicated IO scheduling threads by dividing the coroutine scheduling threads into two groups, thereby reducing the scheduling resource consumption of compute-intensive scheduling threads and improving the concurrency performance of the database.

[0095] In some optional implementations disclosed, the above-mentioned loading of a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database to generate at least one coroutine scheduling thread includes: in response to the database being unable to modify the source code and not having a connection management plug-in mechanism, starting the database; loading and initializing the dynamic runtime library to generate at least one coroutine scheduling thread, the dynamic runtime library having a hook function for creating a thread, the hook function for creating a thread being used to replace the connection processing thread generated by the native runtime library of the database with a coroutine; when the database is initialized, overloading the hook function for creating a thread to determine whether the currently created thread is a connection processing thread through the hook function for creating a thread, and when the currently created thread is a connection processing thread, converting the connection processing thread into a coroutine.

[0096] In this embodiment, in the hook function of creating a thread, it is monitored whether the currently created thread is a connection processing thread. When the currently created thread is a connection processing thread, the thread descriptor is replaced by the coroutine context structure, and the currently running thread or coroutine is marked by a global variable with a thread local constraint. The thread local storage information in the coroutine context structure is managed by the synchronization management module. The synchronization management module is used to synchronize the thread local storage of the coroutine when the coroutine scheduling thread schedules the coroutine.

[0097] In this embodiment, the coroutine context structure (hereinafter referred to as the COCTX structure) is a structure for placing the coroutine context (hereinafter referred to as COCTX), which is used to maintain the context of the coroutine, and is similar to the role of the thread descriptor (or thread handle). In order to provide compatibility with thread behavior, it is necessary to hook the library functions for creating threads and obtaining thread descriptors in the native runtime library, and replace the thread descriptor with COCTX. Taking Linux as an example, its thread descriptor is called "TCB", and its implementation is a structure called "pthread". The calls to create threads and obtain thread descriptors in Linux are:

[0098] pthread_create: creates a thread and returns a thread descriptor. The value of this thread descriptor is the address of the TCB structure. In this embodiment, the hook for creating a thread function is replaced by a pointer to COCTX.

[0099] pthread_self: Get the descriptor of the current thread, also replaced by the COCTX pointer.

[0100] In this embodiment, a global TLS variable (a global variable with thread-local constraints) can be used to obtain the context of the current coroutine, which is declared as follows:

[0101] extern__thread COCTX*_current_coctx;

[0102] In this embodiment, COCTX has the following four types:

[0103] Coroutine COCTX: corresponds to an actual coroutine;

[0104] Global COCTX: The main thread's _current_coctx will be set to global COCTX, which will be created when the dynamic runtime library is just loaded;

[0105] Scheduler COCTX: Each coroutine scheduling thread (that is, the thread that runs the coroutine) will have a default COCTX. If no coroutine is in the ready state or there is an intermediate state between two coroutines, the current thread's _current_coctx will be set to scheduler COCTX;

[0106] Single COCTX: When a system native thread is created, a virtual COCTX is created for it.

[0107] As shown above, the hook function of pthread_self actually returns the value of _current_coctx. In the program, by judging the type of the current COCTX, you can know which thread is currently in which state.

[0108] In this embodiment, the contents stored in the COCTX structure include: coroutine stack and TLS. The dynamic runtime library allocates an independent stack for each coroutine, so that the behavior of a thread can be fully simulated (including the memory size allocated in the stack and the call stack depth).

[0109] If a coroutine fails to fully simulate the thread's TLS mechanism, it will be unable to securely access variables with TLS constraints. This embodiment implements TLS management encapsulation through a synchronization management module (hereinafter referred to as co_tls). The capabilities provided by co_tls are crucial for transparent thread simulation. For example, Linux stores two types of TLS in its TCB: dtv and specific.

[0110] The disclosed co_tls support for specifics: co_tls maintains a data structure similar to the specific arrays in the TCB. When a newly created coroutine is first swapped in, the specifics in the TCB of its scheduling thread are copied. Furthermore, the library functions for managing specifics need to be hooked. The Linux library functions listed above are similar, and Windows also has similar functions: TlsAlloc, TlsFree, TlsGetValue, and TlsSetValue.

[0111] The co_tls disclosed in the present invention supports dtv: Similarly, when a newly created coroutine is scheduled for execution for the first time, it is also necessary to copy the dtv in the TCB. However, unlike specific, the specific content in co_tls no longer needs to be synchronized with the TCB; but since other dynamic runtime libraries may be dynamically loaded at runtime, the dtv of co_tls needs to be incrementally synchronized with the dtv in the TCB. An incremental backup of the TCB dtv is stored in the scheduler COCTX to describe the incremental part of the dtv generated each time the dynamic runtime library is loaded. At the same time, it is necessary to hook the library function call for loading the dynamic runtime library (the library function is called dlopen in Linux, and corresponds to LoadLibrary in Windows). Taking Linux as an example, a data structure called "link_map" describes all dynamic runtime library information. Combining link_map and dtv incremental backup, the difference between the current coroutine and the dtv increment can be parsed. For the merging of dtv increments, a "lazy" synchronization solution is adopted, that is, it is determined whether dtv needs to be synchronized when the coroutine is about to be swapped in. If dlopen is called in a coroutine, it is necessary to identify _current_coctx as a coroutine type in the dlopen hook and immediately synchronize dtv for the current coroutine.

[0112] In this embodiment, by creating a hook function for a thread, a coroutine that is completely consistent with the thread capability can be simulated. The coroutine switching process is as follows: First, in the initial state of the coroutine scheduling thread, _current_coctx is scheduler COCTX; then, when a coroutine needs to be swapped in (resume), check whether there is a difference between the coroutine and the DTV incremental backup (if there is, synchronization is required), and after the difference synchronization is completed, _current_coctx is set as the context of the current coroutine; finally, when the coroutine requires to be swapped out, _current_coctx is restored to scheduler COCTX. The entire coroutine switching process is executed entirely in user mode, without the need for any form of interaction with the operating system, thereby maintaining the lightweight characteristics of the coroutine.

[0113] This embodiment implements pure user-mode coroutine TLS switching, maintaining the lightweight characteristics of coroutine switching while maintaining the cross-coroutine security of TLS (taking into account both high performance and "transparent" virtualization).

[0114] The method for generating a coroutine scheduling thread provided in this embodiment, when the database source code cannot be modified and does not have a connection management plug-in mechanism, injects a dynamic runtime library with a hook function for creating a thread into the started database. When the database is initialized, the hook function for creating a thread is overloaded, so that the hook function for creating a thread can intercept the request to create a connection processing thread and convert the connection processing thread into a coroutine. The method provided in this embodiment provides a reliable implementation method for converting a connection processing thread into a coroutine.

[0115] In some optional implementations disclosed, the above-mentioned loading of a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database and generating at least one coroutine scheduling thread includes: starting the database in response to the database having a connection management plug-in mechanism; loading and initializing the dynamic runtime library to generate at least one coroutine scheduling thread; initializing the database; loading and initializing the plug-in so that the plug-in receives a connection request sent to the database, and when the thread construction request of the database is a request for processing the connection request, controlling the operation of the hook function for creating a thread in the dynamic runtime library, the hook function for creating a thread is used to determine whether the currently created thread is a connection processing thread, and when the currently created thread is a connection processing thread, converting the connection processing thread into a coroutine.

[0116] In this embodiment, the connection management plug-in mechanism is a mechanism for extending the database function through plug-ins without modifying the database. It is also a solution that does not modify the database source code.

[0117] In this embodiment, the plug-in is a third-party device located in the database and the dynamic runtime library. The plug-in can call the application interface of the dynamic runtime library and the application interface of the database. The plug-in receives the connection request and the database thread establishment request by calling the database application interface, detects whether the database thread establishment request is a request for processing the connection request, and calls the application interface of the dynamic runtime library when the database thread establishment request is a request for processing the connection request. By calling the application interface of the dynamic runtime library, the hook function of creating the thread is activated, the hook function of creating the thread determines the connection processing thread, and converts the connection processing thread into a coroutine.

[0118] In this embodiment, the hook function for creating a thread is a function obtained by processing the function for creating a thread in the C library through the HOOK mechanism. The specific content of the hook function for creating a thread is as described in the above embodiment and will not be repeated here.

[0119] The method for generating a coroutine scheduling thread provided in this embodiment, when the database has a connection management plug-in mechanism, connects the plug-in, receives a connection request through the plug-in, and when the connection request is a thread construction request for user processing connection, calls the hook function of the creation thread of the dynamic runtime library to convert the connection processing thread into a coroutine. The method provided in this embodiment provides another reliable implementation method for converting the connection processing thread into a coroutine.

[0120] In some optional implementations of the present disclosure, if it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, the IO-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request, including: in response to the coroutine corresponding to the connection request being in the stage of creating a connection, the coroutine is placed in the current IO-intensive scheduling thread, and the current IO-intensive scheduling thread is determined based on a load balancing algorithm; in response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, and completing the submission of the IO request to write the specific file and before letting the coroutine enter IO waiting, the coroutine is migrated to the current IO-intensive scheduling thread.

[0121] In this embodiment, the writing operations of specific files and feature files may vary depending on the type of database. For example, for a MySQL database, the specific file is a binlog file; for an openGauss database, the specific file is an xlog file. For various specific files, various types of data have corresponding specific write operations.

[0122] The method for scheduling coroutines provided by this optional implementation method migrates the coroutine in the database to an IO-intensive scheduling thread when the coroutine is in the stage of creating a connection; migrates the coroutine to an IO-intensive scheduling thread when the coroutine is in a specific write operation on a specific file and completes the submission of the specific file IO request and before the coroutine enters IO waiting, thereby directing IO-intensive tasks to a dedicated IO scheduling thread, reducing the resource consumption of the computation-intensive scheduling thread and improving the concurrency performance of the database.

[0123] In some optional implementations of the present disclosure, when the database is a MySQL database, in response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, and before submitting the write IO request to the specific file and letting the coroutine enter IO waiting, migrating the coroutine to the current IO-intensive scheduling thread includes:

[0124] In response to the coroutine corresponding to the connection request being in the write operation on the binary log file and completing the submission of the write file IO request and before letting the coroutine enter the IO wait, the coroutine is migrated to the current IO intensive scheduling thread.

[0125] The method for migrating coroutines provided in this embodiment, when the database is a MySQL database, migrates the coroutines to the current IO-intensive scheduling thread based on the write operation of a specific binary log file in the MySQL database, providing a reliable implementation method for allocating coroutines in the MySQL database.

[0126] In some embodiments of the present disclosure, the above-mentioned database thread pool control method also includes: detecting whether there is a coroutine that drives batch submission in the IO-intensive scheduling thread; if there is a coroutine that drives batch submission in the IO-intensive scheduling thread, the coroutine awakened by the coroutine that drives batch submission is migrated to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which the coroutine awakened by the coroutine that drives batch submission is migrated is determined based on a load balancing algorithm.

[0127] In this embodiment, a coroutine wake-up callback function can be added to the dynamic runtime library. The callback function has corresponding judgment logic. The judgment logic is: if the coroutine that is executing the operation of waking up other coroutines is in an IO-intensive scheduling thread itself, the coroutine awakened by it also needs to be migrated to the IO-intensive scheduling thread.

[0128] The database thread pool control method provided in this embodiment can improve the efficiency of coroutine scheduling by migrating the coroutines awakened by the coroutines that drive batch submission to the current IO-intensive scheduling thread when there are coroutines that drive batch submission in the IO-intensive scheduling thread.

[0129] In some optional implementations of the present disclosure, the above-mentioned database is MySQL and a database with group submission enabled, and detecting whether there is a coroutine that drives batch submission in the IO-intensive scheduling thread includes: detecting whether there is a group leader coroutine that drives the group submission process for writing to the binary log file in the IO-intensive scheduling thread; if there is a coroutine that drives batch submission in the IO-intensive scheduling thread, migrating the coroutine awakened by the coroutine to the IO-intensive scheduling thread includes: if a group leader coroutine that writes to the binary log file is detected, migrating the group member coroutine awakened by the group leader coroutine to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which each group member coroutine is migrated is determined based on the load balancing algorithm.

[0130] In this embodiment, in IO-intensive tasks, only the group leader coroutine submitted by the binary log file group will wake up all other tasks in the submission group after receiving the confirmation message from the slave library; at this time, the awakened tasks must also be in the submitted state, and therefore need to be switched to the IO-intensive scheduling thread.

[0131] The method for migrating coroutines provided in this embodiment, when the database is a MySQL database, determines the group leader coroutine based on the write operation of a specific binary log file in the MySQL database, and migrates the group member coroutines awakened by the group leader coroutine to the current IO-intensive scheduling thread, providing a reliable implementation method for allocating group member coroutines of the MySQL database.

[0132] Further referring to FIG4 , as an implementation of the database thread pool control method shown in the above figures, the present disclosure provides an embodiment of a database thread pool control device. The device embodiment corresponds to the method embodiment shown in FIG1 , and the device can be specifically applied to various electronic devices.

[0133] As shown in FIG4 , an embodiment of the present disclosure provides a database thread pool control device 400, which includes: a loading unit 401, a receiving unit 402, a detecting unit 403, and a creating unit 404. The loading unit 401 can be configured to load a dynamic runtime library capable of replacing threads with coroutines into the database's operating system, generate at least one coroutine scheduling thread, and schedule at least one coroutine scheduling thread; the receiving unit 402 can be configured to receive a connection request sent by a client to the database; the detecting unit 403 can be configured to detect whether the database's request to create a new thread is a request to process a connection request; and the creating unit 404 can be configured to, in response to detecting that the database's request to create a new thread is a request to process a connection request, create a coroutine corresponding to the connection request, and schedule the coroutine through at least one coroutine scheduling thread to complete the access task corresponding to the connection request.

[0134] In this embodiment, in the database thread pool control device 400, the specific processing of the loading unit 401, the receiving unit 402, the detection unit 403, and the creation unit 404 and the technical effects brought about by them can refer to steps 101, 102, 103, and 104 in the corresponding embodiment of Figure 1 respectively.

[0135] In some embodiments, the above-mentioned loading unit 401 is configured to: start the database in response to the database being unable to modify the source code and not having a connection management plug-in mechanism; load and initialize the dynamic runtime library, generate at least one coroutine scheduling thread, the dynamic runtime library has a hook function for creating a thread, and the hook function for creating a thread is used to replace the connection processing thread generated by the native runtime library of the database with a coroutine; when the database is initialized, overload the hook function for creating a thread to determine whether the currently created thread is a connection processing thread through the hook function for creating a thread, and when the currently created thread is a connection processing thread, convert the connection processing thread into a coroutine.

[0136] In some embodiments, the above-mentioned loading unit 401 is configured to: start the database in response to the database having a connection management plug-in mechanism; load and initialize the dynamic runtime library to generate at least one coroutine scheduling thread; initialize the database; load and initialize the plug-in so that the plug-in receives the connection request sent to the database, and when the database thread construction request is a request for processing the connection request, control the operation of the hook function for creating a thread in the dynamic runtime library, and the hook function for creating a thread is used to determine whether the currently created thread is a connection processing thread, and when the currently created thread is a connection processing thread, convert the connection processing thread into a coroutine.

[0137] In some embodiments, the apparatus further includes: a division unit (not shown in the figure), the division unit being configured to divide at least one coroutine scheduling thread into an IO-intensive scheduling thread and a compute-intensive scheduling thread; the creation unit 404 being further configured to: detect whether the coroutine corresponding to the connection request is in a state between a first state and a second state, wherein the first state is a state in which the coroutine is waiting for a data packet to execute a database command, the data packet has arrived, and the coroutine needs to be awakened; the second state is a state in which the coroutine is in a compute-intensive scheduling thread, and the coroutine initiates a specific write request for a specific file; if it is detected that the coroutine corresponding to the connection request is in a state between the first state and the second state, the compute-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request; if it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, the IO-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request.

[0138] In some embodiments, the creation unit 404 is further configured to: in response to the coroutine corresponding to the connection request being in the stage of creating a connection, place the coroutine on the current IO-intensive scheduling thread, which is determined based on a load balancing algorithm; in response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, and completing the submission of the IO request to write the specific file and before letting the coroutine enter IO waiting, migrate the coroutine to the current IO-intensive scheduling thread.

[0139] In some embodiments, the database is a MySQL database, and the construction unit 404 is further configured to: in response to the coroutine corresponding to the connection request being in the writing operation of the binary log file, and completing the submission of the write file IO request and before letting the coroutine enter IO waiting, migrate the coroutine to the current IO intensive scheduling thread.

[0140] In some embodiments, the above-mentioned device also includes: a batch drive unit (not shown in the figure), and the above-mentioned batch drive unit is configured to: detect whether there is a coroutine that drives batch submission in the IO-intensive scheduling thread; if there is a coroutine that drives batch submission in the IO-intensive scheduling thread, the coroutine awakened by the coroutine that drives batch submission is migrated to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which the coroutine awakened by the coroutine that drives batch submission is migrated is determined based on the load balancing algorithm.

[0141] In some embodiments, the above-mentioned database is MySQL and a database with group submission enabled, and the above-mentioned batch drive unit is further configured to: detect whether there is a leader coroutine in the IO-intensive scheduling thread that drives the group submission process for writing to the binary log file; if a group leader coroutine that writes to the binary log file is detected, the group member coroutines awakened by the group leader coroutine are migrated to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which each group member coroutine is migrated is determined based on the load balancing algorithm.

[0142] The database thread pool control device provided by the embodiment of the present disclosure includes: first, a loading unit 401 loads a dynamic runtime library capable of replacing a thread with a coroutine in the operating system of the database, generates at least one coroutine scheduling thread, and the coroutine scheduling thread is used to schedule at least one coroutine; second, a receiving unit 402 receives a connection request sent by a client to the database; third, a detection unit 403 detects whether the request for the database to create a new thread is a request to process a connection request; finally, a creation unit 404, in response to detecting that the request for the database to create a new thread is a request to process a connection request, creates a coroutine corresponding to the connection request, and schedules the coroutine through at least one coroutine scheduling thread to complete the access task corresponding to the connection request. Thus, the present disclosure transparently replaces the connection processing thread used to process the connection in the database with a coroutine through the injection of the dynamic runtime library. The created coroutine corresponding to the connection request runs in the form of a time-sharing call. When a time-consuming operation such as suspending and waiting occurs in a coroutine, the current coroutine scheduling thread can be actively given up and replaced by another executable coroutine by the coroutine scheduling thread, which can solve the problems of increased delay of low-priority tasks and jitter of task response speed, thereby improving the concurrency performance of the database.

[0143] 5 , which shows a schematic structural diagram of an electronic device 500 suitable for implementing the embodiments of the present disclosure.

[0144] As shown in Figure 5, the electronic device 500 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. Various programs and data required for the operation of the electronic device 500 are also stored in the RAM 503. The processing device 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0145] Typically, the following devices can be connected to the I / O interface 505: an input device 506 including, for example, a touch screen, a touchpad, a keyboard, a mouse, etc.; an output device 507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 508 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 509. The communication device 509 can allow the electronic device 500 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 5 shows an electronic device 500 with various devices, it should be understood that it is not required to implement or have all the devices shown. More or fewer devices may be implemented or have alternatively. Each box shown in Figure 5 may represent one device, or may represent multiple devices as needed.

[0146] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network via the communication device 509, or installed from the storage device 508, or installed from the ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the method of the embodiment of the present disclosure are performed.

[0147] It should be noted that the computer-readable medium of the embodiments of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the embodiments of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or component. In the embodiments of the present disclosure, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or convey a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code embodied on the computer-readable medium may be conveyed using any suitable medium, including but not limited to wires, optical cables, RF (Radio Frequency), or any suitable combination thereof.

[0148] The computer-readable medium may be included in the server, or may exist independently without being incorporated into the server. The computer-readable medium carries one or more programs. When executed by the server, the server: loads a dynamic runtime library capable of replacing threads with coroutines into the database's operating system, generates at least one coroutine scheduling thread, and the coroutine scheduling thread is used to schedule at least one coroutine; receives a connection request sent by a client to the database; detects whether the database's request to create a new thread is a request to process the connection request; in response to detecting that the database's request to create a new thread is a request to process the connection request, creates a coroutine corresponding to the connection request, and schedules the coroutine through at least one coroutine scheduling thread to complete the access task corresponding to the connection request.

[0149] Computer program code for performing the operations of embodiments of the present disclosure may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0150] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to the various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0151] The units involved in the embodiments described in the present disclosure can be implemented by software or by hardware. The described units can also be set in a processor. For example, they can be described as: a processor including a loading unit, a receiving unit, a detection unit, and a creation unit. In some cases, the names of these units do not constitute a limitation on the unit itself. For example, the loading unit can also be described as a unit "configured to load a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database, and generate at least one coroutine scheduling thread."

[0152] The above description is merely a preferred embodiment of the present disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present disclosure is not limited to the technical solutions formed by a specific combination of the above-mentioned technical features, but should also encompass other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned inventive concept. For example, a technical solution formed by mutually replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A database thread pool control method, the method comprising: Loading a dynamic runtime library capable of replacing a thread with a coroutine in an operating system of the database, generating at least one coroutine scheduling thread, wherein the coroutine scheduling thread is used to schedule at least one coroutine; Receiving a connection request sent by a client to the database; Detecting whether the request of the database to create a new thread is a request to process the connection request; In response to detecting that the database requests to create a new thread for processing the connection request, a coroutine corresponding to the connection request is created, and the coroutine is scheduled by the at least one coroutine scheduling thread to complete an access task corresponding to the connection request.

2. The method according to claim 1, wherein: The step of loading a dynamic runtime library capable of replacing a thread with a coroutine in the operating system of the database to generate at least one coroutine scheduling thread includes: In response to the database being unable to modify source code and not having a connection management plug-in mechanism, starting the database; Loading and initializing a dynamic runtime library to generate at least one coroutine scheduling thread, wherein the dynamic runtime library has a hook function for creating a thread, and the hook function for creating a thread is used to replace a connection processing thread generated by a native runtime library of the database with a coroutine; When the database is initialized, the hook function of the thread creation is overloaded to determine whether the currently created thread is a connection processing thread through the hook function of the thread creation. When the currently created thread is a connection processing thread, the connection processing thread is converted into a coroutine.

3. The method according to claim 1, wherein: The step of loading a dynamic runtime library capable of replacing a thread with a coroutine in the operating system of the database to generate at least one coroutine scheduling thread includes: In response to the database having a connection management plug-in mechanism, starting the database; Load and initialize the dynamic runtime library and generate at least one coroutine scheduling thread; Initializing the database; A plug-in is loaded and initialized so that the plug-in receives a connection request sent to the database, and when the thread construction request of the database is a request for processing the connection request, the plug-in controls the operation of a hook function for creating a thread in the dynamic runtime library, wherein the hook function for creating a thread is used to determine whether the currently created thread is a connection processing thread, and when the currently created thread is a connection processing thread, the connection processing thread is converted into a coroutine.

4. The method according to any one of claims 1 to 3, wherein: The method further comprises: Dividing the at least one coroutine scheduling thread into an IO-intensive scheduling thread and a computation-intensive scheduling thread; The step of scheduling the coroutine by the at least one coroutine scheduling thread to complete the access task corresponding to the connection request includes: Detecting whether the coroutine corresponding to the connection request is in a state between a first state and a second state, wherein the first state is a state in which the coroutine is waiting for a data packet to execute a database command, the data packet has arrived, and the coroutine needs to be awakened; the second state is a state in which the coroutine is in a computationally intensive scheduling thread, and the coroutine initiates a specific write request for a specific file; If it is detected that the coroutine corresponding to the connection request is in a state between the first state and the second state, a computationally intensive scheduling thread in the at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request; If it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, an IO-intensive scheduling thread in the at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request.

5. The method according to claim 4, wherein: If it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, using the IO-intensive scheduling thread in the at least one coroutine scheduling thread to schedule the coroutine corresponding to the connection request includes: In response to the coroutine corresponding to the connection request being in a stage of creating a connection, placing the coroutine in a current IO-intensive scheduling thread, where the current IO-intensive scheduling thread is determined based on a load balancing algorithm; In response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, completing submission of the write specific file IO request and before letting the coroutine enter IO waiting, the coroutine is migrated to the current IO intensive scheduling thread.

6. The method according to claim 5, wherein: The database is a MySQL database, and in response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, and completing submission of the write specific file IO request and before letting the coroutine enter IO waiting, migrating the coroutine to the current IO intensive scheduling thread includes: In response to the coroutine corresponding to the connection request being in the write operation to the binary log file, and completing the submission of the write file IO request and before letting the coroutine enter the IO wait, the coroutine is migrated to the current IO intensive scheduling thread.

7. The method according to claim 5, wherein: The method further comprises: Detect whether there is a coroutine driving batch submission in the IO-intensive scheduling thread; If the IO-intensive scheduling thread contains coroutines submitted by the driver in batches, the coroutines awakened by the coroutines submitted by the driver in batches are migrated to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which the coroutines awakened by the coroutines submitted by the driver in batches are migrated is determined based on the load balancing algorithm.

8. The method according to claim 7, wherein: The database is MySQL and a group submission database is enabled, and the detecting whether there is a coroutine driving batch submission in the IO-intensive scheduling thread includes: Detect whether there is a group leader coroutine of a driving group submission process for writing a binary log file in the IO-intensive scheduling thread; The IO-intensive scheduling thread has a coroutine for driving batch submission, and the coroutine awakened by the coroutine is migrated to the IO-intensive scheduling thread, including: If a group leader coroutine that writes to a binary log file is detected, the group member coroutines awakened by the group leader coroutine are migrated to an IO-intensive scheduling thread. The IO-intensive scheduling thread to which each group member coroutine is migrated is determined based on a load balancing algorithm.

9. A database thread pool control device, the device comprising: A loading unit is configured to load a dynamic runtime library capable of replacing a thread with a coroutine in an operating system of the database, and generate at least one coroutine scheduling thread, wherein the coroutine scheduling thread is used to schedule at least one coroutine; A receiving unit, configured to receive a connection request sent by a client to the database; a detection unit configured to detect whether the request of the database to create a new thread is a request to process the connection request; The creation unit is configured to, in response to detecting a request from the database to create a new thread to process the connection request, create a coroutine corresponding to the connection request, and schedule the coroutine through the at least one coroutine scheduling thread to complete an access task corresponding to the connection request.

10. The device according to claim 9, wherein: The loading unit is further configured to: In response to the database being unable to modify source code and not having a connection management plug-in mechanism, starting the database; Load and initialize the dynamic runtime library, generate at least one coroutine scheduling thread, the dynamic runtime library has a hook function for creating a thread, and the hook function for creating a thread is used to replace the connection processing thread generated by the native runtime library of the database with a coroutine; When the database is initialized, the hook function of the thread creation is overloaded to determine whether the currently created thread is a connection processing thread through the hook function of the thread creation. When the currently created thread is a connection processing thread, the connection processing thread is converted into a coroutine.

11. The device according to claim 9, wherein: The loading unit is further configured to: In response to the database having a connection management plug-in mechanism, starting the database; Load and initialize the dynamic runtime library and generate at least one coroutine scheduling thread; Initialize the database; Load and initialize the plug-in so that the plug-in receives the connection request sent to the database, and when the database thread construction request is a request for processing the connection request, the hook function of creating a thread in the dynamic runtime library is controlled to work. The hook function of creating a thread is used to determine whether the currently created thread is a connection processing thread. When the currently created thread is a connection processing thread, the connection processing thread is converted into a coroutine.

12. The device according to any one of claims 9 to 10, wherein: The device also includes: A partitioning unit, configured to partition at least one coroutine scheduling thread into an IO-intensive scheduling thread and a computation-intensive scheduling thread; The creation unit is further configured to: detect whether the coroutine corresponding to the connection request is in a state between a first state and a second state, wherein the first state is a state in which the coroutine is waiting for a data packet to execute a database command, the data packet has arrived, and the coroutine needs to be awakened; the second state is a state in which the coroutine is located in a computationally intensive scheduling thread, and the coroutine initiates a specific write request for a specific file; if it is detected that the coroutine corresponding to the connection request is in a state between the first state and the second state, a computationally intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request; if it is detected that the coroutine corresponding to the connection request is not in a state between the first state and the second state, an IO-intensive scheduling thread in at least one coroutine scheduling thread is used to schedule the coroutine corresponding to the connection request.

13. The device according to claim 12, wherein: The creation unit is further configured to: In response to the coroutine corresponding to the connection request being in a stage of creating a connection, placing the coroutine in a current IO-intensive scheduling thread, the current IO-intensive scheduling thread being determined based on a load balancing algorithm; In response to the coroutine corresponding to the connection request being in a specific write operation on a specific file, and completing submission of the write specific file IO request and before letting the coroutine enter IO waiting, the coroutine is migrated to the current IO intensive scheduling thread.

14. The device according to claim 13, wherein: The database is a MySQL database, and the construction unit is further configured to: in response to the coroutine corresponding to the connection request being in a write operation on a binary log file, and completing the submission of the write file IO request and before letting the coroutine enter IO waiting, migrate the coroutine to the current IO intensive scheduling thread.

15. The device according to claim 13, wherein: The device also includes: The batch drive unit is configured to: detect whether there is a coroutine submitted by the driver in batches in the IO-intensive scheduling thread; if there is a coroutine submitted by the driver in batches in the IO-intensive scheduling thread, migrate the coroutine awakened by the coroutine submitted by the driver in batches to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which the coroutine awakened by the coroutine submitted by the driver in batches is migrated is determined based on the load balancing algorithm.

16. The device according to claim 15, wherein: The database is MySQL and a group submission database is enabled, and the batch drive unit is further configured to: Detect whether there is a leader coroutine of the driver group submission process that writes to the binary log file in the IO-intensive scheduling thread; If a group leader coroutine that writes to a binary log file is detected, the group member coroutines awakened by the group leader coroutine are migrated to an IO-intensive scheduling thread. The IO-intensive scheduling thread to which each group member coroutine is migrated is determined based on a load balancing algorithm.

17. An electronic device comprising: one or more processors; a storage device having one or more computer programs stored thereon; When the one or more computer programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 8.

18. A non-transitory computer readable medium having a computer program stored thereon, wherein: When the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images