IO delay time statistics method, system, device and storage medium

Abstract

This invention proposes an I / O latency statistics method, system, device, and storage medium. The method includes: in response to detecting a user-layer I / O request, inserting multiple time probes during the execution of the I / O request to obtain the trigger times of key actions in the memory data page dirtying stage, block I / O request generation stage, I / O scheduling stage, driver processing stage, hardware processing stage, and I / O completion stage during the execution of the I / O request; calculating the time consumption of each stage based on the trigger times of the key actions; and calculating the execution latency of the I / O request based on the time consumption of each stage. This invention achieves statistical analysis of the I / O time consumption of each important stage, enabling finer-grained tracking of the I / O link and pinpointing the specific location where I / O latency occurs based on the I / O time consumption.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to an I / O latency statistics method, system, device, and storage medium. Background Technology

[0002] In daily operations and maintenance, we often encounter issues such as application service response latency and application service hangs. For example, database requests may slow down or throughput may decrease at certain times, and in severe cases, the application may hang briefly. From the system level, the output of the iostat command and the records of sar logs may show phenomena such as high iowait, an increase in the number of D-state processes, and increased disk utilization. However, IO problems are very complex, and their root causes are diverse, including uneven IO flow distribution, kernel bugs, hardware bugs, etc. They involve complex IO stacks and may also involve application usage models. It is rare to find the cause of the problem by checking a single piece of code or a single component.

[0003] In related technologies, the performance analysis tools built into the operating system are usually used to find the cause of response latency, such as iostat, sar, systemtap, blktrace, etc. However, these tools can only obtain very limited information and cannot deeply analyze the cause of the problem.

[0004] For example, the await value obtained from the iostat tool can be used to obtain the time taken from the generation of an IO request to its completion on the device. However, when IO latency occurs, iostat cannot distinguish whether the IO latency is due to IO scheduling or hardware issues. The blktrace tool can record the time taken for each step from when an IO request enters the block layer to when the IO is completed, but when encountering IO latency problems, the data analysis from the blktrace tool still cannot distinguish whether the performance problem is on the disk, the disk controller, or the driver level.

[0005] It is evident that the performance analysis tools built into the operating system cannot measure the IO latency of important execution processes in each stage from the generation to completion of an IO request, thus making it impossible to accurately pinpoint the specific location where IO latency occurs. Summary of the Invention

[0006] To address the above problems, the present invention aims to provide an IO latency statistics method, system, device, and storage medium, which realizes the statistics of IO time consumption at each important stage, enables finer-grained tracking of the IO link, and can pinpoint the specific location where IO latency occurs based on IO time consumption.

[0007] To achieve the above objectives, the present invention employs the following technical solution:

[0008] In a first aspect, the present invention discloses an I / O latency statistics method, comprising:

[0009] In response to the detection of user-level IO, multiple time probes are inserted into the execution process of the IO request to obtain the trigger time of key actions during the execution of the IO request; the execution process of the IO request includes the memory data page dirtying stage, block input / output request generation stage, input / output scheduling stage, driver processing stage, hardware processing stage, and input / output completion stage in sequence.

[0010] The time taken for the memory data page dirtying stage, the block input / output request generation stage, the input / output scheduling stage, the driver processing stage, the hardware processing stage, and the input / output completion stage are calculated based on the key action trigger time.

[0011] The execution delay of an I / O request is calculated based on the time consumed in the memory data page dirtying phase, the time consumed in the block I / O request generation phase, the time consumed in the I / O scheduling phase, the time consumed in the driver processing phase, the time consumed in the hardware processing phase, and the time consumed in the I / O completion phase.

[0012] Furthermore, the method of inserting multiple time probe points during the execution of the IO request to obtain the trigger time of key actions during the execution of the IO request includes:

[0013] The dynamic probing tool using packet filters inserts the first probe point during the IO request delivery process to obtain the completion time TT1 of the IO request delivery to the file system layer;

[0014] A dynamic probing tool using packet filters inserts a second time probe point during the process of allocating memory data pages for IO requests, used to obtain the time TT2 when the memory data page corresponding to the IO request is dirtied.

[0015] Furthermore, the method of inserting multiple time probe points during the execution of the IO request to obtain the trigger time of key actions during the execution of the IO request also includes:

[0016] A third time probe point is inserted into the dirty page write-back process using a dynamic probing tool with packet filters to obtain the completion time TT3 for encapsulating dirty pages into block input / output structures;

[0017] A fourth time probe point is inserted into the dirty page write-back process using a dynamic probe tool that uses packet filters to obtain the time TT4 when the block input / output request is generated.

[0018] Furthermore, the method of inserting multiple time probe points during the execution of the IO request to obtain the trigger time of key actions during the execution of the IO request also includes:

[0019] Once a block I / O request is added to the insertion queue, the number of block I / O requests is monitored in real time.

[0020] Once the number of block input / output requests reaches the threshold, the block input / output requests inserted into the queue are placed into the hardware dispatch queue. When the block input / output requests in the hardware dispatch queue are dispatched to the driver layer, the dynamic probing tool of the packet filter is used to insert a fifth time probe point to obtain the time TT5 when the block input / output request is dispatched to the driver layer.

[0021] Furthermore, the method of inserting multiple time probe points during the execution of the IO request to obtain the trigger time of key actions during the execution of the IO request also includes:

[0022] After a block input / output request is dispatched to the driver layer, it is encapsulated into block input / output request data that can be recognized by the controller and disk device, and then submitted by the driver layer to the hardware layer. At this time, a sixth time probe point is inserted using a packet filter dynamic probing tool to obtain the time TT6 when the block input / output request data is submitted to the hardware layer.

[0023] After the block input / output request data is submitted to the hardware layer, it is sent to the storage device through the disk controller, and the storage device performs the data write-to-disk processing; a seventh time probe point is inserted during the write-to-disk process using a dynamic probing tool with a packet filter to obtain the data write-to-disk completion time TT7;

[0024] After the block input / output request data is written to the storage device, the input / output completion process is entered, the hardware interrupt is returned, and the callback function is returned and cleaned up. The dynamic probing tool of the packet filter is used to insert an eighth time probe point in the input / output completion process to obtain the end time TT8 of the input / output completion process.

[0025] Furthermore, the calculation of the time consumption for the memory data page dirtying stage, the block input / output request generation stage, the input / output scheduling stage, the driver processing stage, the hardware processing stage, and the input / output completion stage based on the key action trigger time includes:

[0026] The time PageCacheTime for the dirtying phase of memory data pages can be calculated using the formula PageCacheTime = TT2 - TT1.

[0027] The time consumed in the block input / output request generation phase, BiorequestMakeTime, can be calculated using the formula BiorequestMakeTime = TT4 - TT3.

[0028] The input / output scheduling time IOSchedulerTime is calculated using the formula IOSchedulerTime = TT5 - TT4.

[0029] The time consumed in the driver processing stage is calculated using the formula DriverTime = TT6 - TT5.

[0030] The hardware processing time (HardwareTime) is calculated using the formula HardwareTime = TT7 - TT6.

[0031] The input / output completion time (IOCompleteTime) can be calculated using the formula IOCompleteTime = TT8 - TT7.

[0032] Furthermore, the step of calculating the execution latency of an I / O request based on the time consumed in the memory data page dirtying phase, the time consumed in the block I / O request generation phase, the time consumed in the I / O scheduling phase, the time consumed in the driver processing phase, the time consumed in the hardware processing phase, and the time consumed in the I / O completion phase includes:

[0033] Through formula

[0034] PageCacheTime + BiorequestMakeTime + IOSchedulerTime + DriverTime + HardwareTime + IOCompleteTime = T. This calculates the delay time T during the execution of the IO request.

[0035] Secondly, the present invention also discloses an I / O latency statistics system, comprising:

[0036] The time monitoring module is configured to, in response to the detection of user-layer IO requests, insert multiple time probes during the execution of the IO request to obtain the trigger times of key actions during the IO request execution process. The execution process of the IO request sequentially includes the memory data page dirtying stage, the block I / O request generation stage, the I / O scheduling stage, the driver processing stage, the hardware processing stage, and the I / O completion stage. The stage time calculation module is configured to calculate the time consumption of the memory data page dirtying stage, the block I / O request generation stage, the I / O scheduling stage, the driver processing stage, the hardware processing stage, and the I / O completion stage based on the trigger times of the key actions.

[0037] The statistics module is configured to calculate the execution latency of I / O requests based on the time consumed in the memory data page dirtying phase, the time consumed in the block I / O request generation phase, the time consumed in the I / O scheduling phase, the time consumed in the driver processing phase, the time consumed in the hardware processing phase, and the time consumed in the I / O completion phase.

[0038] Thirdly, the present invention also discloses an I / O latency statistics device, comprising:

[0039] The memory is used to store the I / O latency statistics program;

[0040] A processor, configured to implement the steps of the IO latency statistics method as described above when executing the IO latency statistics program.

[0041] Fourthly, the present invention also discloses a readable storage medium storing an IO latency statistics program, wherein the IO latency statistics program, when executed by a processor, implements the steps of the IO latency statistics method described in any of the above descriptions.

[0042] Compared with existing technologies, the advantages of this invention are as follows: This invention discloses an I / O latency statistics method, system, device, and storage medium. Utilizing a kernel debugging method based on dynamic probing tools using packet filters, probe points are inserted before and after important execution processes in each stage of the I / O request from generation to completion, calculating the I / O time consumption of each important stage, thus achieving finer-grained tracing of the I / O link. This invention implements I / O time analysis at the file system layer, block layer block I / O request generation stage, IOScheduler scheduling stage, driver layer, hardware layer, and I / O complete stage, thereby accurately locating the specific location where I / O latency occurs. This invention effectively solves the problems that iostat cannot distinguish whether I / O latency is due to I / O scheduling or hardware, and that the blktrace tool cannot distinguish whether performance problems occur on the disk, disk controller, or driver level.

[0043] Therefore, it is evident that the present invention has outstanding substantive features and significant progress compared with the prior art, and the beneficial effects of its implementation are also obvious. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0045] Figure 1This is a flowchart of an IO latency time statistics method according to a specific embodiment of the present invention.

[0046] Figure 2 This is a flowchart of another IO latency time statistics method in a specific embodiment of the present invention.

[0047] Figure 3 This is a system architecture diagram of an IO latency time statistics system according to a specific embodiment of the present invention.

[0048] Figure 4 This is a schematic diagram of the structure of an IO delay time statistics device according to a specific embodiment of the present invention.

[0049] In the diagram, 1 is the time monitoring module; 2 is the stage time calculation module; 3 is the statistics module; 101 is the processor; 102 is the memory; 103 is the input interface; 104 is the output interface; 105 is the communication unit; 106 is the keyboard; 107 is the display; and 108 is the mouse. Detailed Implementation

[0050] The core of this invention is to provide a method for statistical analysis of I / O latency. In related technologies, the performance analysis tools built into the operating system are usually used to find the cause of response latency, such as iostat, sar, systemtap, blktrace, etc. However, such tools can only obtain very limited information and cannot deeply analyze the cause of the problem.

[0051] The IO latency statistics method provided by this invention first, in response to the detection of user-layer IO, inserts multiple time probes during the execution of the IO request to obtain the trigger times of key actions during the IO request execution process. The execution process of the IO request sequentially includes a memory data page dirtying stage, a block I / O request generation stage, an I / O scheduling stage, a driver processing stage, a hardware processing stage, and an I / O completion stage. Then, the time consumed in the memory data page dirtying stage, the block I / O request generation stage, the I / O scheduling stage, the driver processing stage, the hardware processing stage, and the I / O completion stage are calculated based on the trigger times of the key actions. Finally, the execution latency of the IO request is calculated based on the time consumed in each stage. Therefore, this invention achieves statistical analysis of the IO time consumed in each important stage, enabling finer-grained tracking of the IO link and pinpointing the specific location of IO latency based on the IO time consumed.

[0052] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0053] The key terms used in this invention will be explained below.

[0054] eBPF, short for "Extended Berkeley Packet Filter," is a packet filtering technology that is an extension of BPF (Berkeley Packet Filter) technology.

[0055] kprobe is a dynamic kernel probing tool that can probe any kernel instruction. Based on the type of probe point, kprobes can be divided into three types: kprobes, jprobes, and kretprobes (also called return probe points). kprobes can be inserted into any instruction location in the kernel, jprobes can only be inserted into the entry point of a kernel function, and kretprobes are executed only when the specified kernel function returns.

[0056] bio, a block input / output structure, represents an I / O request, representing a data request for one or more consecutive sectors of a block device. A sector is the smallest unit of access to a block device, and bio is sent by the file system to the Block Layer.

[0057] A bio request, or block input / output request, represents a single task unit that a block device can process. A request consists of one bio or multiple bios connected together by sectors.

[0058] An I / O scheduler is a method used by the operating system to determine the order in which I / O operations are submitted on a block device. It serves two purposes: to improve I / O throughput and to reduce I / O response time.

[0059] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] See Figure 1 As shown, this embodiment provides a method for calculating I / O latency, including the following steps:

[0061] S1: In response to the detection of user-level IO, multiple time probes are inserted during the execution of the IO request to obtain the trigger time of key actions during the execution of the IO request; the execution process of the IO request includes the memory data page dirtying stage, block input / output request generation stage, input / output scheduling stage, driver processing stage, hardware processing stage, and input / output completion stage in sequence.

[0062] Specifically:

[0063] The kprobe function in ebpf is used to insert the first time probe point during the IO request delivery process, which is used to obtain the completion time TT1 of the IO request delivery to the file system layer.

[0064] Using kprobe in ebpf, a second time probe is inserted during the allocation of memory data pages for I / O requests to obtain the time TT2 when the dirtying of the memory data page corresponding to the I / O request is completed. These two time probes enable monitoring of the triggering time of key actions during the dirtying phase of memory data pages.

[0065] Use kprobe in ebpf to insert a third time probe point in the dirty page write-back process to obtain the completion time TT3 of encapsulating the dirty page into a block input / output structure.

[0066] The kprobe tool in EBPF is used to insert a fourth time probe point in the dirty page write-back process to obtain the block I / O request generation time TT4. These two time probe points enable monitoring of the triggering time of key actions during the block I / O request generation phase.

[0067] Once a block I / O request is added to the insertion queue, its number is monitored in real time. When the number of block I / O requests reaches a threshold, the requests are moved from the insertion queue to the hardware dispatch queue. When a block I / O request from the hardware dispatch queue is dispatched to the driver layer, a fifth time probe is inserted using kprobe in EBPF to obtain the time TT5 when the request is dispatched to the driver layer. This insertion of the fifth time probe enables monitoring of the triggering time of key actions during the I / O scheduling phase.

[0068] After a block I / O request is dispatched to the driver layer, it is encapsulated into block I / O request data that can be recognized by the controller and disk device, and then submitted by the driver layer to the hardware layer. At this time, the kprobe function in EBPF is used to insert a sixth time probe point to obtain the time TT6 when the block I / O request data is submitted to the hardware layer. By inserting the sixth time probe point, the triggering time of key actions in the driver processing phase is monitored.

[0069] After block input / output request data is submitted to the hardware layer, it is sent to the storage device via the disk controller, and the storage device performs the data write-to-disk processing. A seventh time probe point is inserted during the write-to-disk process using kprobe in EBPF to obtain the data write-to-disk completion time TT7. This insertion of the seventh time probe point enables the monitoring of the trigger time of key actions in the hardware processing phase.

[0070] After the block input / output request data is written to the storage device, the input / output completion process begins, returning to the hardware interrupt and performing callback function return and cleanup. The `kprobe` function in EBPF is used to insert an eighth time probe point into the input / output completion process to obtain the end time TT8 of the process. This insertion of the eighth time probe point enables the monitoring of the triggering time of key actions during the input / output completion phase.

[0071] S2: Calculate the time consumed in the memory data page dirtying stage, the time consumed in the block input / output request generation stage, the time consumed in the input / output scheduling stage, the time consumed in the driver processing stage, the time consumed in the hardware processing stage, and the time consumed in the input / output completion stage based on the key action trigger time.

[0072] Specifically:

[0073] The time taken for the memory data page dirtying stage is calculated using the formula PageCacheTime = TT2 - TT1; the time taken for the block I / O request generation stage is calculated using the formula BiorequestMakeTime = TT4 - TT3; the time taken for the I / O scheduling stage is calculated using the formula IOSchedulerTime = TT5 - TT4; the time taken for the driver processing stage is calculated using the formula DriverTime = TT6 - TT5; the time taken for the hardware processing stage is calculated using the formula HardwareTime = TT7 - TT6; and the time taken for the I / O completion stage is calculated using the formula IOCompleteTime = TT8 - TT7.

[0074] S3: Calculate the execution delay of the IO request based on the time consumed in the memory data page dirtying stage, the time consumed in the block I / O request generation stage, the time consumed in the I / O scheduling stage, the time consumed in the driver processing stage, the time consumed in the hardware processing stage, and the time consumed in the I / O completion stage.

[0075] Specifically, through the formula

[0076] PageCacheTime + BiorequestMakeTime + IOSchedulerTime + DriverTime + HardwareTime + IOCompleteTime = T. This calculates the delay time T during the execution of the IO request.

[0077] Additionally, it is worth noting that the performance analysis tool iolantency can be used to obtain the I / O time for each stage of a process and the time for each stage of all I / O operations on a disk by using the time statistics corresponding to the above I / O processing stages. This allows us to identify where the I / O performance bottleneck is located and perform further analysis.

[0078] As can be seen, this method enables the statistical analysis of IO time consumption at each important stage, allowing for finer-grained tracking of the IO link and pinpointing the specific location where IO latency occurs based on IO time consumption.

[0079] See Figure 2 As shown, the present invention also discloses an I / O latency statistics method, comprising the following steps:

[0080] 1. User-level I / O instruction issuance: User space calls system APIs to perform data write operations, passing information such as data buffer, write position, and data length to the kernel file system layer.

[0081] 2. PageCache Dirty Page Time Statistics: In the kernel file system layer, the data structure for this I / O operation needs to be described for the first time, including the starting address of the data buffer, the data length, and the write position. At this time, the file system layer allocates a page cache for this I / O operation. First, it searches for the file block to be accessed in the existing page cache. If it is not found, the content to be accessed is loaded from the disk into the page cache. Then, the data is written to the page cache, and the page cache is marked as a dirty page.

[0082] Dirty page writes to disk are performed by a background write-back process, so it is necessary to determine whether the triggering conditions for the write-back operation have been met. The specific triggering conditions for the write-back operation are as follows: (1) The number of dirty pages exceeds the water level limit; (2) User synchronization command; (3) System timed wake-up write-back operation; (4) The time a dirty page stays in the system exceeds the threshold. If the above dirty page write-back triggering conditions are not met, the I / O operation ends.

[0083] When an IO request is sent to the file system layer, the kprobe function in ebpf is used to insert a time probe point TT1. At the point where the page cache corresponding to this IO request is dirtyed, the kprobe method is used to insert a time probe point TT2. The time taken to dirty the page cache is equal to the time TT2 for the page cache corresponding to the IO request to be dirtyed minus the time TT1 for the IO request to be sent to the file system layer.

[0084] 3. Bio request generation time statistics: If any of the triggering conditions for a write-back operation are met, the system will start the dirty page write-back process. The dirty page is encapsulated into a bio structure. Each bio structure contains 256 bio vectors, and each bio vector points to the page cache corresponding to a dirty page.

[0085] After a bio is generated, it is submitted to the general block layer, generating a bio request. If the data length of the bio request is too long and exceeds the limit, the bio is split into multiple bios. If this bio request is physically adjacent to other I / O requests, it is merged into a single bio; otherwise, it exists as a separate bio request.

[0086] At the bio generation point, time probe point TT3 is inserted using kprobe in ebpf. After the bio request is generated and split and merged, time probe point TT4 is inserted using kprobe in ebpf. The bio request generation time is equal to the bio request generation time TT4 minus the bio generation time TT3.

[0087] 4. IO Scheduler Time Statistics: When a bio request is added to the plug queue, to increase data processing throughput, after the number of requests accumulates to a certain level, the system moves the IO requests in the plug queue to the unplug queue, also known as the hardware dispatch queue, according to the system's IO scheduling algorithm. IO requests in the unplug queue are then dispatched to the driver layer, where a time probe point TT5 is inserted using kprobe in EBPF. The IO scheduler phase time equals the time TT5 for the IO request to be dispatched to the driver layer minus the bio request generation time TT4.

[0088] 5. Driver Layer Time Consumption Statistics: When the BIO request enters the driver layer, it is further processed and encapsulated by the driver into data that can be recognized by the controller and disk device, and then submitted to the hardware by the driver. At the hardware level, the kprobe in EBPF inserts a time probe point TT6. The driver layer processing time is equal to the time TT6 when the data is submitted to the hardware minus the time TT5 when the BIO request enters the driver layer.

[0089] 6. Hardware Layer Time Consumption Statistics: The BIO request is submitted to the hardware by the driver, and it travels through the disk controller, cables, network, etc., to reach the storage device. The storage device performs data write-to-disk processing. At the point where data write-to-disk is complete, a time probe point TT7 is inserted using kprobe in EBPF. The hardware layer processing time is equal to the time TT7 at the point where data write-to-disk is complete minus the time TT6 when the data is submitted to the hardware.

[0090] 7. IO Complete Processing Time Statistics: After the IO is written to the disk device, the complete process begins. During this process, a hardware interrupt is returned, and callback functions are executed for return and cleanup. Once all these steps are complete, a time probe point TT8 is inserted using kprobe in ebpf, marking the true completion of an IO request. The IO complete processing time equals the IO complete completion time TT8 minus the time TT7 for data write-to-disk completion.

[0091] Therefore, this method utilizes the kprobe kernel debugging method in ebpf to insert probe points before and after important execution processes in each stage of the I / O request from generation to completion, calculating the I / O time consumption of each important stage, and achieving finer-grained tracing of the I / O link. This invention implements I / O time analysis at the file system layer, block layer block I / O request generation stage, IOScheduler scheduling stage, driver layer, hardware layer, and I / O complete stage, thereby accurately locating the specific location where I / O latency occurs.

[0092] See Figure 3 As shown, the present invention also discloses an IO latency statistics system, including: a time monitoring module 1, a stage time calculation module 2, and a statistics module 3.

[0093] The time monitoring module 1 is configured to, in response to the detection of user-layer IO, insert multiple time probe points during the execution of the IO request to obtain the trigger time of key actions during the execution of the IO request; the execution process of the IO request includes, in sequence, the memory data page dirtying stage, the block input / output request generation stage, the input / output scheduling stage, the driver processing stage, the hardware processing stage, and the input / output completion stage.

[0094] Phase Elapsed Time Calculation Module 2 is configured to calculate the elapsed time of the memory data page dirtying phase, the elapsed time of the block input / output request generation phase, the elapsed time of the input / output scheduling phase, the elapsed time of the driver processing phase, the elapsed time of the hardware processing phase, and the elapsed time of the input / output completion phase based on the trigger time of the key actions.

[0095] Statistics module 3 is configured to calculate the execution delay of IO requests based on the time consumed in the memory data page dirtying stage, the time consumed in the block I / O request generation stage, the time consumed in the I / O scheduling stage, the time consumed in the driver processing stage, the time consumed in the hardware processing stage, and the time consumed in the I / O completion stage.

[0096] This invention discloses an IO latency statistics system that enables the statistical analysis of IO latency at each critical stage, allowing for finer-grained tracking of the IO link and pinpointing the specific location of IO latency based on IO latency duration. It effectively solves the problems of iostat's inability to distinguish whether IO latency originates from IO scheduling or hardware, and the blktrace tool's inability to differentiate whether performance issues occur on the disk, disk controller, or driver level.

[0097] See Figure 4 As shown, the present invention also discloses an I / O latency time statistics device, including a processor 101 and a memory 102; wherein, when the processor 101 executes the I / O latency time statistics program stored in the memory, it performs the following steps:

[0098] 1. In response to the detection of user-level IO, multiple time probes are inserted into the execution process of the IO request to obtain the trigger time of key actions in the execution process of the IO request; the execution process of the IO request includes the memory data page dirtying stage, block input / output request generation stage, input / output scheduling stage, driver processing stage, hardware processing stage, and input / output completion stage in sequence.

[0099] 2. Calculate the time consumption of the memory data page dirtying stage, the block input / output request generation stage, the input / output scheduling stage, the driver processing stage, the hardware processing stage, and the input / output completion stage based on the trigger time of key actions.

[0100] 3. Calculate the execution delay of the I / O request based on the time consumed in the memory data page dirtying stage, the time consumed in the block I / O request generation stage, the time consumed in the I / O scheduling stage, the time consumed in the driver processing stage, the time consumed in the hardware processing stage, and the time consumed in the I / O completion stage.

[0101] The IO latency statistics device provided in this embodiment may include, but is not limited to, smartphones, tablets, laptops, or desktop computers.

[0102] The processor 101 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 101 may be implemented using at least one hardware form selected from Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 101 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 101 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 101 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0103] The memory 102 may include one or more computer-readable storage media, which may be non-transitory. The memory 102 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 102 is used to store at least the following computer program, which, after being loaded and executed by the processor 101, is capable of implementing the relevant steps of the IO latency statistics method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 102 may also include an operating system and data, and the storage method may be temporary or permanent storage. The operating system may include Windows, Unix, Linux, etc. The data may include, but is not limited to, the data involved in the aforementioned IO latency statistics method.

[0104] Furthermore, the IO latency statistics device in this embodiment may also include:

[0105] Input interface 103 is used to acquire externally imported IO latency statistics programs and save the acquired IO latency statistics programs to the memory 102. It can also be used to acquire various instructions and parameters transmitted from external terminal devices and transmit them to the processor 101 so that the processor 101 can perform corresponding processing using these instructions and parameters. In this embodiment, input interface 103 may specifically include, but is not limited to, a USB interface, a serial interface, a voice input interface, a fingerprint input interface, a hard disk read interface, etc.

[0106] The output interface 104 is used to output various data generated by the processor 101 to a connected terminal device, so that other terminal devices connected to the output interface can obtain the various data generated by the processor 101. In this embodiment, the output interface 104 may specifically include, but is not limited to, a USB interface, a serial interface, etc.

[0107] The communication unit 105 is used to establish a remote communication connection between the server-running business optimization configuration device and the external server, so that the IO latency statistics device can mount the image file to the external server. In this embodiment, the communication unit 105 may specifically include, but is not limited to, a remote communication unit based on wireless communication technology or wired communication technology.

[0108] Keyboard 106 is used to acquire various parameter data or commands input by the user through real-time keystrokes.

[0109] Display 107 is used to display relevant information about the running I / O latency statistics process in real time.

[0110] Mouse 108 can be used to assist users in inputting data and simplifying user operations.

[0111] This invention also discloses a readable storage medium, which includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable hard disk, CD-ROM, or any other form of storage medium known in the art. The readable storage medium stores an I / O latency statistics program, which, when executed by a processor, performs the following steps:

[0112] 1. In response to the detection of user-level IO, multiple time probes are inserted into the execution process of the IO request to obtain the trigger time of key actions in the execution process of the IO request; the execution process of the IO request includes the memory data page dirtying stage, block input / output request generation stage, input / output scheduling stage, driver processing stage, hardware processing stage, and input / output completion stage in sequence.

[0113] 2. Calculate the time consumption of the memory data page dirtying stage, the block input / output request generation stage, the input / output scheduling stage, the driver processing stage, the hardware processing stage, and the input / output completion stage based on the trigger time of key actions.

[0114] 3. Calculate the execution delay of the I / O request based on the time consumed in the memory data page dirtying stage, the time consumed in the block I / O request generation stage, the time consumed in the I / O scheduling stage, the time consumed in the driver processing stage, the time consumed in the hardware processing stage, and the time consumed in the I / O completion stage.

[0115] In summary, this invention enables the statistical analysis of IO time consumption at each important stage, allowing for finer-grained tracking of the IO link and pinpointing the specific location of IO latency based on IO time consumption.

[0116] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The methods disclosed in the embodiments are described simply because they correspond to the systems disclosed in the embodiments; relevant details can be found in the method section.

[0117] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0118] In the embodiments provided by this invention, it should be understood that the disclosed systems, methods, and approaches can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0119] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0120] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit.

[0121] Similarly, in the various embodiments of the present invention, each processing unit can be integrated into a functional module, or each processing unit can exist physically, or two or more processing units can be integrated into a functional module.

[0122] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0123] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0124] The I / O latency statistics method, system, apparatus, and readable storage medium provided by this invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this invention.

Claims

1. A method for calculating I / O latency, characterized in that, include: In response to the detection of user-level IO, multiple time probes are inserted into the execution process of the IO request to obtain the trigger time of key actions during the execution of the IO request; the execution process of the IO request includes the memory data page dirtying stage, block input / output request generation stage, input / output scheduling stage, driver processing stage, hardware processing stage, and input / output completion stage in sequence. The time taken for the memory data page dirtying stage, the block input / output request generation stage, the input / output scheduling stage, the driver processing stage, the hardware processing stage, and the input / output completion stage are calculated based on the key action trigger time. Calculate the execution delay of the I / O request based on the time consumed in the memory data page dirtying phase, the time consumed in the block I / O request generation phase, the time consumed in the I / O scheduling phase, the time consumed in the driver processing phase, the time consumed in the hardware processing phase, and the time consumed in the I / O completion phase. The method involves inserting multiple time probes during the execution of an IO request to obtain the trigger times of key actions during the IO request execution process, including: The dynamic probing tool using packet filters inserts the first probe point during the IO request delivery process to obtain the completion time TT1 of the IO request delivery to the file system layer; A dynamic probing tool using packet filters inserts a second time probe point during the process of allocating memory data pages for IO requests, used to obtain the time TT2 when the memory data page corresponding to the IO request is dirtied.

2. The IO latency statistics method according to claim 1, characterized in that, The method of inserting multiple time probes during the execution of IO requests to obtain the trigger times of key actions during the execution of IO requests also includes: A third time probe point is inserted into the dirty page write-back process using a dynamic probing tool with packet filters to obtain the completion time TT3 for encapsulating dirty pages into block input / output structures; A fourth time probe point is inserted into the dirty page write-back process using a dynamic probe tool that uses packet filters to obtain the time TT4 when the block input / output request is generated.

3. The IO latency statistics method according to claim 2, characterized in that, The method of inserting multiple time probes during the execution of IO requests to obtain the trigger times of key actions during the execution of IO requests also includes: Once a block I / O request is added to the insertion queue, the number of block I / O requests is monitored in real time. Once the number of block input / output requests reaches the threshold, the block input / output requests inserted into the queue are placed into the hardware dispatch queue. When the block input / output requests in the hardware dispatch queue are dispatched to the driver layer, the dynamic probing tool of the packet filter is used to insert a fifth time probe point to obtain the time TT5 when the block input / output request is dispatched to the driver layer.

4. The IO latency time statistics method according to claim 3, characterized in that, The method of inserting multiple time probes during the execution of IO requests to obtain the trigger times of key actions during the execution of IO requests also includes: After a block input / output request is dispatched to the driver layer, it is encapsulated into block input / output request data that can be recognized by the controller and disk device, and then submitted by the driver layer to the hardware layer. At this time, a sixth time probe point is inserted using a packet filter dynamic probing tool to obtain the time TT6 when the block input / output request data is submitted to the hardware layer. After the block input / output request data is submitted to the hardware layer, it is sent to the storage device through the disk controller, and the storage device performs the data write-to-disk processing; a seventh time probe point is inserted during the write-to-disk process using a dynamic probing tool with a packet filter to obtain the data write-to-disk completion time TT7; After the block input / output request data is written to the storage device, the input / output completion process is entered, the hardware interrupt is returned, and the callback function is returned and cleaned up. The dynamic probing tool of the packet filter is used to insert an eighth time probe point in the input / output completion process to obtain the end time TT8 of the input / output completion process.

5. The IO latency time statistics method according to claim 4, characterized in that, The calculation of the time consumption for the memory data page dirtying stage, the block I / O request generation stage, the I / O scheduling stage, the driver processing stage, the hardware processing stage, and the I / O completion stage based on the key action trigger time includes: The time PageCacheTime for the dirtying phase of memory data pages is calculated using the formula PageCacheTime=TT2-TT1. The time consumed in the block input / output request generation phase, BiorequestMakeTime, is calculated using the formula BiorequestMakeTime = TT4 - TT3. The input / output scheduling time IOSchedulerTime is calculated using the formula IOSchedulerTime = TT5 - TT4. The time consumed in the driver processing stage is calculated using the formula DriverTime = TT6 - TT5. The hardware processing time (HardwareTime) is calculated using the formula HardwareTime = TT7 - TT6. The time taken for the input / output completion phase, IOCompleteTime, can be calculated using the formula IOCompleteTime = TT8 - TT7.

6. The IO latency time statistics method according to claim 5, characterized in that, The calculation of the execution latency of an I / O request based on the time consumed in the memory data page dirtying phase, the time consumed in the block I / O request generation phase, the time consumed in the I / O scheduling phase, the time consumed in the driver processing phase, the time consumed in the hardware processing phase, and the time consumed in the I / O completion phase includes: The execution delay time T of the IO request can be calculated using the formula PageCacheTime + BiorequestMakeTime + IOSchedulerTime + DriverTime + HardwareTime + IOCompleteTime = T.

7. An I / O latency statistics system, characterized in that, include: The time monitoring module is configured to respond to the detection of user-layer IO issuance by inserting multiple time probe points during the execution of the IO request to obtain the trigger time of key actions during the execution of the IO request; the execution process of the IO request includes, in sequence, the memory data page dirtying stage, the block input / output request generation stage, the input / output scheduling stage, the driver processing stage, the hardware processing stage, and the input / output completion stage; The phase time calculation module is configured to calculate the time consumption of the memory data page dirtying phase, the time consumption of the block input / output request generation phase, the time consumption of the input / output scheduling phase, the time consumption of the driver processing phase, the time consumption of the hardware processing phase, and the time consumption of the input / output completion phase based on the trigger time of the key actions. The statistics module is configured to calculate the execution latency of I / O requests based on the time consumed in the memory data page dirtying phase, the time consumed in the block I / O request generation phase, the time consumed in the I / O scheduling phase, the time consumed in the driver processing phase, the time consumed in the hardware processing phase, and the time consumed in the I / O completion phase. The method involves inserting multiple time probes during the execution of an IO request to obtain the trigger times of key actions during the IO request execution process, including: The dynamic probing tool using packet filters inserts the first probe point during the IO request delivery process to obtain the completion time TT1 of the IO request delivery to the file system layer; A dynamic probing tool using packet filters inserts a second time probe point during the process of allocating memory data pages for IO requests, used to obtain the time TT2 when the memory data page corresponding to the IO request is dirtied.

8. An I / O latency statistics device, characterized in that, include: The memory is used to store the I / O latency statistics program; A processor, configured to implement the steps of the I / O latency statistics method as described in any one of claims 1 to 6 when executing the I / O latency statistics program.

9. A readable storage medium, characterized in that: The readable storage medium stores an I / O latency statistics program, which, when executed by a processor, implements the steps of the I / O latency statistics method as described in any one of claims 1 to 6.

Images