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

Abstract

The invention provides a database thread pool control method and device. A specific embodiment of the method comprises the steps of loading a dynamic runtime library capable of replacing a thread with a coroutine in an operating system of a database, and generating at least one coroutine scheduling thread; receiving a connection request sent by the client to the database; detecting whether the request of the database for creating the new thread 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 a request for processing 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. According to the implementation mode, the coroutine scheduling thread serves as a working thread of a database thread pool, the problem of task starvation of a traditional multi-thread scheduling model and the problem of related task response speed jitter are avoided through a coroutine swap-in and swap-out mechanism, the concurrency performance of a database is improved, and meanwhile resource consumption of concurrency scheduling is reduced.

Description

Technical Field

[0001] 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

[0002] The default concurrent connection model of the MySQL database adopts "one thread one connection", that is, a thread is created for each connection. A major drawback of this database is that in high-concurrency scenarios, frequent creation / destruction of threads will cause the database to freeze or crash. In addition, even if the long connection mode is used, a large number of threads will greatly increase the task scheduling burden.

[0003] To solve the above problems, some databases have introduced thread pool solutions. The purpose of thread pool technology is to use a fixed number of threads to process tasks that are far higher than the number of threads in the thread pool through round-robin response, thereby reducing scheduling contention and reducing resource utilization. However, in this mode, if all tasks are at the same priority, then some tasks that need to be completed urgently will have a high delay when the task execution time is generally long. Therefore, some thread pools introduce high-priority queues. However, when there are many tasks in the high-priority queue or the execution time is generally long, the delay of low-priority tasks will be further aggravated. In extreme cases, some tasks will never be responded to, which is called the "starvation" phenomenon. Summary of the invention

[0004] The embodiments of the present disclosure provide a database thread pool control method and device, an electronic device, and a computer-readable medium.

[0005] 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 operating system of the database, 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.

[0006] 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 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.

[0007] 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 to generate at least one coroutine scheduling thread includes: in response to the database 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; 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 of creating a thread in the dynamic runtime library, the hook function of 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.

[0008] 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 a 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 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 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.

[0009] 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 to 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.

[0010] In some embodiments, the database is a MySQL database, and the 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 file IO request and letting the coroutine enter IO wait, migrating the coroutine to the current IO intensive scheduling thread includes: in response 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.

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

[0012] In some embodiments, the above-mentioned database is MySQL and a database with group submission enabled. The above-mentioned detection of whether there is a coroutine driving batch submission in the IO-intensive scheduling thread includes: detecting whether there is a group leader coroutine driving the group submission process that writes to the binary log file in the IO-intensive scheduling thread; the IO-intensive scheduling thread has a coroutine 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 the binary log file is detected, the group member coroutine awakened by the group leader coroutine is 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.

[0013] 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 a thread with a coroutine in the operating system of the database, and generate at least one coroutine scheduling thread, the coroutine scheduling thread being 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 a request for a database to create a new thread is a request for processing a connection request; a creation unit, configured to create a coroutine corresponding to the connection request in response to detecting that the request for a database to create a new thread is a request for processing a connection request, and schedule the coroutine through at least one coroutine scheduling thread to complete an access task corresponding to the connection request.

[0014] In some embodiments, the 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 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, 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.

[0015] In some embodiments, the 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 a connection request sent to the database, and when the database thread construction request is a request for processing the connection request, control the hook function of creating a thread in the dynamic runtime library to work, and the hook function of 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.

[0016] 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 located 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.

[0017] In some embodiments, the 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 in 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 write specific file IO request and before letting the coroutine enter IO waiting, migrate the coroutine to the current IO-intensive scheduling thread.

[0018] 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 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] The database thread pool control method and device provided by the embodiment of the present disclosure, first, load a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database, generate at least one coroutine scheduling thread, and the coroutine scheduling thread is used to schedule at least one coroutine; secondly, receive a connection request sent by the client to the database; thirdly, detect whether the request for the database to create a new thread is a request for processing the connection request; finally, in response to detecting that the request for the database to create a new thread is a request for processing the 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. 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, and the created coroutine corresponding to the connection request runs in the form of 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 replaced by another executable coroutine, which can solve the problem of increased delay of low-priority tasks and jitter of task response speed, and improve the concurrency performance of the database. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0025] Figure 1 is a flowchart of an embodiment of a database thread pool control method according to the present disclosure;

[0026] Figure 2is a schematic diagram of a database structure disclosed in the present invention;

[0027] Figure 3 is a flowchart of another embodiment of a database thread pool control method according to the present disclosure;

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

[0029] Figure 5 It is a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present disclosure. DETAILED DESCRIPTION

[0030] The present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It is also necessary to explain that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.

[0031] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of 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.

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

[0033] When the thread pool is enabled, client connections will be placed in different priority queues according to the task priority policy settings and the type of SQL instructions to be executed. When there are tasks in the high priority queue, tasks in the low priority queue will not be executed.

[0034] In general, when there are tasks to be executed in the task queue but there are no idle worker threads, new worker threads will be 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 by the entire thread pool; when a worker thread is idle for longer than the time set by the parameter "thread_pool_idle_timeout", it will automatically exit.

[0035] However, if the execution time of the tasks being scheduled is generally long, and at the same time the number of worker threads has reached the upper limit; then the tasks in the task queue will not be scheduled for execution for a long time. Another similar situation is that when a large number of tasks continue to flow into the high-priority task queue, the tasks in the low-priority queue will also not be executed for a long time. This situation is a common phenomenon in concurrent task scheduling, and is figuratively called task "starvation".

[0036] 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 a connection through an "extra port". However, if the excessive use of threads exceeding the limit 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 if 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 an overlimit thread), thereby causing severe jitter in the SQL response speed.

[0037] The core problem of the above "starvation" phenomenon is that a SQL that runs for a long time, or a SQL that is in a waiting state for a long time (such as thread suspension caused by lock waiting), cannot be swapped out from the thread currently running this SQL before the SQL is executed. In other words, even if the working thread is in a suspended (lock waiting) state during the execution of a SQL, it cannot be reused to schedule other SQL tasks; if you want to execute other SQLs at the same time, you can only use other threads.

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

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

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

[0041] Thread pool: As the name implies, a thread pool is to create several executable threads in advance and put them into a pool (container). When a task needs to be executed, instead of creating a new thread for the task, the thread already created in the thread pool is used. Through the above solution, the number of thread creation and destruction is reduced, the scheduling burden is reduced, and the system performance is improved.

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

[0043] Semi-sync: Semi-synchronous replication is a master-slave replication mode of MySQL. Its performance and reliability are between full synchronous replication and full asynchronous replication. Unlike full synchronous replication, semi-sync does not pursue real-time consistency of data visibility between the master and the slave, but only ensures that there will be no log loss between the master and the slave (that is, to ensure the final consistency of data visibility between the master and the slave). By weakening the consistency requirement, the purpose of improving the performance of master-slave replication is achieved.

[0044] Relay log: In the master-slave synchronization solution of the database based on binlog, the slave library (i.e., the binlog receiver) can achieve asynchronous log reception and application through a strategy called "relay log". When the slave library receives the binlog sent by the master library, it can land the log stream into a local file; and the background log application thread can realize asynchronous log application by continuously reading these local log files. The local log file generated by the slave library is called a "relay log".

[0045] Group commit: When the database performs a commit operation, it needs to write a log, and the log file needs to be written serially. In the scenario of large-scale concurrent writes, if each transaction writes a log once, 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 there is a large amount of concurrent writes, the logs of multiple transactions that are committed almost at the same time can be merged, so that this group of transactions only needs one log write, thereby improving concurrent 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.

[0046] The present disclosure provides a database thread pool control method, which can transparently replace the database connection processing thread with a coroutine through dynamic runtime library injection without the database being aware of it, and can ensure that the number of threads executing connection requests will not exceed the number of scheduled threads, thereby improving the concurrency performance of the database thread pool. Figure 1 , shows a process 100 of an embodiment of a database thread pool control method according to the present disclosure, the database thread pool control method comprising the following steps:

[0047] Step 101: 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.

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

[0049] 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.

[0050] In this embodiment, the dynamic runtime is a dynamic runtime, in which the compiled functions are stored, and the dynamic runtime provides an API interface to the database through the functions, and the database calls the functions in the dynamic runtime through the API interface. Based on the native runtime, the dynamic runtime can be obtained by hooking the library functions related to thread scheduling in the native runtime, and after loading, the obtained dynamic runtime can have the scheduling capability equivalent to that of a thread.

[0051] 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. The database runs under 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 threads and scheduling coroutines through coroutine scheduling threads.

[0052] In this embodiment, loading the dynamic runtime library means dynamically injecting the dynamic runtime library into the database when the operating system starts the database, and the runtime injection of the dynamic runtime library means loading a certain dynamic runtime library before the operating system starts a database and loads the program into the memory, and running the initialization code in the dynamic runtime library. Through this program loading method, the pre-loaded dynamic runtime library has the opportunity to build a runtime virtualization environment in advance. In the runtime virtualization environment, the database or operating system can call the function in the dynamic runtime library in real time. In this embodiment, after the database is started, the coroutine scheduling thread can be started accordingly.

[0053] In this embodiment, the coroutine scheduling thread includes: a scheduler and a lock-free queue for placing at least one coroutine, and 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 actively 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 actively 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.

[0054] In this embodiment, the thread control block is the data structure of the thread in the native runtime, called the "thread control block" (TCB), which is the context structure of the thread. dtv and specific array are the data structures that store TLS data in the TCB. dtv: used to store TLS variables defined in the encoding phase. This data will be incremented as the database loads a new dynamic runtime, because there may also be TLS variables in the dynamic runtime.

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

[0056] In this embodiment, when the source code of the database is open source code, the dynamic runtime library is obtained by directly modifying and recompiling the source code of the database. After loading the dynamic runtime library, the database can be run in a new virtualized environment. Optionally, when the database supports plug-in development, the plug-in interface of the plug-in can be used to implement the connection response. When the connection management plug-in responds to the new connection, the hook function of creating a coroutine is called to achieve the purpose of connecting the thread to the coroutine. The hook function of creating a coroutine is injected when the database is started, and the timing of loading the plug-in can be at any stage desired by the user.

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

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

[0059] 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.

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

[0061] In this embodiment, after loading the dynamic runtime, the hook function in the dynamic runtime directly replaces the connection manager module (connection handler) in the database. The hook function can directly convert the newly created connection processing thread (session) of the database into a coroutine. When the dynamic runtime is loaded in the form of a plug-in, the connection processing program is replaced by mounting the thread pool plug-in, and after the thread pool plug-in replaces the connection manager module, the newly created connection processing thread of the data 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 is busy" error will be reported.

[0062] In this embodiment, the request to create a new thread is a request to create a thread issued by the database. After receiving the connection request from the client, the database will create a corresponding connection processing thread for each client connection, and 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 build a connection processing thread after obtaining that the request to create a new thread is a request to process the connection request, and establish a connection with the client through the built connection processing thread. Optionally, the execution subject can also use a coroutine to replace the built connection processing thread after obtaining that the request to create a new thread is a request to process the connection request, and establish a connection with the client by scheduling the execution of the coroutine through the coroutine scheduling thread.

[0063] Step 104, in response to detecting that the request for creating a new thread by the database is a request for processing a 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.

[0064] 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 nature of the time slice of the time-sharing scheduling thread, it can be ensured that the database will not have tasks "starved to death" or response time jitter problems caused by the inability to schedule tasks for a long time.

[0065] In this embodiment, the process of processing a user's connection processing thread (from connection creation to continuous receiving and executing SQL until the connection is closed) is regarded as an access task, and the coroutine created corresponding to the connection request is the carrier of this task. Coroutines can be continuously created for connection requests, and the only constant is the coroutine scheduling thread. For this reason, the present disclosure needs to schedule the continuously created coroutines through a limited coroutine scheduling thread.

[0066] like Figure 2 As shown, a schematic diagram of the structure of the disclosed database is shown. Figure 2 In the example, a new connection is created in the database as follows: after receiving a thread construction request for processing the connection, the library function for creating a thread in the native runtime is hooked (such as Figure 2 The pthread_create() hook in the dynamic runtime library converts the database connection processing thread into a coroutine. 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 for processing the connection request. After the request is approved, the database can create a connection processing thread for processing the client connection request, and the connection processing thread is a thread for processing the client connection request. Furthermore, through the hook function in the dynamic runtime library, a coroutine that replaces the connection processing thread can be directly constructed after there is a thread construction request for processing the connection.

[0067] The database thread pool control method provided by the embodiment of the present disclosure firstly 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 a client to the database; thirdly, detects whether the request for the database to create a new thread is a request for processing a connection request; finally, in response to detecting that the request for the database to create a new thread is a request for processing 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, and the created coroutine corresponding to the connection request runs in the form of 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 is replaced by another executable coroutine, which can solve the problem of increased delay of low-priority tasks and jitter of task response speed, and improve the concurrency performance of the database.

[0068] 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, which can generally be divided into computationally intensive and IO intensive, such as Figure 3 As shown in the figure, in a three-node MySQL database cluster with one master (Z) and two slaves (C1, C2) architecture, the time series of SQL execution on the master node includes: receiving SQL instructions -> executing SQL instructions -> writing modified content to binlog -> synchronizing binlog increments to 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) enabled, the following describes the process of the group leader) steps are as follows:

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

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

[0071] 3) The slave receives the binlog from the master and writes its contents to the relay log ( Figure 3 Receive relay logs in the master database), and then send a confirmation response to the master database;

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

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

[0074] A MySQL connection processing coroutine (obtained by coroutine conversion of the connection processing thread) will repeat the above process over and over again to execute the SQL statement initiated by the client. From the whole process, it can be seen that only the SQL instruction execution stage is computationally intensive, and the CPU occupancy rate is high at this time; the other stages are to initiate IO or wait for IO completion, that is, IO-intensive load. Although the IO-intensive load itself consumes very little CPU, it needs to trigger a large number of coroutine swap-in and swap-out actions due to the need for frequent IO waiting. If the IO-intensive load and the computation-intensive load are put into the same group of scheduling threads for execution, the frequent swap-in and swap-out actions of the IO-intensive load will disrupt the scheduling rhythm of the computation-intensive tasks, increase the scheduling burden, and reduce the overall performance. Because the coroutine relies on the time slice of the time-sharing multiplexing scheduling thread to achieve simulated parallelism, the scheduling thread also consumes CPU time to process swap-in and swap-out; therefore, the more CPU time the scheduling thread consumes on swap-in and swap-out, the less CPU time is used to execute computing tasks.

[0075] In this embodiment, after the dynamic runtime is loaded, the management of threads in all databases converts all threads into coroutines by default, resulting in different types of coroutines (such as IO coroutines of master-slave replication, coroutines for receiving response signals, etc.) and different types of loads in database commands being 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 disrupts the scheduling rhythm of compute-intensive loads and increases the burden of threads processing coroutine swap-ins.

[0076] To solve the above performance problem, 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, the coroutine scheduling thread being 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 building request for processing a connection; in response to detecting that the connection request is a thread building request for processing a connection, creating a coroutine corresponding to the connection request, 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 a 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.

[0077] 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.

[0078] 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 determine the ratio of the number of IO-intensive scheduling threads to the number of compute-intensive scheduling threads based on the type of database. 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 rules; 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 rules.

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

[0080] In this embodiment, the state between the first state and the second state is used to define the stage from the point where the operation of the data packet waiting for the execution of the database command is about to be awakened to the point where the specific write operation occurs to the specific file. In the state of waiting for the data packet for the execution of the database command, the data packet has arrived and when the coroutine is about to be awakened, a computationally intensive scheduling thread needs to be put into place.

[0081] For MySQL database, the state between the first state and the second state refers to the state where the data of the SQL request packet has arrived and the IO operation waiting for the SQL request packet is about to be awakened from the waiting state. By monitoring the state between the first state and the second state, the coroutine in this state can be migrated to the computationally intensive scheduling thread. When the coroutine resumes, it is executed in the computationally intensive scheduling thread and starts to process the SQL request packet that has just been received.

[0082] 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:

[0083] 1) For the newly created connection, since handshake confirmation and connection context initialization (i.e., the connection creation phase) need to be performed, it is necessary to communicate back and forth with the client several times during the process, which is an IO-intensive operation. Therefore, the connection processing coroutine corresponding to the new connection needs to be handled by the 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.

[0084] 2) After the connection is established, the MySQL connection processing coroutine needs to wait for the receiving operation to receive the SQL command data packet sent by the client (MySQL waits through poll); when poll ends the waiting (that is, when there is a data packet to receive) and is about to wake up the connection processing coroutine, the connection processing coroutine can be migrated to the computationally intensive scheduling thread. During the SQL operation, the current coroutine always remains in the computationally intensive scheduling thread.

[0085] 3) When the connection processing coroutine calls the write operation to start writing the binlog file, it means that the connection processing coroutine begins to enter the master-slave synchronization and transaction commit stage (if binlog group commit is turned on, it means that this coroutine is the "group leader"); at this time, before completing the submission of the write file IO request and letting the coroutine enter the IO wait state, the current connection processing coroutine is migrated to the IO-intensive scheduling thread.

[0086] From binlog writing, binlog sending, ack waiting, and transaction submission, until new SQL instructions are available, the current connection processing coroutine always remains in the IO-intensive scheduling thread.

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

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

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

[0090] 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.

[0091] Based on the above premise, the present invention discloses that only a callback function for waking up the coroutine operation and a callback function for the write operation need to be implemented. These two callback functions can realize the coroutine group scheduling mechanism mentioned above.

[0092] When executing a file write operation, if it is determined that the current coroutine is writing a binlog file, its scheduling thread ID is set to a value between 32 and 39 (i.e., IO 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.

[0093] The database thread pool control method provided by the embodiment 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 the compute-intensive scheduling threads and improving the concurrency performance of the database.

[0094] 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 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.

[0095] 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.

[0096] 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, which 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:

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

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

[0099] 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:

[0100] extern__thread COCTX*_current_coctx;

[0101] In this embodiment, COCTX has the following 4 types:

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

[0103] 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;

[0104] 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 if two coroutines are in the intermediate state of switching, the _current_coctx of the current thread will be set to scheduler COCTX;

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

[0106] 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 and running state it is currently in.

[0107] In this embodiment, the contents stored in the COCTX structure include: coroutine stack and TLS. The dynamic runtime 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).

[0108] If the coroutine cannot fully simulate the TLS mechanism of the thread, the coroutine will not be able to safely access variables with TLS constraints. In this embodiment, the encapsulation of TLS management is implemented through the synchronization management module (hereinafter referred to as co_tls). The capabilities provided by co_tls are crucial for "transparent" simulation of threads. Taking Linux as an example, its TCB stores the following two types of TLS: dtv and specific.

[0109] The co_tls disclosed in this disclosure supports specific: a data structure similar to specificarrays in TCB needs to be maintained in co_tls. When a newly created coroutine is swapped in for execution for the first time, the specific in the TCB of its scheduling thread will be copied. In addition, it is also necessary to hook the library functions that manage specific. The library functions of Linux are listed above. There are similar functions in Windows, namely: TlsAlloc, TlsFree, TlsGetValue, and TlsSetValue.

[0110] 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 does not need 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. Combined with 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 scheme is adopted, that is, when the coroutine is about to be swapped in, it is determined whether dtv needs to be synchronized. If dlopen is called in a coroutine, you need to identify _current_coctx as a coroutine type in the dlopen hook and immediately synchronize dtv for the current coroutine.

[0111] In this embodiment, by creating a hook function of a thread, a coroutine that is completely consistent with the thread capability can be simulated. The switching process of the coroutine is as follows: First, in the initial state of the coroutine scheduling thread, _current_coctx is schedulerCOCTX; 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 completely in user mode, without any form of interaction with the operating system, thereby maintaining the lightweight characteristics of the coroutine.

[0112] 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).

[0113] The method for generating a coroutine scheduling thread provided in this embodiment, when the database cannot modify the source code 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 for creating 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.

[0114] In some optional implementations disclosed above, 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 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; 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 a 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.

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

[0116] 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 thread building request of the database by calling the application interface of the database, detects whether the thread building request of the database is a request for processing the connection request, and calls the application interface of the dynamic runtime library when the thread building request of the database 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 works, the hook function of creating the thread determines the connection processing thread, and converts the connection processing thread into a coroutine.

[0117] 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.

[0118] 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.

[0119] 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, placing the coroutine in 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 to a specific file, and completing the submission of the IO request to write the specific file and before letting the coroutine enter IO waiting, migrating the coroutine to the current IO-intensive scheduling thread.

[0120] 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.

[0121] The method for scheduling coroutines provided by this optional implementation method migrates the coroutine to an IO-intensive scheduling thread when the coroutine in the database 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 computationally intensive scheduling thread and improving the concurrency performance of the database.

[0122] 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 completing the submission of the write specific file IO request and letting the coroutine enter IO waiting, migrating the coroutine to the current IO intensive scheduling thread includes:

[0123] 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.

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

[0125] 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, 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 is migrated is determined based on a load balancing algorithm.

[0126] In this embodiment, a coroutine wake-up callback function can be added in 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.

[0127] The database thread pool control method provided in this embodiment can improve the coroutine scheduling efficiency by migrating the coroutines awakened by the coroutines submitted by the driver in batches to the current IO-intensive scheduling thread when there are coroutines submitted by the driver in batches in the IO-intensive scheduling thread.

[0128] 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 driving batch submission in the IO-intensive scheduling thread includes: detecting whether there is a group leader coroutine driving the group submission process that writes to the binary log file in the IO-intensive scheduling thread; the IO-intensive scheduling thread has a coroutine driving 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.

[0129] 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.

[0130] 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, thereby providing a reliable implementation method for allocating group member coroutines of the MySQL database.

[0131] Further references Figure 4 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. Figure 1 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0132] like Figure 4As shown, 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 detection unit 403, and a creation unit 404. The loading unit 401 can be configured to load a dynamic runtime library capable of replacing threads with coroutines in the operating system of the database, generate at least one coroutine scheduling thread, and the coroutine scheduling thread is used to schedule at least one coroutine; the receiving unit 402 can be configured to receive a connection request sent by a client to a database; the detection unit 403 can be configured to detect whether the request for the database to create a new thread is a request to process a connection request; the creation unit 404 can be 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.

[0133] In this embodiment, the specific processing of the loading unit 401, the receiving unit 402, the detecting unit 403, and the creating unit 404 and the technical effects thereof can be referred to in the respective Figure 1 Corresponding to step 101, step 102, step 103, and step 104 in the embodiment.

[0134] In some embodiments, the 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 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, 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.

[0135] In some embodiments, the 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 a connection request sent to the database, and when the thread construction request of the database is a request for processing the connection request, control the hook function of creating a thread in the dynamic runtime library to work, and the hook function of 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.

[0136] 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.

[0137] 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 in 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 write specific file IO request and before letting the coroutine enter IO waiting, migrate the coroutine to the current IO-intensive scheduling thread.

[0138] 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 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.

[0139] 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 for driving batch submission in the IO-intensive scheduling thread; if there is a coroutine for driving batch submission in the IO-intensive scheduling thread, the coroutine awakened by the coroutine for driving batch submission is migrated to the IO-intensive scheduling thread, and the IO-intensive scheduling thread to which the coroutine awakened by the coroutine for driving batch submission is migrated is determined based on the load balancing algorithm.

[0140] 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.

[0141] The database thread pool control device provided by the embodiment of the present disclosure, first, the 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; secondly, the receiving unit 402 receives a connection request sent by the client to the database; thirdly, the detection unit 403 detects whether the request for the database to create a new thread is a request for processing a connection request; finally, the creation unit 404 responds to the detection that the request for the database to create a new thread is a request for processing 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, and the created coroutine corresponding to the connection request runs in the form of 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 replaced by another executable coroutine, which can solve the problem of increased delay of low-priority tasks and jitter of task response speed, and improve the concurrency performance of the database.

[0142] Reference below Figure 5 , which shows a structural schematic diagram of an electronic device 500 suitable for implementing an embodiment of the present disclosure.

[0143] like Figure 5 As shown, 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. In the RAM 503, various programs and data required for the operation of the electronic device 500 are also stored. 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.

[0144] Typically, the following devices may be connected to the I / O interface 505: an input device 506 including, for example, a touch screen, a touch pad, 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 may allow the electronic device 500 to communicate with other devices wirelessly or by wire to exchange data. Figure 5 The electronic device 500 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead. Figure 5 Each block shown in the figure may represent one device, or may represent multiple devices as required.

[0145] 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 a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 509, or installed from a storage device 508, or installed from a 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 executed.

[0146] It should be noted that the computer-readable medium of the embodiment of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with 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 of the above. In the embodiment of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device. In the embodiment of the present disclosure, the computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0147] The computer-readable medium may be included in the server; or it may exist independently without being assembled into the server. The computer-readable medium carries one or more programs. When the one or more programs are executed by the server, the server: loads a dynamic runtime library capable of replacing threads with coroutines in the database 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 a database; detects whether the database's request to create a new thread is a request to process a connection request; in response to detecting that the database's request 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.

[0148] 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 a user's computer, partially on a user's computer, as a separate software package, partially on a 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 via 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., via the Internet using an Internet service provider).

[0149] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the 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 from the order 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 flow chart, and the combination of the boxes in the block diagram and / or flow chart 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.

[0150] The units involved in the embodiments described in the present disclosure may be implemented by software or by hardware. The described units may also be arranged in a processor, for example, may be described as: a processor comprising a loading unit, a receiving unit, a detection unit, and a creation unit. Among them, the names of these units do not constitute a limitation on the unit itself under certain circumstances. For example, the loading unit may 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".

[0151] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. 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 cover other technical solutions formed by any combination of the above-mentioned technical features or their equivalent features without departing from the above-mentioned inventive concept. For example, the above-mentioned features are replaced with the technical features with similar functions disclosed in the embodiments of the present disclosure (but not limited to) to form a technical solution.

Claims

1. A database thread pool control method, the method include: 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 a dynamic runtime library capable of replacing threads with coroutines is loaded into the operating system of the database to generate at least one coroutine scheduling thread include: 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 dynamic runtime library capable of replacing threads with coroutines is loaded into the operating system of the database to generate at least one coroutine scheduling thread include: 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, further comprising: include: 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, in, 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, in, 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, in, 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, in, 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: Detecting whether the IO-intensive scheduling thread has a group leader coroutine driving a group submission process for performing a write operation on a binary log file; 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 include: 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. An electronic device, include: one or more processors; a storage device having one or more programs stored thereon; When the one or more 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.

11. A computer readable medium having a computer program stored thereon, in, When the program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images