Asynchronous I / O (Input / Output) implementation method and equipment under NUMA (Non Uniform Memory Access) architecture and medium
By allocating back-end processes to different NUMA nodes in the PostgreSQL database and using read and write control processes for batch reading and writing, cross-NUMA memory access problems caused by buffer read and write operations under the NUMA architecture are solved, and performance improvements are achieved.
Patent Information
- Application Number
- CN202510571283.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-06
- Publication Date
- 2025-06-03
- Estimated Expiration
- 2045-05-06
AI Technical Summary
Under the NUMA architecture, the buffer read and write operations of PostgreSQL databases may lead to cross-NUMA memory access, increasing access costs and reducing system performance.
Asynchronous I/O operations are realized by assigning back-end processes to different NUMA nodes in the PostgreSQL database and adding read and write requests to the read and write queue of the target NUMA node, using read and write control processes to perform batch reading and writing.
Reduces the number of accesses to remote memory, reduces the performance loss of cross-NUMA memory access, and improves the overall performance of the database.
Smart Images

Figure CN120086257A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of digital data processing, and particularly to an asynchronous I / O implementation method, device, and medium under a NUMA architecture. Background Art
[0002] In modern NUMA-type architecture operating systems, the physical hardware resources are divided into multiple independent NUMA nodes to improve the scalability and resource allocation efficiency of multi-core processors. Each NUMA node is essentially a self-contained computing unit, which integrates some CPU cores and their directly associated local memory. The core feature of this architecture lies in the asymmetry of memory access. That is to say, when a CPU core accesses the local memory of its affiliated NUMA node, low-latency and high-bandwidth data transmission can be achieved through a high-speed interconnect bus.
[0003] When the PostgreSQL database performs file read and write operations, it usually does not perform file read and write operations every time it accesses the file on the physical storage medium. The buffer cache stores relational pages to balance the access time to the physical storage medium and memory. When data needs to be read from the physical storage medium, the data is stored in the buffer in memory; when the buffer in memory needs to be flushed to disk, the data in the buffer in memory is written to the physical storage medium.
[0004] The existing PostgreSQL database implements the read and write methods for the buffer by calling the read and write functions of the operating system. For the PostgreSQL database running on a NUMA operating system, in the case of disk I / O scenarios that can be asynchronously executed, the PostgreSQL database may use a continuous memory area located in non-local memory as the buffer used before reading and writing for I / O processing. This buffer processing method increases the number of accesses to remote memory and causes performance loss due to cross-NUMA memory access. Summary of the Invention
[0005] To solve the above problems, the present invention proposes an asynchronous I / O implementation method under a NUMA architecture, including: Based on the main process of the PostgreSQL database, allocate multiple backend processes generated for different front-end query requests to different NUMA nodes; wherein, the backend processes are used to apply for reading and writing the buffer. When the backend process generates a read / write request for the buffer, add the read / write request to the read / write queue of the target NUMA node corresponding to the buffer. Call the read / write control process of the target NUMA node, and poll the read / write queue to add the pending read / write requests in the read / write queue as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process; Poll the I / O control structure through the read / write control process to perform batch read / write operations on the linked list elements included in the I / O linked list in a preset state, so as to implement asynchronous I / O for the PostgreSQL database.
[0006] In an implementation manner of the present invention, adding the pending read / write requests in the read / write queue as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process specifically includes: Obtain the status flag bit in the I / O control structure corresponding to the read / write control process; When the status flag bit is not in the specified state, add the pending read / write requests in the read / write queue as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process; wherein, the specified state is processing I / O, and the linked list element is an I / O structure.
[0007] In an implementation manner of the present invention, performing batch read / write operations on the linked list elements included in the I / O linked list in a preset state specifically includes: According to the status flag bit, when the I / O control structure is in a preset state, obtain the number of I / O linked list elements from the I / O control structure; wherein, the preset state is processing completed and harvesting completed; Mark the status flag bit as the specified state, and perform batch read / write operations on the linked list elements in the I / O linked list that meet the number of I / O linked list elements; After completing the batch read / write operations on the linked list elements, mark the status flag bit as the preset state.
[0008] In an implementation manner of the present invention, after adding the pending read / write requests in the read / write queue as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process, the method further includes: Determine the logical address of the buffer required by the pending read / write request and the previous pending read / write request of the pending read / write request; According to the logical address, determine whether the pending read / write request needs to be merged.
[0009] In an implementation manner of the present invention, determining whether the pending read / write request needs to be merged according to the logical address specifically includes: Determine whether the logical addresses of the to-be-processed read / write request and the previous to-be-processed read / write request are consecutive based on whether the sum of the starting address of the buffer corresponding to the previous to-be-processed read / write request and the previous read / write length corresponding to the previous to-be-processed read / write request is the same as the starting address of the buffer corresponding to the to-be-processed read / write request; If so, merge the to-be-processed read / write request and the previous to-be-processed read / write request into a combined request to accumulate the read / write length corresponding to the to-be-processed read / write request and the previous read / write length.
[0010] In an implementation manner of the present invention, adding the read / write request to the read / write queue of the target NUMA node corresponding to the buffer specifically includes: Attempt to add the read / write request to the local read / write queue of the local NUMA node corresponding to the buffer to determine whether the local read / write queue is full; If so, determine the access cost of the read / write request for each NUMA node; According to the access cost, select the NUMA node with the minimum access cost from other NUMA nodes except the local NUMA node as the target NUMA node for adding the read / write request, and add the read / write request to the read / write queue of the target NUMA node.
[0011] In an implementation manner of the present invention, attempting to add the read / write request to the local read / write queue of the local NUMA node corresponding to the buffer to determine whether the local read / write queue is full specifically includes: Obtain the free element pointer and the tail pointer in the local read / write queue; Compare the positions corresponding to the free element pointer and the tail pointer. When the next position of the free element pointer is the tail pointer, determine that the local read / write queue is full.
[0012] In an implementation manner of the present invention, after batch reading and writing the linked list elements included in the I / O linked list that meet the preset state, the method further includes: When an exception occurs in the batch reading and writing, determine the corresponding exception type; If the exception type is a system call interruption, perform batch reading and writing of the linked list elements again; If the exception type is not a system call interruption, save the exception state corresponding to the batch reading and writing according to the read / write request type corresponding to the batch reading and writing.
[0013] An embodiment of the present invention provides an asynchronous I / O implementation device in a NUMA architecture. The device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute an asynchronous I / O implementation method under a NUMA architecture as described in any one of the above.
[0014] An embodiment of the present invention provides a non-volatile computer storage medium storing computer-executable instructions, and the computer-executable instructions are configured to: an asynchronous I / O implementation method under a NUMA architecture as described in any one of the above.
[0015] The asynchronous I / O implementation method under a NUMA architecture proposed by the present invention can bring the following beneficial effects: The backend process is no longer responsible for buffer reading and writing, but only makes reading and writing requests. The asynchronous reading and writing requests that can be made to the buffer in the memory of the same NUMA node are handed over to the reading and writing control process running on the CPU core located on the same NUMA node for proxy processing. When the reading and writing control process accesses the buffer located in the local memory, compared with accessing the remote memory, the access cost is reduced. Combined with the batch processing of I / O, the result of reducing the performance loss of the database and optimizing the database performance can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The drawings described herein are used to provide a further understanding of the present invention, and constitute a part of the present invention. The illustrative embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings: Figure 1 is a schematic flowchart of an asynchronous I / O implementation method under a NUMA architecture provided by an embodiment of the present invention; Figure 2 is a schematic diagram of a NUMA architecture provided by an embodiment of the present invention; Figure 3 is a schematic diagram of a read / write queue data structure provided by an embodiment of the present invention; Figure 4 is a schematic diagram of a data structure provided by an embodiment of the present invention; Figure 5 is a schematic diagram of the structure of an asynchronous I / O implementation device under a NUMA architecture provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0017] To make the objectives, technical solutions and advantages of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments of the present invention and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the scope of protection of the present invention.
[0018] PostgreSQL (commonly abbreviated as Postgres) is an open-source relational database management system, known for its powerful functions, high reliability and scalability. It supports the SQL language and provides rich extension capabilities, suitable for application scenarios of various scales. In the PostgreSQL database system running on the NUMA platform, when its buffer is applied for, initialized, allocated, read and written, it does not distinguish which local memory of which NUMA node it is located in. The process responsible for reading and writing to this buffer is also scheduled by the operating system to select a CPU core according to the scheduling algorithm in the system. The CPU core for scheduling and this buffer are not necessarily located on the same NUMA node. This way of processing the buffer increases the number of accesses to remote memory and causes performance loss.
[0019] The technical solutions provided by each embodiment of the present invention will be described in detail below in conjunction with the drawings.
[0020] As Figure 1 shown, an asynchronous I / O implementation method under the NUMA architecture provided by an embodiment of the present invention includes: S101: Based on the main process of the PostgreSQL database, allocate multiple backend processes generated for different front-end query requests to different NUMA nodes; among them, the backend processes are used to apply for reading and writing to the buffer.
[0021] As Figure 2 shown in a schematic diagram of the NUMA architecture, when the PostgreSQL database is started, a main process Postgres will be created, which is responsible for managing the life cycle of the entire database system, including listening for connection requests from clients, starting and managing backend processes, maintaining the global state of the database, etc. When a user initiates a query operation at the front end, such as querying data in the database, performing insert, update or delete operations, these front-end query requests will be sent to the PostgreSQL database. When the main process receives the front-end query request, it will fork a backend process for each request and run these backend processes on different CPU cores according to the scheduling algorithm, that is, distribute them to different NUMA nodes. The difference between the embodiment of the present invention and the traditional NUMA I / O implementation method is that the backend process only makes read and write applications and does not responsible for the actual read and write processing.
[0022] S102: When a read / write request for the buffer is generated by the backend process, add the read / write request to the read / write queue of the target NUMA node corresponding to the buffer.
[0023] In PostgreSQL, the buffer is used to cache data pages in the database in memory. When the backend process initiates a read / write request, the NUMA node will first check whether there is a corresponding data page in the buffer. If there is, the read / write operation will be directly performed; if not, the data page will be read from the disk and loaded into the buffer. The role of the buffer is to reduce disk I / O operations and improve database performance.
[0024] Under the NUMA architecture, the memory access latency of different NUMA nodes is different. If the backend process randomly performs read / write operations on the buffer, it may frequently access memory across NUMA nodes, resulting in an increase in memory access latency and a decrease in system performance. To reduce this cross-node memory access and improve memory access efficiency, it is necessary to centralize the read / write requests of the backend process for the buffer into the read / write queue of the corresponding target NUMA node. The read / write queue stores the read / write requests for the target NUMA node in sequence. When multiple backend processes simultaneously initiate read / write requests for the buffer of the same NUMA node, these requests will be added to the read / write queue and then processed sequentially according to certain rules to avoid conflicts and ensure data consistency.
[0025] In one embodiment, under the NUMA architecture, in order to make full use of the local memory resources of each node and improve memory access efficiency, the backend process is usually given priority to send read / write requests to the local read / write queue of the local NUMA node. However, the capacity of the local read / write queue is limited. When the queue is full, if a request is continuously tried to be added to it, it will cause request backlog and affect read / write performance. Therefore, when adding a read / write request to the read / write queue of the target NUMA node, it is necessary to reasonably screen the read / write requests according to the access costs of different NUMA nodes to achieve dynamic balance of distributing read / write requests. Thus, when the local read / write queue is full, some read / write requests are transferred to other nodes with lower access costs, avoiding blocking of the local queue due to overload, reducing the latency of critical requests, and optimizing resource utilization at the same time.
[0026] First, analyze the location of the local NUMA node of the memory where the buffer to be written is located. Then, try to add the read / write request to the local read / write queue of the local NUMA node corresponding to the buffer to determine whether the local read / write queue is full. If the queue is not full, the read / write request will be successfully added to the local read / write queue and then processed by the local NUMA node in the queue order. If the local queue is full and the request cannot be added to the local queue, at this time, it is necessary to find other NUMA nodes as the target NUMA node.
[0027] To select the optimal node, it is necessary to calculate the access cost of the read-write request for all NUMA nodes except the local NUMA node. The calculation of the access cost usually considers multiple factors, such as the physical distance between nodes, the bandwidth of the communication link, the current load of the nodes, etc. Generally speaking, the farther the distance, the lower the bandwidth, and the higher the load, the greater the access cost. According to the calculated access costs of each NUMA node, select the NUMA node with the smallest access cost from the nodes other than the local NUMA node. This node is the target NUMA node of the current read-write request. Finally, add the read-write request to the read-write queue of the target NUMA node, and the target NUMA node is responsible for processing the request. If no free space is found in the read-write queue of each NUMA node, spin waiting is required, and the read-write request queues are polled in ascending order of the memory access costs of the local NUAM node and other NUMA nodes until there is free space in one of the read-write queues and then the read-write queue is inserted.
[0028] It should be noted that when judging whether the read-write queue is full, it is necessary to judge through the free element pointer and the tail pointer. As Figure 3 shown in a schematic diagram of the read-write queue data structure, the read-write queue is maintained by a read-write control process. The read-write queue is an idle queue. Each time the backend process reads and writes, it needs to use an idle space in the read-write queue. When it needs to use an idle space, it locates according to the free element pointer and fills the information into the queue member structure at the position of the free element. Each queue member contains a buffer descriptor, physical file information, I / O operation type, whether it is idle, a pointer to the next element, etc., to ensure the orderly processing of read-write requests. The free element pointer pointing to the free element node represents the current position in the local read-write queue that can be used to store new read-write requests. It moves as requests are added and always indicates the next free node that can be written. The tail pointer pointing to Request 1 marks the last occupied request node in the local read-write queue and is used to define the boundary of the requests stored in the queue.
[0029] When the backend process attempts to add a read-write request to the local read-write queue, it first obtains the two key pointers of the queue, namely the free element pointer and the tail pointer. Perform a logical comparison on the positions corresponding to the free element pointer and the tail pointer. As Figure 3In the queue structure shown, each node is connected by a pointer pointing to the next element. When a read / write request is added to the read / write queue, it is first added to the first available position in the logical order according to the queue order. After the read / write request is written, the pointer to the available element is moved backward. If the next position of the pointer to the available element is the tail pointer, it means that the pointer to the available element currently points to the last available node, and the next position of this node has reached the occupied node pointed to by the tail pointer. At this time, there is no extra available node in the queue to store new requests, that is, the queue is full.
[0030] S103: Call the read / write control process of the target NUMA node to poll the read / write queue, and add the pending read / write requests in the read / write queue as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process.
[0031] There is a read / write control process on each NUMA node. The read / write control process has two responsibilities. One of the responsibilities is to maintain the read / write queue. The read / write control process of the target NUMA node will periodically poll the read / write queue, and the read / write queue will return the current first pending read / write request to be processed to the read / write control process when polled. If there is a pending read / write request on the queue and the I / O control structure is not in the state of I / O being processed, add the pending request as a linked list element to the I / O linked list in the I / O control structure. The I / O linked list is a linked list structure in the I / O control structure, which is used to store pending I / O requests. These requests exist in the form of I / O structures in the linked list, which is convenient for management and scheduling.
[0032] As Figure 4 Shown in a schematic diagram of a data structure, the I / O control structure is the core data structure responsible for coordinating and managing the I / O request processing of the local node. The I / O control structure stores the unprocessed I / O linked list, status flag bits, the number of I / O linked list elements, the number of processed I / O linked list elements, and the buffer pointer. The linked list elements in the I / O linked list are I / O structures. The I / O structure contains the status information of this I / O, the buffer descriptor to be used, the physical file information, the I / O operation type, and a pointer to the next I / O structure. The status flag bit of the I / O control structure is used to represent the current usage status of this I / O control structure. There are 7 statuses in total, namely: idle (no requests), I / O being processed, I / O processing exception, requests being merged, processing completed waiting for harvesting, harvesting in progress after processing completed, harvesting completed after processing completed. The buffer pointer is used to indicate the buffer data position when reading data during an I / O operation.
[0033] A large number of read and write requests are generated by the PostgreSQL database. To efficiently process these read and write requests, it is necessary to call the read and write control processes on each NUMA node for management. The I / O control structure is the key data structure for centrally managing these I / O operations. However, I / O operations need to be carried out sequentially, and only one request can be processed at the same time. Therefore, it is necessary to control the addition of requests through status flags to avoid conflicts and errors caused by multiple requests being processed simultaneously.
[0034] In one embodiment, when the read and write control process needs to add a pending read and write request in the read and write queue to the I / O linked list of the I / O control structure, it will first obtain the status flag in the I / O control structure. The status flag can reflect the usage status of the current I / O control structure, thereby determining whether a new request can be added. After obtaining the status flag, it will be judged whether it is in the specified state, and the specified state means that the I / O is being processed. If it is in the specified state, it means that the I / O control structure is processing an I / O request. At this time, a new request cannot be added to the I / O linked list, and it is necessary to wait for the request to be processed and the status flag to change before trying again. When the status flag is not in the specified state, it means that the I / O control structure is not currently processing an I / O request and can receive a new request. Then, the new read and write request can be directly added to the I / O linked list as a linked list element.
[0035] It should be noted that in I / O operations, frequent read and write requests will increase the system overhead, especially on storage devices such as disks. Each I / O operation has a certain time and resource cost. When the data accessed by multiple read and write requests is continuous or adjacent in the buffer, merging these requests into one request for processing can reduce unnecessary I / O operations and improve the read and write performance of the database. Therefore, after adding the pending read and write request to the I / O linked list, it is necessary to judge whether request merging can be performed.
[0036] Specifically, after adding the pending read and write request to the I / O linked list, determine the logical address of the buffer required by this pending read and write request. At the same time, the logical address of the buffer required by the previous pending read and write request of this pending read and write request will also be determined. The logical address can be obtained by reading the information recorded in the I / O structure. The logical address can be information such as the starting address and length of the buffer, which is used to determine the specific position of the data involved in the request in the buffer. According to the two obtained logical addresses, judge whether these two requests can be merged. The basis for judgment is usually the continuity or adjacency of the logical addresses.
[0037] Specifically, obtain the starting address of the buffer corresponding to the previous read / write request to be processed, and the previous read / write length corresponding to this request. Then, add the starting address of the buffer corresponding to the previous read / write request to be processed to the previous read / write length to obtain the ending address of the data involved in the previous request in the buffer. For example, if the starting address of the buffer of the previous read / write request to be processed is start_addr_prev and the previous read / write length is length_prev, then the ending address of the previous request is end_addr_prev = start_addr_prev + length_prev. Then, obtain the starting address start_addr_current of the buffer corresponding to the current read / write request to be processed, and compare whether the ending address end_addr_prev of the previous request is the same as the starting address start_addr_current of the buffer corresponding to the current read / write request to be processed. If they are the same, it means that the data involved in these two requests is continuous in the buffer, that is, their logical addresses are continuous. When it is determined that the logical addresses of the read / write request to be processed and the previous read / write request to be processed are continuous, the operating system will merge these two requests.
[0038] The specific operation of the merge is to accumulate the read / write length length_current corresponding to the read / write request to be processed with the previous read / write length length_prev to obtain a new read / write length new_length = length_prev + length_current. At the same time, update the relevant request information and treat these two requests as a whole for subsequent processing.
[0039] In addition, if the logical addresses of the two read / write requests are not continuous but very close, they may also be merged according to specific strategies. For example, the interval between the two read / write requests is less than a preset time threshold. Merging these two requests can reduce the number of I / O operations and improve efficiency.
[0040] S104: Poll the I / O control structure through the read / write control process to perform batch read / write on the list elements included in the I / O list in a preset state, so as to implement asynchronous I / O for the PostgreSQL database.
[0041] In addition to maintaining the read-write queue, the read-write control process is also responsible for periodically polling the I / O control structure, scheduling read-write operations by reading the information in the control structure, and performing batch read-writes on the list elements included in the I / O linked list that meet the preset status. In the traditional synchronous I / O mode, the front end will block and wait for the operation to complete after initiating an I / O request, which will cause waste of CPU resources. Especially in high-concurrency scenarios, it will seriously affect the performance and response speed of the database. In the embodiment of the present invention, the I / O processing that can be asynchronously performed in the buffer area of the NUMA node memory is handed over to the read-write control process running on the CPU core located on the same NUMA node for proxy processing. By polling the I / O control structure by the read-write control process and performing batch read-writes, asynchronous I / O can be better implemented and the overhead of I / O operations can be reduced.
[0042] In one embodiment, the read-write control process polls the I / O control structure at regular time intervals. During the polling process, it determines whether the status of the I / O control structure meets the preset status according to the status flag bit. The preset status here refers to the processing completion and harvesting completion. When the I / O control structure is in the state of processing completion and harvesting completion and other states are not true, it indicates that the I / O control structure has completed the processing of all requests and resource recycling and is in a reusable state. At this time, the control system obtains the number of I / O linked list elements from the I / O control structure, and the number of I / O linked list elements is the number of read-write requests to be processed in the subsequent batch read-write operation.
[0043] To avoid concurrency problems during batch read-writes, the operating system marks the status flag bit as a specified status before performing batch read-writes. The specified status indicates that the I / O control structure is performing a batch read-write operation, and other processes or operations need to wait for this operation to complete. After marking the status flag bit, batch read-write operations are performed on the list elements in the I / O linked list that meet the number of I / O linked list elements. Specifically, the read-write requests represented by these list elements are combined into a group and sent to the corresponding buffer for read-write processing at one time. When the batch read-write operation is completed, the status flag bit is marked as the preset status again, which means that the I / O control structure has completed the current round of batch read-write tasks and has cleaned up and harvested the relevant resources, and can accept new read-write tasks again.
[0044] Through the above batch read-write mechanism based on the status flag bit, the efficiency of I / O operations can be effectively improved and system overhead can be reduced. At the same time, the use of the status flag bit ensures the order and correctness of I / O operations, avoids the occurrence of concurrency problems, and forms a closed loop in the entire scheduling process of the read-write control process by marking the status flag bit, thereby realizing efficient query of the PostgreSQL database.
[0045] It should be noted that after the batch read and write operations are performed by the read-write control process, abnormal situations may occur due to reasons such as hardware failures, insufficient system resources, and software errors. After the batch read and write operations, it is necessary to check and handle possible exceptions to ensure the reliability of the system and the integrity of the data.
[0046] Specifically, after the batch read and write operations are completed, first check whether there are any exceptions. If an exception is detected in the batch read and write, it is necessary to further determine the corresponding exception type. If the error code EINTR is returned, that is, the system call is interrupted, regardless of whether the request being processed is a merged request or not, the batch read and write of the linked list elements needs to be executed again. In the case of an exception other than EINTR, that is, not a system call interruption, it is necessary to save the exception status corresponding to the batch read and write according to the type of read and write request corresponding to the batch read and write. The merged read and write requests are first split and the I / O operations are executed again separately. If there are still exceptions, the exception statuses are saved separately. The transaction associated with the I / O will detect the completion status of the I / O before submission. If it is not completed, it will block and wait. If there is an exception, the transaction will roll back.
[0047] As Figure 2 shown in a schematic diagram of a NUMA architecture, the main process Postgres of the PostgreSQL database will fork out the backend processes for the front-end query requests. The backend processes are allocated to different NUMA nodes, and each NUMA node is responsible for processing multiple I / O requests that can be executed asynchronously. When there are read and write requests for the buffer generated by the backend process, according to the NUMA node corresponding to the buffer and the load conditions of the read and write queues in the NUMA node, the read and write requests are distributed to the corresponding target NUMA nodes. The target NUMA nodes here can be one or more. The read and write requests are preferentially distributed to the local NUMA node. When the local read and write queue is full, the read and write requests will be inserted into the read and write queues of the corresponding NUMA nodes in ascending order of access cost. The backend process is not responsible for performing the read and write operations. After the backend process completes the distribution of the read and write requests, the read-write control process obtains the read and write requests by polling the read and write queues and writes the read and write requests into the I / O control structure. The read-write control process schedules the read and write requests that meet the preset status by periodically reading the data in the I / O control structure and changing the status of the I / O control structure, realizing the batch read and write of the permanent storage medium and obtaining the corresponding return results.
[0048] The read and write methods of the PostgreSQL buffer are not optimized for the NUMA architecture design. When the backend process reads and writes the buffer, if the buffer is remote memory, more access costs will be incurred compared to accessing local memory, thereby affecting the overall performance of the database. In the embodiments of the present invention, instead of having the backend process perform buffer reading and writing, the asynchronous read and write requests for the buffer in the memory of the same NUMA node are handed over to the read and write control process running on the CPU core located on the same NUMA node for proxy processing. When the read and write control process accesses the buffer located in local memory, the access cost is reduced compared to accessing remote memory. Combined with the batch processing of I / O, the result of reducing the performance loss of the database and achieving database performance optimization can be achieved.
[0049] The above is the method embodiment proposed by the present invention. Based on the same idea, some embodiments of the present invention also provide the corresponding devices and non-volatile computer storage media for the above method.
[0050] Figure 5 It is a schematic structural diagram of an asynchronous I / O implementation device under the NUMA architecture provided by the embodiments of the present invention. As Figure 5 shown, it includes: At least one processor; and, A memory communicatively connected to at least one processor; wherein, The memory stores instructions executable by at least one processor, and the instructions are executed by at least one processor so that at least one processor can execute an asynchronous I / O implementation method under the NUMA architecture as described in any one of the above.
[0051] The embodiments of the present invention provide a non-volatile computer storage medium storing computer-executable instructions, and the computer-executable instructions are set as: An asynchronous I / O implementation method under the NUMA architecture as described in any one of the above.
[0052] The various embodiments in the present invention are described in a progressive manner. The same or similar parts among the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments.
[0053] The devices and media provided by the embodiments of the present invention correspond one-to-one with the methods. Therefore, the devices and media also have beneficial technical effects similar to those of the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be elaborated here.
[0054] Those skilled in the art will understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) that contain computer-usable program code.
[0055] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable data processing devices to generate a machine, such that the instructions executed by the processors of the computer or other programmable data processing devices produce means for implementing the functions specified in Figure 1 one or more of the flows Figure 1 or blocks or combinations of blocks.
[0056] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufactured article including instruction means that implement the functions specified in Figure 1 one or more of the flows Figure 1 or blocks or combinations of blocks.
[0057] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are performed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in Figure 1 one or more of the flows Figure 1 or blocks or combinations of blocks.
[0058] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.
[0059] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.
[0060] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
[0061] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.
[0062] The above description is only an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent substitution, improvement, etc. made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.
Claims
1. A method for implementing asynchronous I / O under a NUMA architecture, characterized in that: The method comprises: Based on the main process of the PostgreSQL database, multiple backend processes generated for different frontend query requests are allocated to different NUMA nodes; wherein the backend processes are used to apply for read and write to the buffer; When the backend process generates a read / write request for a buffer, the read / write request is added to a read / write queue of a target NUMA node corresponding to the buffer; Calling the read / write control process of the target NUMA node, polling the read / write queue, and adding the pending read / write requests in the read / write queue as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process; The read / write control process polls the I / O control structure to batch read and write the linked list elements contained in the I / O linked list in a preset state, thereby realizing asynchronous I / O for the PostgreSQL database.
2. The method for implementing asynchronous I / O under a NUMA architecture according to claim 1, characterized in that: Adding the pending read / write requests in the read / write queue as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process specifically includes: Obtaining the status flag bit in the I / O control structure corresponding to the read / write control process; When the status flag is not in a specified state, the pending read / write requests in the read / write queue are added as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process; wherein the specified state is processing I / O, and the linked list element is the I / O structure.
3. The method for implementing asynchronous I / O under a NUMA architecture according to claim 2, wherein: Batch reading and writing of the linked list elements contained in the I / O linked list that meet the preset state specifically includes: According to the state flag, when the I / O control structure satisfies a preset state, the number of I / O linked list elements is obtained from the I / O control structure; wherein the preset state is processing completion and harvesting completion; Mark the state flag as the specified state, and perform batch reading and writing of the linked list elements in the I / O linked list that meet the number of elements in the I / O linked list; After completing the batch reading and writing of the linked list elements, the state flag is marked as a preset state.
4. The method for implementing asynchronous I / O under a NUMA architecture according to claim 1, wherein: After adding the pending read / write requests in the read / write queue as linked list elements to the I / O linked list in the I / O control structure corresponding to the read / write control process, the method further includes: Determine the logical address of the buffer area required by the pending read / write request and the previous pending read / write request of the pending read / write request; It is determined whether the pending read and write requests need to be merged according to the logical address.
5. The method for implementing asynchronous I / O under a NUMA architecture according to claim 4, characterized in that: According to the logical address, determining whether the pending read and write requests need to be merged includes: Determine whether the logical addresses of the pending read / write request and the previous pending read / write request are continuous, based on whether the sum of the first address of the buffer corresponding to the previous pending read / write request and the previous read / write length corresponding to the previous pending read / write request is the same as the first address of the buffer corresponding to the pending read / write request; If so, the pending read / write request is merged with the previous pending read / write request to accumulate the read / write length corresponding to the pending read / write request and the previous read / write length.
6. The method for implementing asynchronous I / O under a NUMA architecture according to claim 1, characterized in that: Adding the read / write request to the read / write queue of the target NUMA node corresponding to the buffer specifically includes: Trying to add the read / write request to a local read / write queue of a local NUMA node corresponding to the buffer to determine whether the local read / write queue is full; If yes, determine the access cost of the read / write request for each NUMA node; According to the access cost, a NUMA node with the smallest access cost is selected from other NUMA nodes except the local NUMA node as a target NUMA node for adding the read / write request, and the read / write request is added to a read / write queue of the target NUMA node.
7. The method for implementing asynchronous I / O under a NUMA architecture according to claim 6, characterized in that: Trying to add the read / write request to a local read / write queue of a local NUMA node corresponding to the buffer to determine whether the local read / write queue is full, specifically comprising: Obtaining an idle element pointer and a tail pointer in the local read-write queue; The positions corresponding to the idle element pointer and the tail pointer are compared, and when the next position of the idle element pointer is the tail pointer, it is determined that the local read-write queue is full.
8. The method for implementing asynchronous I / O under a NUMA architecture according to claim 1, wherein: After batch reading and writing the linked list elements included in the I / O linked list that meet the preset state, the method further includes: When an exception occurs in the batch reading and writing, determining a corresponding exception type; If the exception type is a system call interrupt, batch reading and writing of the linked list elements are performed again; If the exception type is not a system call interrupt, the exception state corresponding to the batch reading and writing is saved according to the read / write request type corresponding to the batch reading and writing.
9. An asynchronous I / O implementation device under a NUMA architecture, characterized in that: The device comprises: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute an asynchronous I / O implementation method under a NUMA architecture as described in any one of claims 1-8.
10. A non-volatile computer storage medium storing computer executable instructions, characterized in that: The computer executable instructions are configured to: An asynchronous I / O implementation method under a NUMA architecture as described in any one of claims 1 to 8.
Citation Information
Patent Citations
Instruction prefetch-based multi-core shared memory control equipment
CN102207916A
Method for preventing node controller from deadly embrace and node controller
CN102439571A
Thread pool processing method and system capable of fusing synchronous and asynchronous features
CN103197968A
Method and device for dynamic control over memory reading and writing
CN103838513A
Synchronization method for NUMA (Non Uniform Memory Access) sensing under multi-core and multi-thread environment
CN104834505A
Cited By
Solid-state memory back-end loopback test method
CN121393517A