Data interaction method, apparatus and electronic device

By obtaining the waiting command statistics of the file descriptor mechanism in the cloud service system and adjusting the call frequency of the epoll mechanism, the problem of wasted computing resources in the cloud service system is solved and the data processing efficiency is improved.

CN121277909BActive Publication Date: 2026-06-05CHINA TELECOM CLOUD TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
CHINA TELECOM CLOUD TECH CO LTD
Filing Date
2025-12-09
Publication Date
2026-06-05

AI Technical Summary

Technical Problem

Cloud service systems suffer from wasted computing resources when retrieving kernel data into user space.

Method used

By obtaining statistics on waiting commands in the file descriptor mechanism of the compute nodes, the proportion of invalid polling is determined, and the call frequency of waiting commands is adjusted according to this proportion to reduce invalid polling and optimize the use of the epoll mechanism.

Benefits of technology

This reduces the waste of computing resources on computing nodes, improves data processing efficiency, and reduces the computing burden on the CPU.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121277909B_ABST
    Figure CN121277909B_ABST
Patent Text Reader

Abstract

The application discloses a data interaction method and device and electronic equipment, and belongs to the field of data communication of a data center. The method comprises the following steps: obtaining statistical information of a waiting command of a file descriptor mechanism in a computing node; determining an invalid polling proportion of the waiting command according to the statistical information; determining a calling frequency of the waiting command according to the invalid polling proportion; controlling a thread in the computing node to call the waiting command according to the calling frequency, so as to determine a file descriptor in a ready state in the computing node, the file descriptor in the ready state being used to store target data corresponding to a data access request in a kernel of the computing node after the storage node responds to the data access request sent by the computing node, and the thread of the computing node and the kernel of the computing node being interacted to obtain the target data; and the file descriptor is registered in the file descriptor mechanism by the thread of the computing node. The application embodiment reduces resource waste caused by invalid calling of the waiting command in a cloud service system.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of data communication in data centers, and specifically relates to a data interaction method, apparatus, and electronic device. Background Technology

[0002] With the diversification of network services and the rapid growth of data traffic, cloud service systems that process big data need to quickly acquire kernel IO (Input / Output) data to user space to improve data processing performance and save CPU (Central Processing Unit) computing resources.

[0003] For cloud service system vendors, obtaining kernel data is an unavoidable device requirement and a major technical challenge. However, the current kernel mechanism of cloud service systems results in a waste of computing resources when obtaining kernel data to user space. Summary of the Invention

[0004] The purpose of this application is to provide a data interaction method, apparatus, and electronic device that can solve the problem of wasted computing resources when cloud service systems obtain kernel data to user space.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a data interaction method applied to a cloud service system, the cloud service system including computing nodes and storage nodes, the method comprising:

[0007] Obtain statistical information on the file descriptor mechanism waiting commands in the compute node;

[0008] The proportion of invalid polling for the waiting command is determined based on the statistical information.

[0009] The frequency of calling the waiting command is determined based on the invalid polling ratio;

[0010] The waiting command is invoked according to the calling frequency to determine the file descriptors in the ready state in the computing node. The ready file descriptors are used to store the target data corresponding to the data access request in the kernel of the computing node after the storage node responds to the data access request sent by the computing node. The threads of the computing node interact with the kernel of the computing node to obtain the target data. The file descriptors are registered by the threads of the computing node in the file descriptor mechanism.

[0011] In the above embodiments, this application embodiment can determine the invalid polling ratio of waiting commands based on the statistical information of waiting commands in the file descriptor mechanism of the cloud service system, and then determine the calling frequency of waiting commands in the computing node based on the invalid polling ratio. In this way, the problem of waiting commands spinning idly in the file descriptor mechanism of the computing node is avoided, the number of invalid calls to waiting commands is reduced, and the waste of computing resources caused by invalid calls to waiting commands in the cloud service system is reduced.

[0012] Optionally, the statistics may include at least the total number of times the number of times the number of wait commands is invoked and the number of times the number of file descriptors returning a ready state is different from the specified number.

[0013] Optionally, the number of times the number of file descriptors in the ready state is different includes at least the number of times the number of file descriptors in the ready state is 0, and determining the invalid polling ratio of the waiting command based on the statistical information includes:

[0014] The invalid polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 0.

[0015] Optionally, determining the call frequency of the waiting command based on the invalid polling ratio includes:

[0016] When the proportion of invalid polling exceeds a first preset threshold, the frequency of calling the waiting command is reduced.

[0017] When the proportion of invalid polling is less than or equal to a first preset threshold, the frequency of calling the waiting command is increased.

[0018] In the above embodiments, by determining the invalid polling ratio based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 0, the invalidity of epoll_wait (waiting for commands) can be quantified. Then, epoll_wait (waiting for commands) can be adaptively adjusted according to the invalidity, thereby reducing the waste of computing resources of computing nodes.

[0019] Optionally, the number of times the number of file descriptors in the ready state returned is a different specified number also includes at least the number of times the number of file descriptors in the ready state returned by the waiting command is 1 and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2.

[0020] Optionally, determining the call frequency of the waiting command based on the invalid polling ratio includes:

[0021] The inefficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 1.

[0022] The efficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2.

[0023] The call frequency of the waiting command is determined based on the inefficient polling ratio, the efficient polling ratio, and the invalid polling ratio.

[0024] In the above embodiments, the inefficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 1, while the efficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2. This allows for a more accurate quantification of the inefficiency and efficiency (efficiency and inefficiency) of epoll_wait (waiting for commands). Consequently, epoll_wait (waiting for commands) can be adaptively adjusted based on the degree of inefficiency and efficiency, thereby better reducing the waste of computing resources on computing nodes.

[0025] Optionally, determining the call frequency of the waiting command based on the inefficient polling ratio, the efficient polling ratio, and the invalid polling ratio includes:

[0026] When the proportion of invalid polling exceeds a second preset threshold, the frequency of calling the waiting command is reduced.

[0027] When the proportion of invalid polling is less than or equal to a second preset threshold and the proportion of inefficient polling is greater than a third preset threshold, the frequency of calling the waiting command is reduced.

[0028] When the proportion of invalid polling is less than or equal to a second preset threshold, the proportion of inefficient polling is less than or equal to a third preset threshold, and the proportion of efficient polling is greater than a fourth preset threshold, the call frequency of the waiting command is increased.

[0029] In the above embodiments, the frequency of epoll_wait (waiting for commands) calls can be reduced or increased more precisely and adaptively based on the relationship between the invalid polling ratio, the inefficient polling ratio, the efficient polling ratio and the preset threshold, thereby reducing the idle situation of epoll_wait (waiting for commands) and thus reducing the waste of computing resources of computing nodes.

[0030] Secondly, embodiments of this application provide a data interaction apparatus applied to a cloud service system, the cloud service system including computing nodes and storage nodes, the apparatus comprising:

[0031] The statistics information acquisition module is used to acquire statistics on the waiting commands of the file descriptor mechanism in the computing node;

[0032] An invalid polling ratio determination module is used to determine the invalid polling ratio of the waiting command based on the statistical information.

[0033] The call frequency determination module is used to determine the call frequency of the waiting command based on the invalid polling ratio;

[0034] The data interaction module is used to control the threads in the computing node to call the wait command according to the calling frequency, so as to determine the file descriptors in the computing node that are in a ready state. The file descriptors in the ready state are used to store the target data corresponding to the data access request in the kernel of the computing node after the storage node responds to the data access request sent by the computing node. The threads of the computing node interact with the kernel of the computing node to obtain the target data. The file descriptors are registered by the threads of the computing node in the file descriptor mechanism.

[0035] Thirdly, embodiments of this application provide an electronic device, including: a processor; and a memory for storing processor-executable instructions;

[0036] The processor is configured to execute the instructions to implement the data interaction method described above.

[0037] Fourthly, embodiments of this application provide a computer-readable storage medium that, when the instructions in the storage medium are executed by the processor of a mobile terminal, enables the mobile terminal to perform the aforementioned data interaction method.

[0038] In this embodiment, the cloud service system may include compute nodes and storage nodes. It obtains statistical information on wait commands in the file descriptor mechanism of the compute nodes, determines the invalid polling ratio of wait commands based on the statistical information, determines the call frequency of wait commands based on the invalid polling ratio, and finally controls the threads in the compute nodes to call wait commands according to the call frequency. This identifies file descriptors in the compute nodes that are in a ready state. The ready file descriptors are used to store the target data corresponding to the data access request in the kernel of the compute node after the storage node responds to the data access request sent by the compute node. The threads of the compute node interact with the kernel of the compute node to obtain the target data. The file descriptors are registered by the threads of the compute node in the file descriptor mechanism. This embodiment can determine the invalid polling ratio of wait commands based on the statistical information of wait commands in the file descriptor mechanism of the cloud service system, and then determine the call frequency of wait commands in the compute nodes based on the invalid polling ratio. This avoids the problem of idle wait commands in the file descriptor mechanism of the compute nodes, reduces the number of invalid calls to wait commands, and thus reduces the waste of computing resources caused by invalid calls to wait commands in the cloud service system. Attached Figure Description

[0039] Figure 1 This is a flowchart illustrating the steps of a data interaction method provided in an embodiment of this application;

[0040] Figure 2 This is a flowchart of an epoll mechanism for a thread module provided in an embodiment of this application;

[0041] Figure 3 This is a storage computing connection diagram provided in an embodiment of this application;

[0042] Figure 4 This is a schematic diagram of an Epoll mechanism detection process provided in an embodiment of this application;

[0043] Figure 5 This is a structural block diagram of a data interaction device provided in an embodiment of this application;

[0044] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0045] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0046] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0047] In practical implementations, cloud service systems can include compute nodes and storage nodes. Compute nodes incorporate a file descriptor mechanism. File descriptors are indexes created by the kernel for efficient management of open files, pointing to those files. In network and system programming, I / O multiplexing mechanisms allow a thread or process (worker) to monitor multiple file descriptors simultaneously to determine if they are ready for I / O operations (such as reading or writing). Traditional select and poll mechanisms are used to monitor file descriptors, but these mechanisms suffer from performance bottlenecks when handling a large number of file descriptors.

[0048] Specifically, the traditional select and poll mechanisms have the following drawbacks: 1) They limit the number of file descriptors (usually 1024), passing the file descriptor set through structures like FD_SET, which need to be reset for each call, resulting in low efficiency. 2) They linearly scan all file descriptors, with a complexity of O(n), leading to significant performance degradation when processing a large number of file descriptors. 3) While the poll mechanism overcomes the file descriptor limit of the select mechanism, it still requires a linear scan of each file descriptor set, and performance issues persist.

[0049] To address the aforementioned issues and improve the efficiency of handling a large number of concurrent connections, the Linux operating system kernel introduced the epoll mechanism. Specifically, epoll is an I / O multiplexing mechanism provided by the Linux kernel for efficiently handling a large number of concurrent I / O requests. It is an improvement over traditional I / O multiplexing techniques such as select and poll, and performs particularly well in high-concurrency scenarios.

[0050] Specifically, the epoll mechanism supports an event-driven model, allowing you to focus only on file descriptors that are already ready (file descriptors in the ready state) without constantly polling all file descriptors. It is suitable for high-performance servers that need to handle a large number of concurrent connections, such as storage servers, and for cloud service systems that require low latency and high throughput.

[0051] However, the current usage of the epoll mechanism has many problems in processing large volumes of data, resulting in wasted resources. Therefore, this application proposes a data processing method based on existing protocol stack implementations, which has significant technical advantages. Its key features are listed below: First, it reduces the invalid polling of `epoll_wait` (waiting for commands) in the epoll mechanism, as there are many invalid traversals after setting `epoll_wait` (waiting for commands) for polling. Second, by judging the return value (statistical information) of `epoll_wait` (waiting for commands), invalid system calls of `epoll_wait` (waiting for commands) can be reduced, allowing valuable computing resources to handle more business processing. Third, for multi-TCP connection modes, it can increase the number of TCP connections that the epoll mechanism can process in a batch, making it more efficient for batch data.

[0052] This application's embodiments optimize the epoll mechanism, thereby reducing the resource waste (CPU resources) caused by the epoll mechanism.

[0053] The embodiments of this application will be described in detail below with reference to the accompanying drawings and specific examples and application scenarios.

[0054] Reference Figure 1 This document illustrates a flowchart of a data interaction method provided in an embodiment of this application, applied to a cloud service system. The cloud service system includes computing nodes and storage nodes, and specifically includes the following steps:

[0055] Step 101: Obtain statistical information on the waiting commands of the file descriptor mechanism in the computing node.

[0056] A cloud service system can include compute nodes and storage nodes. There are typically multiple compute nodes and storage nodes in a cloud service system, but it can also be a single node. In specific implementations, compute nodes are equipped with a file descriptor mechanism. In some embodiments, this file descriptor mechanism can be the epoll mechanism. Specifically, the epoll mechanism is an I / O multiplexing mechanism provided by the Linux kernel for efficiently handling a large number of concurrent I / O requests.

[0057] In cloud service systems, such as high-performance storage systems and protocol stacks, the epoll mechanism implements an efficient model with the following advantages: First, efficient event notification: the epoll mechanism only returns file descriptors where events have occurred, avoiding unnecessary polling and reducing processing overhead. Second, support for large-scale file descriptors: the epoll mechanism can efficiently handle tens of thousands of file descriptors, breaking through the limitations of the traditional select mechanism. Third, an event-driven model: unlike the traditional polling model, the epoll mechanism is event-driven, enabling faster responses to actual events and reducing invalid checks. These advantages make the epoll mechanism perform exceptionally well in high-concurrency environments, especially suitable for high-performance servers and real-time data processing scenarios.

[0058] Specifically, the epoll mechanism works as follows: The compute node creates an epoll instance in kernel mode and registers the file descriptors to be monitored (such as sockets) and the events it is interested in (such as readable data) with the epoll instance. Then, user-mode threads repeatedly call epoll_wait (the core wait function of the epoll event-driven mechanism, which blocks the thread and waits until one or more of the monitored file descriptors have experienced a specified I / O event (such as data arrival for readable data)). When the kernel detects that an event is ready (such as data arrival) on a monitored file descriptor, it indicates that the file descriptor is in a ready state. At this time, epoll_wait returns the ready file descriptor. Thus, user-mode threads can directly process these ready file descriptors without traversing all file descriptors, thereby performing corresponding data I / O operations to transfer data from the kernel to user mode and drive the execution of the user-mode thread's business logic. In this process, after the storage node responds to the data access request sent by the compute node, it stores the target data corresponding to the data access request in the kernel of the compute node. At this time, if there is an event ready on the file descriptor, the file descriptor becomes a ready state, that is, a file descriptor in a ready state.

[0059] In cloud service systems, front-end (compute node) storage typically uses TCP (Transmission Control Protocol) to connect to the back-end (storage node) storage cluster. If a full TCP connection is used, there will be a large number of connections and communication with the back-end. Generally, the number of active TCP connections increases exponentially with the size of the storage volume. Both compute and storage nodes in a cloud service system can have multiple nodes. For ease of explanation, this application's embodiment is based on testing with one compute node and multiple storage nodes. Typically, a storage node has multiple IO threads communicating with each IO thread of the compute node. After a user-space thread creates a TCP connection, the kernel returns a file descriptor. All subsequent operations on this TCP connection (such as reading and writing data) are executed through the corresponding file descriptor. The kernel uses the file descriptor to find the corresponding complete connection structure for processing.

[0060] Reference Figure 2 This is a flowchart of an epoll mechanism for a thread module provided in an embodiment of this application. The flowchart includes one compute node (Node0) and two storage nodes (Node1). Each compute node can include multiple workers (worker0, worker1, and worker2). The workers of the compute node establish data connections with the storage nodes through a channel. The rx subqueue (receive / submit queue) of the workers on the compute node can manage the batch reception (rx) of data requests from the storage nodes through the channel, optimizing processing efficiency by merging and submitting data requests. Additionally, the storage nodes can also receive (rx) data requests sent by the compute nodes.

[0061] Reference Figure 3 This is a storage-computing connection diagram provided in an embodiment of this application. The main implementation scenario of this application is a cloud service system, employing a kernel TCP multi-connection model. There are numerous connections between compute nodes and storage nodes, established via kernel TCP. For compute nodes, the number of TCP connections is related to the number of storage nodes; the more storage nodes, the more TCP connections. In pool1…poolN, there can be a maximum of 500 storage nodes in total. The CPU of the compute nodes can access XSSDs (cloud disks), retrieve data from the storage nodes, and then perform corresponding computations.

[0062] Referring to Table 1, this application provides a table showing the impact of the number of TCP connections on bandwidth:

[0063] Table 1:

[0064]

[0065] As shown in Table 1, the data from the polling mode using the epoll mechanism reveals a non-linear impact on kernel bandwidth performance as the number of TCP connections increases. Specifically, bandwidth decreases by approximately 10% when the number of TCP connections increases from 30 to 960, and by approximately 30% when the number of TCP connections increases from 960 to 7680. Clearly, the overhead of cloud service systems is no longer simply proportional to the number of TCP connections, but rather exhibits a non-linear impact.

[0066] Referring to Table 2, this application embodiment shows the impact of the number of TCP connections on epoll_wait (wait command).

[0067] Table 2:

[0068]

[0069] The statistics in Table 2 represent the number of ready file descriptors returned by epoll_wait (wait command). For example, [0] indicates the number of times the number of ready file descriptors returned is 0, [1] indicates the number of times the number of ready file descriptors returned is 1, and [2,4), [4,8), [8,16) and [16,32) indicate the number of times the number of ready file descriptors returned is greater than or equal to 2.

[0070] As can be seen from Table 2, for the epoll mechanism to poll multiple active TCP connections, the more TCP connections there are, the more times epoll polls will return empty (i.e., the number of times the number of ready file descriptors returned is 0), and the number of ready file descriptors returned is relatively small, for example, only 1, or only 2-4.

[0071] Therefore, in this embodiment of the application, the statistical information of epoll_wait (waiting for commands) of the file descriptor mechanism (epoll mechanism) in the computing node can be obtained. The statistical information records the number of file descriptors in the monitored file descriptor state that are in a ready state for a specified number (such as 0, 1 or more).

[0072] The statistics include at least the total number of calls to wait for commands (total_num) and the number of times the number of ready file descriptors returned is different from the specified number. Specifically, the number of times the number of ready file descriptors returned is different from the specified number can include zero_num (the number of times the number of ready file descriptors returned is 0), one_num (the number of times the number of ready file descriptors returned is 1), and more_num (the number of times the number of ready file descriptors returned is greater than or equal to 2).

[0073] Of course, the above statistical information is only an example. In practical applications, the number of file descriptors returning a ready state can be set to a different specified number of times, depending on the requirements. This application embodiment does not impose any restrictions on this.

[0074] Step 102: Determine the invalid polling ratio of the waiting command based on the statistical information.

[0075] In this embodiment of the application, the invalid polling ratio of epoll_wait (waiting for commands) can be determined based on statistical information. The invalid polling ratio refers to the proportion of the number of times that the number of file descriptors in the ready state among the monitored file descriptors is 0 to the total number of calls. The larger the invalid polling ratio, the greater the proportion of epoll_wait (waiting for commands) running idle, and the more computing resources of the computing nodes are wasted.

[0076] Step 103: Determine the call frequency of the waiting command based on the invalid polling ratio.

[0077] Step 104: Control the threads in the computing node to call the wait command according to the calling frequency to determine the file descriptors in the computing node that are in a ready state. The file descriptors in the ready state are used to store the target data corresponding to the data access request in the kernel of the computing node after the storage node responds to the data access request sent by the computing node. The threads of the computing node interact with the kernel of the computing node to obtain the target data. The file descriptors are registered by the threads of the computing node in the file descriptor mechanism.

[0078] In this embodiment of the application, when determining the invalid polling ratio, the call frequency of epoll_wait (waiting for commands) can be determined based on the invalid polling ratio, so that the call frequency of epoll_wait (waiting for commands) will not be too high or too low, and the proportion of epoll_wait (waiting for commands) idle will be reduced accordingly, thereby reducing the waste of computing resources of computing nodes.

[0079] After determining the frequency of epoll_wait (wait for command) calls, the threads in the compute node can be controlled to call epoll_wait (wait for command) according to the call frequency. This allows the epoll_wait (wait for command) to determine the file descriptors in the ready state. Subsequently, the threads of the compute node can interact with the kernel of the compute node to obtain the target data stored in the kernel of the compute node by the storage node.

[0080] In this embodiment, the cloud service system may include compute nodes and storage nodes. It obtains statistical information on wait commands in the file descriptor mechanism of the compute nodes, determines the invalid polling ratio of wait commands based on the statistical information, determines the call frequency of wait commands based on the invalid polling ratio, and finally controls the threads in the compute nodes to call wait commands according to the call frequency. This identifies file descriptors in the compute nodes that are in a ready state. The ready file descriptors are used to store the target data corresponding to the data access request in the kernel of the compute node after the storage node responds to the data access request sent by the compute node. The threads of the compute node interact with the kernel of the compute node to obtain the target data. The file descriptors are registered by the threads of the compute node in the file descriptor mechanism. This embodiment can determine the invalid polling ratio of wait commands based on the statistical information of wait commands in the file descriptor mechanism of the cloud service system, and then determine the call frequency of wait commands in the compute nodes based on the invalid polling ratio. This avoids the problem of idle wait commands in the file descriptor mechanism of the compute nodes, reduces the number of invalid call times of wait commands, and thus reduces resource waste caused by invalid call times of wait commands in the cloud service system.

[0081] In one embodiment of this application, the number of times the number of file descriptors in the ready state is different from the specified number can include at least the number of times the number of file descriptors in the ready state is 0, and determining the invalid polling ratio of the waiting command based on the statistical information can include:

[0082] The invalid polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 0.

[0083] In this embodiment, the ratio of the number of times the number of file descriptors in the ready state is zero (zero_num) to the total number of calls (total_num) can be used as the invalid polling ratio of epoll_wait (waiting for commands), i.e., zero_num / total_num. Subsequently, the call frequency of epoll_wait (waiting for commands) can be determined based on the invalid polling ratio, thereby ensuring that the call frequency of epoll_wait (waiting for commands) is neither too high nor too low, thus reducing the proportion of epoll_wait (waiting for commands) idle and minimizing the waste of computing resources on computing nodes.

[0084] In the above embodiments, by determining the invalid polling ratio based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 0, the invalidity of epoll_wait (waiting for commands) can be quantified. Then, epoll_wait (waiting for commands) can be adaptively adjusted according to the invalidity, thereby reducing the waste of computing resources of computing nodes.

[0085] In one embodiment of this application, determining the call frequency of the waiting command based on the invalid polling ratio may include:

[0086] When the proportion of invalid polling exceeds a first preset threshold, the frequency of calling the waiting command is reduced.

[0087] When the proportion of invalid polling is less than or equal to a first preset threshold, the frequency of calling the waiting command is increased.

[0088] In some alternative embodiments, the first preset threshold may be 50%.

[0089] In this embodiment, if the invalid polling ratio is greater than a first preset threshold, for example, if the invalid polling ratio is greater than 50%, it indicates that the invalidity of epoll_wait (waiting for commands) is relatively high, and the call frequency of epoll_wait (waiting for commands) can be reduced. If the invalid polling ratio is less than or equal to the first preset threshold, for example, if the invalid polling ratio is less than or equal to 50%, it indicates that the invalidity of epoll_wait (waiting for commands) is relatively low, and the call frequency of epoll_wait (waiting for commands) can be increased.

[0090] To enable those skilled in the art to better understand the embodiments of this application, a specific example is used below to illustrate the process of resolving epoll idling. (Refer to...) Figure 4This is a flowchart of an epoll mechanism detection method provided in an embodiment of this application. The specific process for resolving epoll idle time is as follows: Step 401: Collect statistical information of epoll_wait (waiting for commands), wherein the statistical information may include total_num, zero_num, one_num, and more_num based on thread variables; Step 402: Calculate zero_num / total_num (invalid polling ratio); Step 403: If it is greater than 50%, reduce the call frequency of epoll_wait (waiting for commands); Step 404: If it is less than or equal to 50%, increase the call frequency of epoll_wait (waiting for commands).

[0091] Based on the epoll mechanism, the embodiments of this application have at least the following advantages: Efficient event notification: Only file descriptors with events occurring (ready file descriptors) are processed, avoiding polling of all file descriptors and thus reducing CPU resource consumption. Support for large-scale concurrency: It can effectively manage a large number of file descriptors without significantly increasing time complexity, making it suitable for high-concurrency scenarios. Dynamic updates: Adding and deleting file descriptors does not require re-traversing all file descriptors, making operations more efficient. Event triggering method: More events are merged into a single trigger, reducing duplicate event notifications and further improving performance.

[0092] In the above embodiments, the frequency of epoll_wait (waiting for commands) calls can be adaptively reduced or increased according to the relationship between the invalid polling ratio and the first preset threshold, thereby reducing the idle situation of epoll_wait (waiting for commands) and thus reducing the waste of computing resources of computing nodes.

[0093] In one embodiment of this application, the number of times the number of file descriptors in the ready state returned is a different specified number may at least include the number of times the number of file descriptors in the ready state returned by the wait command is 1 and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2; the step of determining the call frequency of the wait command based on the invalid polling ratio may include:

[0094] The inefficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 1.

[0095] The efficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2.

[0096] The call frequency of the waiting command is determined based on the inefficient polling ratio, the efficient polling ratio, and the invalid polling ratio.

[0097] In this embodiment, the ratio of the number of times the number of ready file descriptors returned is 1 (one_num) to the total number of calls (total_num) can be used as the inefficient polling ratio of epoll_wait (waiting for commands), i.e., one_num / total_num. Conversely, the ratio of the number of times the number of ready file descriptors returned is greater than or equal to 2 (more_num) to the total number of calls (total_num) can be used as the efficient polling ratio of epoll_wait (waiting for commands), i.e., more_num / total_num. Subsequently, the call frequency of epoll_wait (waiting for commands) can be determined based on the inefficient polling ratio, efficient polling ratio, and inefficient polling ratio. This ensures that the call frequency of epoll_wait (waiting for commands) is neither too high nor too low, thereby reducing the proportion of epoll_wait (waiting for commands) idle and minimizing the waste of computing resources on computing nodes.

[0098] In the above embodiments, the inefficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 1, while the efficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2. This allows for a more accurate quantification of the inefficiency and efficiency (efficiency and inefficiency) of epoll_wait (waiting for commands). Consequently, epoll_wait (waiting for commands) can be adaptively adjusted based on the degree of inefficiency and efficiency, thereby better reducing the waste of computing resources on computing nodes.

[0099] In one embodiment of this application, determining the call frequency of the waiting command based on the inefficient polling ratio, the efficient polling ratio, and the invalid polling ratio may include:

[0100] When the proportion of invalid polling exceeds a second preset threshold, the frequency of calling the waiting command is reduced.

[0101] When the proportion of invalid polling is less than or equal to a second preset threshold and the proportion of inefficient polling is greater than a third preset threshold, the frequency of calling the waiting command is reduced.

[0102] When the proportion of invalid polling is less than or equal to a second preset threshold, the proportion of inefficient polling is less than or equal to a third preset threshold, and the proportion of efficient polling is greater than a fourth preset threshold, the call frequency of the waiting command is increased.

[0103] In some embodiments, the second preset threshold can be 50%, the third preset threshold can be 30%, and the fourth preset threshold can be 60%.

[0104] In this embodiment, if the invalid polling ratio is greater than a second preset threshold, for example, if the invalid polling ratio is greater than 50%, it indicates that the invalidity of epoll_wait (waiting for commands) is relatively high, and the call frequency of epoll_wait (waiting for commands) can be reduced; if the invalid polling ratio is less than or equal to the second preset threshold, for example, if the invalid polling ratio is less than or equal to 50%, and the inefficient polling ratio of epoll_wait (waiting for commands) is greater than a third preset threshold, for example, if the inefficient polling ratio is greater than 30%, the call frequency of epoll_wait (waiting for commands) can be reduced; if the invalid polling ratio is less than or equal to the second preset threshold, for example, if the invalid polling ratio is less than or equal to 50%, and the efficient polling ratio of epoll_wait (waiting for commands) is greater than a fourth preset threshold, for example, if the efficient polling ratio is greater than 60%, the call frequency of epoll_wait (waiting for commands) can be increased.

[0105] In the above embodiments, the frequency of epoll_wait (waiting for commands) calls can be reduced or increased more precisely and adaptively based on the relationship between the invalid polling ratio, the inefficient polling ratio, the efficient polling ratio and the preset threshold, thereby reducing the idle situation of epoll_wait (waiting for commands) and thus reducing the waste of computing resources of computing nodes.

[0106] The application of this embodiment has at least the following advantages: 1. Based on kernel TCP, this embodiment adaptively increases or decreases the epoll_wait (wait command) call frequency according to the statistics of epoll_wait (wait command), which can reduce the waste of computing resources and has the characteristics of high bandwidth and low latency, making it suitable for processing large amounts of data. 2. This embodiment is simple to implement and can flexibly manage epoll_wait (wait command), making it more flexible. 4. This embodiment is independent, has low coupling with business modules, and is easy to port.

[0107] Reference Figure 5 This diagram illustrates a structural block diagram of a data interaction device provided in an embodiment of this application, applied to a cloud service system. The cloud service system includes computing nodes and storage nodes, and may specifically include the following modules:

[0108] The statistics information acquisition module 501 is used to acquire statistics on the waiting commands of the file descriptor mechanism in the computing node;

[0109] Invalid polling ratio determination module 502 is used to determine the invalid polling ratio of the waiting command based on the statistical information;

[0110] The call frequency determination module 503 is used to determine the call frequency of the waiting command based on the invalid polling ratio;

[0111] The data interaction module 504 is used to control the threads in the computing node to call the wait command according to the calling frequency, so as to determine the file descriptors in the computing node that are in a ready state. The file descriptors in the ready state are used to store the target data corresponding to the data access request in the kernel of the computing node after the storage node responds to the data access request sent by the computing node. The threads of the computing node interact with the kernel of the computing node to obtain the target data. The file descriptors are registered by the threads of the computing node in the file descriptor mechanism.

[0112] In one embodiment of this application, the statistical information includes at least the total number of times the number of times the number of wait commands is invoked and the number of times the number of file descriptors returning a ready state is different from a specified number.

[0113] In one embodiment of this application, the number of times the number of file descriptors in the ready state is different from the specified number includes at least the number of times the number of file descriptors in the ready state is 0. The invalid polling ratio determination module 502 is used for:

[0114] The invalid polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 0.

[0115] In one embodiment of this application, the call frequency determination module 503 is used for:

[0116] When the proportion of invalid polling exceeds a first preset threshold, the frequency of calling the waiting command is reduced.

[0117] When the proportion of invalid polling is less than or equal to a first preset threshold, the frequency of calling the waiting command is increased.

[0118] In one embodiment of this application, the number of times the number of file descriptors in the ready state returned is a different specified number includes at least the number of times the number of file descriptors in the ready state returned by the waiting command is 1 and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2.

[0119] In one embodiment of this application, the call frequency determination module 503 is used for:

[0120] The inefficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 1.

[0121] The efficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2.

[0122] The call frequency of the waiting command is determined based on the inefficient polling ratio, the efficient polling ratio, and the invalid polling ratio.

[0123] In one embodiment of this application, the call frequency determination module 503 is used for:

[0124] When the proportion of invalid polling exceeds a second preset threshold, the frequency of calling the waiting command is reduced.

[0125] When the proportion of invalid polling is less than or equal to a second preset threshold and the proportion of inefficient polling is greater than a third preset threshold, the frequency of calling the waiting command is reduced.

[0126] When the proportion of invalid polling is less than or equal to a second preset threshold, the proportion of inefficient polling is less than or equal to a third preset threshold, and the proportion of efficient polling is greater than a fourth preset threshold, the call frequency of the waiting command is increased.

[0127] In this embodiment, the cloud service system may include compute nodes and storage nodes. It obtains statistical information on wait commands in the file descriptor mechanism of the compute nodes, determines the invalid polling ratio of wait commands based on the statistical information, determines the call frequency of wait commands based on the invalid polling ratio, and finally controls the threads in the compute nodes to call wait commands according to the call frequency. This identifies file descriptors in the compute nodes that are in a ready state. The ready file descriptors are used to store the target data corresponding to the data access request in the kernel of the compute node after the storage node responds to the data access request sent by the compute node. The threads of the compute node interact with the kernel of the compute node to obtain the target data. The file descriptors are registered by the threads of the compute node in the file descriptor mechanism. This embodiment can determine the invalid polling ratio of wait commands based on the statistical information of wait commands in the file descriptor mechanism of the cloud service system, and then determine the call frequency of wait commands in the compute nodes based on the invalid polling ratio. This avoids the problem of idle wait commands in the file descriptor mechanism of the compute nodes, reduces the number of invalid call times of wait commands, and thus reduces resource waste caused by invalid call times of wait commands in the cloud service system.

[0128] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0129] It should be noted that the embodiments of this application may involve the use of user data. In practical applications, user-specific personal data may be used in the scheme described herein within the scope permitted by applicable laws and regulations, provided that it complies with the applicable laws and regulations of the country (e.g., with the user's explicit consent, with the user being properly notified, etc.).

[0130] This application also provides an electronic device, such as... Figure 6 As shown, it includes a processor 1001, a device interface 1002, a memory 1003, and a bus 1004;

[0131] Memory 1003 is used to store computer programs;

[0132] The processor 1001 executes the above steps when executing the program stored in the memory 1003.

[0133] The bus mentioned in the above terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0134] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0135] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0136] This application also provides a storage medium that, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to perform the data interaction method of the foregoing embodiments.

[0137] The algorithms and displays provided herein are not inherently related to any particular computer, virtual device, or other equipment. The structure required to construct such a device is obvious from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0138] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0139] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together into a single embodiment, figure, or description thereof. However, this method of disclosure should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0140] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0141] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the sequencing device according to this application. This application can also be implemented as a device or apparatus program for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can take the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0142] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0143] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0144] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

[0145] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0146] It should be noted that the various data-related processes in the embodiments of this application are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.

Claims

1. A data interaction method, characterized in that, Applied to a cloud service system, the cloud service system including compute nodes and storage nodes, the method includes: Obtain statistical information on the waiting commands of the file descriptor mechanism in the compute node; the statistical information includes at least the total number of calls to the waiting commands and the number of times the number of file descriptors returning to the ready state is different from a specified number; The proportion of invalid polling for the waiting command is determined based on the statistical information. The frequency of calling the waiting command is determined based on the invalid polling ratio; The waiting command is invoked according to the aforementioned call frequency to determine the file descriptors in the ready state of the computing node. The ready file descriptors are used to store the target data corresponding to the data access request in the kernel of the computing node after the storage node responds to the data access request sent by the computing node. The threads of the computing node interact with the kernel of the computing node to obtain the target data. The file descriptors are registered by the threads of the computing node in the file descriptor mechanism. Wherein, the number of times the number of file descriptors in the ready state returned is different from the specified number includes at least the number of times the number of file descriptors in the ready state returned is 0, and the determination of the invalid polling ratio of the waiting command based on the statistical information includes: The invalid polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 0.

2. The method according to claim 1, characterized in that, Determining the call frequency of the waiting command based on the invalid polling ratio includes: When the proportion of invalid polling exceeds a first preset threshold, the frequency of calling the waiting command is reduced. When the proportion of invalid polling is less than or equal to a first preset threshold, the frequency of calling the waiting command is increased.

3. The method according to claim 1, characterized in that, The number of times the number of file descriptors in the ready state returned is different from the specified number includes at least the number of times the number of file descriptors in the ready state returned by the waiting command is 1 and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2.

4. The method according to claim 3, characterized in that, Determining the call frequency of the waiting command based on the invalid polling ratio includes: The inefficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is 1. The efficient polling ratio is determined based on the total number of calls and the number of times the number of file descriptors in the ready state returned is greater than or equal to 2. The call frequency of the waiting command is determined based on the inefficient polling ratio, the efficient polling ratio, and the invalid polling ratio.

5. The method according to claim 4, characterized in that, The step of determining the call frequency of the waiting command based on the inefficient polling ratio, the efficient polling ratio, and the invalid polling ratio includes: When the proportion of invalid polling exceeds a second preset threshold, the frequency of calling the waiting command is reduced. When the proportion of invalid polling is less than or equal to a second preset threshold and the proportion of inefficient polling is greater than a third preset threshold, the frequency of calling the waiting command is reduced. When the proportion of invalid polling is less than or equal to a second preset threshold, the proportion of inefficient polling is less than or equal to a third preset threshold, and the proportion of efficient polling is greater than a fourth preset threshold, the call frequency of the waiting command is increased.

6. A data interaction device, characterized in that, Applied to a cloud service system, the cloud service system including computing nodes and storage nodes, the device includes: The statistics acquisition module is used to acquire statistics on the waiting commands of the file descriptor mechanism in the computing node; the statistics include at least the total number of calls to the waiting commands and the number of times the number of file descriptors returning to the ready state is different from the specified number. An invalid polling ratio determination module is used to determine the invalid polling ratio of the waiting command based on the statistical information. The call frequency determination module is used to determine the call frequency of the waiting command based on the invalid polling ratio; A data interaction module is used to control the threads in the computing node to call the wait command according to the calling frequency, so as to determine the file descriptors in the computing node that are in a ready state. The file descriptors in the ready state are used to store the target data corresponding to the data access request in the kernel of the computing node after the storage node responds to the data access request sent by the computing node. The threads of the computing node interact with the kernel of the computing node to obtain the target data. The file descriptors are registered by the threads of the computing node in the file descriptor mechanism. The invalid polling ratio determination module is specifically used to determine the invalid polling ratio based on the total number of calls and the number of times the number of returned ready file descriptors is different from a specified number, including at least the number of times the number of returned ready file descriptors is 0.

7. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to execute the instructions to implement the data interaction method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the mobile terminal, the mobile terminal is able to perform the data interaction method as described in any one of claims 1 to 5.