An abnormal performance simulation method, device, equipment and medium

Abstract

The present application relates to the technical field of artificial intelligence, and is applied to the financial insurance scene, and particularly relates to a performance anomaly simulation method, device, equipment and medium, wherein the fault injection configuration parameters corresponding to a target fault scene in a storage system are acquired, the fault injection configuration parameters include fault type parameters and fault control parameters, a preset hook function is used to capture I / O requests associated with a block device, the I / O requests carry read / write type identifiers, whether the I / O requests belong to the type of faults to be injected is determined based on the read / write type identifiers and the fault type parameters, if yes, the fault injection operation is performed on the I / O requests meeting the conditions based on the fault control parameters, so as to complete the performance anomaly simulation. It can be seen that, in the present application, the fault injection configuration parameters are acquired and the I / O requests are captured, whether to inject faults is dynamically determined based on the read / write type identifiers and the fault type parameters, and the fine fault injection operation is performed, so that the accuracy of the performance anomaly simulation is improved, and the stringent requirements of the financial industry on the performance anomaly test of the storage system are met.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method, apparatus, device, and medium for simulating performance anomalies. Background Technology

[0002] In platform operations within the financial and insurance sector, storage systems are crucial support for core business operations, carrying critical data such as transaction data, customer information, and settlement records. Their performance and stability directly impact the continuity of financial operations, data security, and user experience. Furthermore, financial scenarios place extremely high demands on the reliability of storage systems, requiring them to ensure data consistency and business availability under various extreme conditions. Therefore, comprehensive performance anomaly testing of storage systems is essential.

[0003] However, existing performance anomaly simulation methods lack the ability to fine-tune simulations of storage layer performance anomalies (such as disk read / write latency anomalies), and cannot reproduce problems such as transaction delays and clearing delays caused by storage performance degradation in financial scenarios, thus reducing the accuracy of performance anomaly simulations. Therefore, how to improve the accuracy of performance anomaly simulations to meet the stringent requirements of the financial industry for storage system performance anomaly testing is an urgent technical problem to be solved. Summary of the Invention

[0004] Therefore, in order to address the above-mentioned technical problems, this invention provides a method, apparatus, device, and medium for simulating performance anomalies, which can improve the accuracy of performance anomaly simulation and thus meet the stringent requirements of the financial industry for performance anomaly testing of storage systems.

[0005] A first aspect of this application provides a performance anomaly simulation method, the performance anomaly simulation method comprising: Obtain the fault injection configuration parameters corresponding to the target fault scenario in the storage system, wherein the fault injection configuration parameters include fault type parameters and fault control parameters; I / O requests associated with block devices are captured using a pre-defined hook function, wherein the I / O request carries a read / write type identifier, and the pre-defined hook function is deployed at the kernel level. Based on the read / write type identifier and the fault type parameter, determine whether the I / O request belongs to the type of fault to be injected; If it is determined that the I / O request belongs to the type of fault to be injected, then a fault injection operation is performed on the I / O request that meets the conditions based on the fault control parameters to complete the performance anomaly simulation.

[0006] A second aspect of this application provides a performance anomaly simulation device, the performance anomaly simulation device comprising: The acquisition module is used to acquire fault injection configuration parameters corresponding to the target fault scenario in the storage system, wherein the fault injection configuration parameters include fault type parameters and fault control parameters. The capture module is used to capture I / O requests associated with the block device using a preset hook function, wherein the I / O request carries a read / write type identifier; The determination module is used to determine whether the I / O request belongs to the type of fault to be injected, based on the read / write type identifier and the fault type parameter; The simulation module is used to perform a fault injection operation on the I / O request that meets the conditions based on the fault control parameters if it is determined that the I / O request belongs to the type of fault to be injected, so as to complete the performance anomaly simulation.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the performance anomaly simulation method as described in the first aspect.

[0008] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements the performance anomaly simulation method as described in the first aspect.

[0009] In summary, this invention provides a performance anomaly simulation method, apparatus, device, and medium. It acquires fault injection configuration parameters corresponding to a target fault scenario in the storage system. These parameters include fault type parameters and fault control parameters. A preset hook function captures I / O requests associated with the block device. Each I / O request carries a read / write type identifier. The preset hook function is deployed at the kernel layer. Based on the read / write type identifier and fault type parameters, it determines whether the I / O request belongs to the type of fault to be injected. If the I / O request belongs to the type of fault to be injected, a fault injection operation is performed on the eligible I / O requests based on the fault control parameters to complete the performance anomaly simulation. Therefore, this application improves the accuracy of performance anomaly simulation by acquiring fault injection configuration parameters, capturing I / O requests, dynamically determining whether to inject a fault based on the read / write type identifier and fault type parameters, and performing refined fault injection operations based on the fault control parameters. This meets the stringent requirements of the financial industry for storage system performance anomaly testing. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of an application environment for a performance anomaly simulation method provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a performance anomaly simulation method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a performance anomaly simulation device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

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

[0013] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0014] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0015] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," or "in response to determination." Similarly, the phrase "if determined" or "if matched to [described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once matched to [described condition or event]," or "in response to matched to [described condition or event]."

[0016] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0017] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless otherwise specifically emphasized.

[0018] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0019] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0020] An embodiment of the present invention provides a performance anomaly simulation method, which can be applied to, for example... Figure 1 In this application environment, the terminal device communicates with the server. The terminal device includes, but is not limited to, PDAs, desktop computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, and personal digital assistants (PDAs). The server can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0021] This application can be used in the financial and insurance sectors. Since the stability and performance of storage systems directly affect the continuity of core business operations (such as policy underwriting, claims processing, customer information inquiries, and transaction clearing), performance anomalies such as I / O latency and data read / write failures can lead to business interruptions, customer complaints, and even financial losses. Therefore, the proactive fault injection method in this application's performance anomaly simulation approach can be used to proactively verify the fault tolerance and disaster recovery mechanisms of financial and insurance systems under extreme storage performance anomalies. This can prevent transaction interruptions or risk control misjudgments caused by performance fluctuations, thereby ensuring the security of fund transactions.

[0022] See Figure 2This is a flowchart illustrating a performance anomaly simulation method according to an embodiment of the present invention, as shown below. Figure 2 As shown, this performance anomaly simulation method can be implemented through the following steps.

[0023] S201: Obtain the fault injection configuration parameters corresponding to the target fault scenario in the storage system, wherein the fault injection configuration parameters include fault type parameters and fault control parameters.

[0024] In step S201, a fault scenario library can be pre-created in the storage system. This library contains fault injection configuration parameters. By obtaining the fault injection configuration parameters corresponding to the target fault scenario in the storage system, the system can accurately simulate abnormal storage performance under the target fault scenario. Through the configuration of these parameters, the system can proactively inject faults without affecting actual business operations, thereby achieving comprehensive testing of the financial insurance system under extreme storage performance anomalies. Specifically, the fault injection configuration parameters are key to defining and controlling fault injection behavior. For example, a configuration file can be manually edited to specify the fault type parameter as "read latency" and the fault control parameter as "latency 100 milliseconds". Alternatively, a command-line tool can be used to pass these parameters as input to the simulation program when starting the simulation task. In another implementation, configuration templates for various fault scenarios can be pre-stored in the database. When a specific scenario needs to be simulated, the corresponding fault injection configuration parameters are obtained by querying the database. The storage system refers to the collection of hardware and software used to store and manage data, typically including components such as disk arrays, storage controllers, file systems, and databases. In demanding scenarios such as finance and insurance, the performance and stability of storage systems are crucial for business continuity. Target failure scenarios refer to specific fault conditions pre-defined or expected to be simulated during performance anomaly simulation, such as disk read / write latency, I / O errors, and bandwidth limitations. Each target failure scenario corresponds to a specific fault injection configuration. Fault type parameters describe the specific type of fault to be injected, such as read operation latency, write operation latency, or random errors. These parameters guide the fault injection module in selecting the appropriate fault simulation logic. Fault control parameters control the timing, frequency, or intensity of fault injection, such as the probability, duration, and latency of the injection. These parameters ensure the controllability and repeatability of the fault injection process.

[0025] In this embodiment, by acquiring the fault injection configuration parameters corresponding to the target fault scenario in the storage system, the storage system can perform fault injection simulation operations without affecting actual business operations. Specifically, the target fault scenario is first analyzed in detail to clarify the required fault type parameters and fault control parameters. Then, the matching fault injection configuration parameters are accurately obtained from a preset configuration library. These parameters are carefully designed and verified to accurately simulate various abnormal situations under the target fault scenario. After obtaining the configuration parameters, they are passed to a dedicated fault injection module. This module, based on the parameter instructions, ensures that faults are injected in a timely and appropriate manner during the subsequent operation of the storage system, ensuring that the simulation process is both realistic and effective without causing substantial damage to actual business operations. This enables comprehensive testing of the financial insurance system under extreme storage performance anomalies.

[0026] S202: Capture I / O requests associated with block devices using a preset hook function, wherein the I / O request carries a read / write type identifier, and the preset hook function is deployed at the kernel level.

[0027] In step S202, the pre-defined hook function is cleverly deployed at the kernel level. This level is chosen to more directly and efficiently intercept and process I / O requests related to block devices. As I / O requests flow through the system, the pre-defined hook function acts like a fine net, accurately capturing those I / O requests associated with block devices. These I / O requests carry key read / write type identifiers. By parsing these identifiers, the system can clearly understand the specific operation type of each request—whether it's reading or writing data—thus providing accurate foundational information for subsequent performance anomaly simulations. For example, a kernel module can be developed that registers an I / O request handling function at the block device driver layer. When any I / O request arrives at the block device, this handling function is called, thus capturing the I / O request. The I / O request carries a read / write type identifier, such as a flag indicating whether it's a read or write operation. In another implementation, existing kernel debugging interfaces or virtual file systems can be used to intercept and process I / O requests, thereby achieving I / O request capture without modifying the core kernel code. An I / O request is a data input / output operation instruction issued by an application or operating system to a storage device, such as reading or writing data blocks. Each I / O request typically includes information such as operation type, target address, and data size. A predefined hook function is an interface or mechanism predefined in a program or operating system that allows custom code to be inserted when a specific event occurs. Hook functions allow for the interception, modification, or extension of system behavior without modifying existing code. Predefined hook functions are deployed at the kernel level, the core of the operating system responsible for managing system resources, scheduling processes, and handling interrupts. Deploying hook functions at the kernel level enables fine-grained control and capture of low-level I / O operations. The read / write type identifier is a predefined field in the I / O request data frame. This field has two values: a first identifier and a second identifier. When the first identifier is true, the I / O request is a read request; when the second identifier is true, the I / O request is a write request.

[0028] In this embodiment, by utilizing preset hook functions, I / O requests can be accurately captured, and various performance anomalies that may occur when the storage system processes I / O requests can be fully simulated. This provides strong support for the performance testing and troubleshooting of the storage system, ensuring the authenticity of subsequent fault simulation results and avoiding misjudgments caused by performance distortion of the test environment.

[0029] S203: Based on the read / write type identifier and the fault type parameter, determine whether the I / O request belongs to the type of fault to be injected.

[0030] In step S203, the storage system first obtains the read / write type identifier corresponding to the current I / O request. This identifier clearly indicates whether the request is a read or write operation. Simultaneously, the system also obtains the fault type parameters from the fault injection configuration parameters. These parameters define in detail the various performance anomalies to be simulated, such as latency, increased error rate, and data loss. Next, the system compares and analyzes the read / write type identifier with the fault type parameters, determining, through preset logical judgment rules, whether the current I / O request falls within the category of specific faults to be injected. For example, if the fault type parameter is specified as "read operation latency," and the captured I / O request's read / write type identifier is "read," then the I / O request is identified as the type of fault to be injected. If the fault type parameter is specified as "write operation error," and the captured I / O request's read / write type identifier is "read," then the I / O request does not belong to the type of fault to be injected. In another implementation, a simple mapping table can be maintained to match the fault type parameters with the read / write type identifiers of I / O requests for quick request type determination.

[0031] In one embodiment of the invention, the fault injection configuration parameters further include a target process identifier (PID) and a target block device name. The I / O request also carries process ID information and block device association information. Before determining whether the I / O request belongs to the type of fault to be injected based on the read / write type identifier and fault type parameters, the following steps are included: Determine whether the process ID in the I / O request matches the target process PID in the fault injection configuration parameters; If the process ID in the I / O request matches the target process PID in the fault injection configuration parameters, then the block device association information in the I / O request is matched with the target block device name in the fault injection configuration parameters for string consistency matching. If the matching result is successful, then the step of determining whether the I / O request belongs to the type of fault to be injected is executed based on the read / write type identifier and the fault type parameter.

[0032] Specifically, after capturing an I / O request, a verification mechanism is introduced to check the process ID information and block device association information of the I / O request. When the preset hook function captures an I / O request associated with a block device, the system first checks whether the process ID of the I / O request matches the target process identifier (PID) specified in the fault injection configuration parameters. If they match, it further checks whether the block device name associated with the I / O request matches the target block device name specified in the fault injection configuration parameters. This can be done by using standard string comparison functions for exact matching, or by supporting regular expression matching to match device names with specific patterns. Only when both conditions are met—that is, when the I / O request originates from the target process and acts on the target block device—will the system continue to determine whether the I / O request belongs to the type of fault to be injected based on the read / write type identifier and fault type parameters. Here, the target process identifier (PID) is a unique identifier assigned to each running process by the operating system, and the target block device name is a unique identifier for a specific block device in the storage system.

[0033] For example, consider simulating a performance anomaly when a database service (e.g., process ID 12345) performs a write operation on a specific data disk (e.g., device name " / dev / sdb"). In this case, the fault injection configuration parameters would include the target process ID (PID) as 12345, the target block device name as " / dev / sdb", and the fault type parameter as "write latency". When the system detects an I / O request, it first obtains the process ID information for that request. If the process ID is not 12345, the I / O request will not be injected with a fault. If the process ID is 12345, the system further obtains the block device association information for the I / O request. If this information is not " / dev / sdb" (e.g., " / dev / sda"), the I / O request will also not be injected with a fault. The system will only proceed to determine whether the read / write type identifier of the I / O request is "write" if the process ID of the I / O request is 12345 and the block device association information is " / dev / sdb". Based on the fault type parameter, the system will then execute the corresponding fault injection operation. This technical solution enables fine-grained control over the scope of fault injection, avoiding unnecessary interference with I / O operations on non-target processes or non-target block devices. This makes the performance anomaly simulation more realistic and controllable, thereby improving the reliability and effectiveness of subsequent fault injection.

[0034] In one embodiment of the invention, determining whether an I / O request belongs to the type of fault to be injected is based on a read / write type identifier and a fault type parameter, including: Based on the read / write type identifier, collect multiple IO operation data of the I / O request within a preset period; Calculate the mean of the multiple IO operation data, and then input the mean into a pre-obtained fault type model, which is pre-constructed based on the IO operation data of multiple normal disks in a distributed cluster; Detect whether the fault type model meets the preset requirements after substituting the mean; If the preset requirements are met, the read / write type identifier will be matched with the fault type parameter; If the matching results are consistent, then the target I / O request is determined to belong to the type of fault to be injected.

[0035] Specifically, once a pre-defined hook function captures an I / O request associated with a block device, the system continuously collects multiple I / O operation data points for that I / O request within a pre-defined sampling period, based on the read / write type identifier of the I / O request. This operation data reflects the performance of the I / O request during actual execution. Subsequently, the system calculates the mean of these collected I / O operation data points and inputs this mean into a pre-built fault type model to preliminarily assess the performance status of the I / O request. The mean calculation can be performed using a weighted average or exponential moving average method, applying metrics such as latency, throughput, or IOPS for all I / O requests within the sampling period. The fault type model can be a statistical model, such as a classifier built based on a Gaussian Mixture Model (GMM) or Support Vector Machine (SVM). This model, during its training phase, learns and defines the "normal" performance boundaries and characteristics by analyzing a large amount of I / O operation data from normal disks. This fault type model, trained on I / O operation data from multiple normal disks in a distributed cluster, can identify whether the performance of an I / O request deviates from the normal baseline. By checking whether the fault type model after inputting the mean meets preset requirements, the system can initially screen out I / O requests whose performance may be abnormal. Only when the performance of an I / O request is initially identified as potentially abnormal by the fault type model, i.e., meeting the preset requirements, will the system further perform a precise match between the read / write type identifier of the I / O request and the preset fault type parameters. This matching process aims to accurately determine whether the I / O request truly belongs to the type of fault to be injected. If the matching result is consistent, i.e., the read / write type of the I / O request matches the preset fault type parameters, the system will ultimately determine that the target I / O request belongs to the type of fault to be injected and perform subsequent fault injection operations accordingly. Through the above technical solution, the actual performance status of I / O requests can be identified more accurately, enabling fault injection operations to precisely target I / O requests that not only match the type but also whose actual performance conforms to the target fault scenario. This significantly improves the realism and effectiveness of performance anomaly simulations, avoiding the erroneous injection of I / O requests that are operating normally or do not conform to fault characteristics. As a result, the simulation results are more valuable and help to more accurately assess the system's behavior and recovery capabilities under specific performance anomalies.

[0036] It should be noted that the preset requirement can refer to the probability value or confidence level output by the model reaching a certain threshold. For example, if the model determines that the probability of the current I / O behavior being "normal" is lower than a certain percentage, it is considered that it does not meet the preset requirement. Alternatively, the preset requirement can also be that the classification result output by the model directly indicates a certain "abnormal" state, or that the I / O performance indicators calculated by the model (such as the mean latency) exceed the upper or lower limits of the normal range.

[0037] In this embodiment, by using a dual matching of read / write type identifier and fault type parameter, it is possible to accurately determine whether an I / O request belongs to the type of fault to be injected, strictly limiting the scope of fault injection requests, thereby ensuring the accuracy and effectiveness of fault injection. This allows subsequent performance simulations to be closer to actual operating scenarios, thus effectively evaluating the storage system's ability to cope with various performance anomalies and its stability.

[0038] S204: If it is determined that the I / O request belongs to the type of fault to be injected, then perform a fault injection operation on the I / O request that meets the conditions based on the fault control parameters to complete the performance anomaly simulation.

[0039] In step S204, if it is determined that the I / O request belongs to the type of fault to be injected, a fault injection operation is performed on the I / O request that meets the conditions based on the fault control parameters to complete the performance anomaly simulation. The fault injection operation can include, but is not limited to, the following methods: simulating data corruption or errors by modifying the data content of the I / O request; simulating network latency or slow storage device response by delaying the response time of the I / O request; and simulating storage device failure or connection interruption by rejecting or discarding the I / O request. These fault injection operations can be flexibly configured and combined according to actual needs and preset fault control parameters to simulate various complex performance anomaly scenarios. Specifically, a fault injection operation refers to a specific operation performed on the I / O request that meets the conditions according to the fault injection configuration parameters to simulate performance anomalies. This operation may include introducing delays, returning errors, or discarding requests. For example, if the fault control parameter is specified as "delay 50 milliseconds," then a 50-millisecond delay is introduced into the I / O request identified as the type of fault to be injected before it is sent to the actual block device. If the fault control parameter is specified as "Return I / O Error", an error code is returned directly to the application that initiated the I / O request without forwarding the request. In another implementation, fault injection can be performed on the I / O request based on fault control parameters, such as a probability value. For example, if the probability is 50%, half of the eligible I / O requests are randomly selected for fault injection.

[0040] In one embodiment of the invention, the fault control parameters include probability control parameters, and the step of performing a fault injection operation on the I / O requests that meet the conditions based on the fault control parameters to complete the performance anomaly simulation includes: Call the random number generator function to generate random integers between 0 and 99; The random integer is compared with the probability control parameter to obtain the comparison result; Based on the comparison results, it is determined whether the I / O request should perform a fault injection operation; If it is determined that the I / O request will perform a fault injection operation, then a dynamic link library is loaded according to the fault injection operation, wherein the dynamic link library is used to store various types of simulated performance anomalies; Obtain target simulated fault information corresponding to the target fault scenario in the storage system, and retrieve the target simulated performance anomaly corresponding to the target simulated fault information from the dynamic link library; The target simulated performance anomaly is injected into the process under test to complete the performance anomaly simulation.

[0041] Specifically, the system first determines whether an I / O request belongs to the type of fault to be injected based on read / write type identifiers and fault type parameters. To avoid over-simulation and uncontrolled system behavior that might result from injecting faults into all eligible I / O requests, this scheme introduces a probability control mechanism. Specifically, for each I / O request identified as a fault to be injected, the system calls a random number generation function to generate a random integer between 0 and 99. This random integer is used as the basis for judgment and compared with a preset probability control parameter. The probability control parameter is a pre-set threshold used to control the frequency or proportion of fault injection. For example, if the probability control parameter is set to 50, it means there is a 50% probability that a fault injection operation will be performed on eligible I / O requests. The system compares the generated random integer with the probability control parameter. If the random integer is less than or equal to the probability control parameter, the I / O request is determined to require a fault injection operation; otherwise, it is not. If it is determined that the I / O request requires a fault injection operation, the system loads the corresponding dynamic link library according to the preset fault injection operation type. The dynamic link library (DLL) stores various simulated performance anomalies, such as latency, errors, and data loss. Each performance anomaly corresponds to specific simulation code or functions, which can simulate the corresponding performance anomaly scenario when called. The system further retrieves the target simulated fault information corresponding to the target fault scenario from the storage system. This target simulated fault information can be a string identifier, which the storage system uses to find the corresponding function pointer or object instance in the DLL; alternatively, it can be a structure or JSON object containing detailed parameters such as fault type, severity, and duration. The general fault injection module in the DLL is configured based on these parameters. This information may include fault type, fault severity, and fault duration, used to accurately describe the performance anomaly to be simulated. Based on this information, the system retrieves the corresponding target simulated performance anomaly from the DLL. Finally, the system injects the retrieved target simulated performance anomaly into the process under test. This process may involve modifying the process's memory data, intercepting and modifying the process's I / O requests, or interfering with the normal execution flow of the process in other ways to simulate the effect of a performance anomaly. The probability control parameter is a value used to adjust the frequency or intensity of fault injection. It can be a percentage value, such as an integer between 0 and 100, representing the probability of an I / O request being injected with a fault. This technical solution enables fine-grained control over fault injection operations on I / O requests, simulating various complex performance anomaly scenarios while avoiding excessive interference or damage to the system. This allows testers to more flexibly configure and control the frequency and type of fault injection, ensuring more realistic and controllable performance anomaly simulations. It also helps to more accurately assess the storage system's ability to cope with various performance anomalies and its stability.

[0042] In one embodiment of the invention, determining whether the I / O request should perform a fault injection operation based on the comparison result includes: If the comparison result is that the random integer is less than the probability control parameter, then it is determined whether the cumulative runtime of the IO request from the request start time to the current time has reached the preset delay threshold. If the preset delay threshold is not reached, the time difference between the current cumulative running time and the preset delay threshold is calculated. Based on the time difference, the usleep function is used to make the cumulative runtime of the I / O request reach the preset delay threshold, and the I / O request is sent to the target block device driver after the delay ends. If the comparison result is that the random integer is greater than or equal to the probability control parameter, then the I / O request is directly sent to the target block device driver.

[0043] Specifically, when the system determines that an I / O request belongs to the type of fault to be injected based on the fault injection configuration parameters and the read / write type identifier of the I / O request, and determines that the I / O request needs to undergo fault injection operation by comparing random numbers with probability control parameters, the solution does not immediately inject a fixed delay. Instead, it first checks the actual cumulative runtime of the I / O request from the start of its processing to the current moment. This cumulative runtime can be determined by recording its start timestamp when the I / O request is captured and calculating the difference between the current time and the start timestamp when a determination is needed; alternatively, the system can maintain a timer or counter for each I / O request and update its consumed time or processing cycle in real time. If the cumulative runtime has reached or exceeded the preset delay threshold, it indicates that the I / O request has naturally experienced sufficient delay. At this point, there is no need to introduce additional delay, and the I / O request can be directly sent to the target block device driver.

[0044] Conversely, if the accumulated runtime has not yet reached the preset delay threshold, the system will precisely calculate the required delay difference and use mechanisms such as the `usleep` function to pause the I / O request for that time difference. This ensures that the total runtime of the I / O request reaches the preset delay threshold. The `usleep` function is a commonly used system call that pauses the current process or thread for a specified number of microseconds, thus precisely introducing the required delay. Besides the `usleep` function, other kernel-level timer mechanisms can also be used, such as setting a timer and waking up the I / O request processing flow after the timer expires, to achieve precise delay control. This mechanism effectively avoids unnecessary repeated delays for already slow I / O requests and ensures that the delay injected into fast I / O requests achieves the expected minimum effect, making the simulated performance anomalies more consistent and controllable. Simultaneously, for I / O requests that are determined by probability control parameters to require no fault injection, the system will directly send them to the target block device driver to ensure normal execution, thereby maintaining the overall randomness and realism of the simulation. The above technical solution ensures that every I / O request injected with a delay fault can reach or exceed a minimum expected latency time, making the simulated performance anomalies more stable, controllable, and consistent with real-world scenarios. It not only avoids unnecessary repeated delays for already slow I / O requests but also ensures that the delay injected into fast I / O requests has a sufficient impact, greatly improving the accuracy and effectiveness of performance anomaly simulation. This allows the simulation results to more realistically reflect the behavior of the storage system under specific fault conditions.

[0045] In one embodiment of the invention, after completing the performance anomaly simulation, the process includes: Establish a real-time monitoring link to continuously collect the operational status data of the fault injection operation. The operational status data includes the process execution progress, the target object response status, and the fault activation identifier. Obtain a set of termination trigger conditions, wherein the set of termination trigger conditions includes preset duration control parameters; Based on the operational status data, determine whether the fault injection operation satisfies the termination trigger condition set; If the fault injection operation satisfies the termination triggering condition set, a termination control signal is generated, wherein the termination control signal is used to trigger the fault injection operation to perform a termination operation. The monitoring link collects termination feedback data and determines whether the fault injection operation has been successfully terminated. If the fault injection operation fails to terminate successfully, a termination control signal is sent again based on a preset retry strategy, and a termination failure log is recorded. If the fault injection operation is successfully terminated, a process termination report is generated, which includes the actual runtime, the scope of the fault impact, and the recovery status information.

[0046] Specifically, after simulating performance anomalies, a real-time monitoring link based on a message queue can be established. This link continuously tracks the operational status of the fault injection process. As a bridge between the fault injection module and the control module, this link transmits critical operational status data, such as process execution progress, target object response status, and fault effectiveness indicators. The control module acquires a preset set of termination trigger conditions, including key metrics such as duration control parameters. Based on the real-time operational status data obtained from the monitoring link, the control module continuously determines whether the fault injection process meets these termination conditions. Once met—for example, if the fault injection duration reaches a preset threshold or the system response latency exceeds the maximum allowable range—the control module generates a termination control signal. For instance, when the monitoring module detects that fault injection has been running for 300 seconds, or when the average I / O latency consistently exceeds 100 milliseconds, it generates a termination control signal. This signal can be a JSON message containing specific instructions, sent to the fault injection module through the same message queue. The termination control signal is an instruction or message that instructs the fault injection module to stop its current operation. This signal can be a specific system call, an inter-process communication message, or implemented by modifying a flag in shared memory. The signal is sent to the fault injection module via the monitoring link, triggering it to perform a termination operation, thereby stopping fault injection and attempting system recovery. To verify the effectiveness of the termination operation, the system will again collect termination feedback data via the monitoring link and determine whether the fault injection process has successfully terminated. If termination fails, the system will attempt to send the termination control signal again based on a preset retry strategy and record detailed termination failure logs for subsequent analysis. Conversely, if the fault injection process successfully terminates, the system will generate a comprehensive process termination report, including information such as the actual runtime, the scope of fault impact, and the system recovery status. This technical solution avoids fault injection lasting too long or exceeding expected impact. By introducing a retry strategy and detailed logging, the reliability of the termination operation is improved, and valuable data support is provided for subsequent fault analysis and system recovery. This significantly enhances the safety, controllability, and effectiveness of performance anomaly simulation testing, ensuring the accuracy of test results and protection of the system under test.

[0047] In one embodiment of the invention, the duration control parameters include a fault injection duration threshold and a maximum allowable delay duration threshold. The step of determining whether the fault injection operation satisfies the termination trigger condition set based on the operating status data includes: Extract the actual start time of the fault injection operation from the running status data, calculate the time difference between the current time and the actual start time, and obtain the actual running time. Determine whether the actual runtime is greater than or equal to the fault injection duration threshold; If the actual runtime is greater than or equal to the fault injection duration threshold, then determine whether the response latency of the storage system is greater than or equal to the maximum allowable latency threshold. If the response latency of the storage system is greater than or equal to the maximum allowable latency threshold, then the fault injection operation is determined to meet the termination triggering condition based on the duration control parameter.

[0048] Specifically, by establishing a real-time monitoring link, the system can continuously acquire operational status data, including process execution progress, target object response status, and fault activation identifiers. Based on this, to determine whether the fault injection process meets the termination triggering condition set, this application introduces a duration control parameter, which specifically includes a fault injection duration threshold and a maximum allowable latency threshold. The system extracts the actual start time of the fault injection process from the operational status data and calculates the time difference between the current time and the actual start time to obtain the actual runtime. Subsequently, the system compares the actual runtime with the fault injection duration threshold to determine whether the fault injection has reached the preset duration limit. Simultaneously, the system also monitors the response latency of the storage system in real time and compares it with the maximum allowable latency threshold to assess whether the impact of fault injection on system performance has exceeded acceptable limits. When the actual runtime reaches or exceeds the fault injection duration threshold, or when the response latency of the storage system reaches or exceeds the maximum allowable latency threshold, the system determines that the fault injection process meets the termination triggering conditions based on the duration control parameter. The above technical solutions ensure that the fault injection process will not run indefinitely or continue to execute when it causes excessive negative impact on the system, thereby significantly improving the reliability, controllability and security of fault injection simulation and reducing potential risks to the production or testing environment.

[0049] It should be noted that the fault injection duration threshold is a preset maximum duration allowed for the fault injection process to run continuously, such as 300 seconds or 600 seconds, or it can be dynamically configured based on the complexity of the test scenario and the expected fault duration. The maximum allowable latency threshold is a preset maximum tolerable response latency of the storage system, such as 100 milliseconds or 500 milliseconds, or it can be set based on the baseline performance of the storage system and the acceptable level of performance degradation.

[0050] In this embodiment, when it is determined that the I / O request belongs to the type of fault to be injected, the fault injection operation is then performed on the I / O request that meets the conditions based on the fault control parameters to complete the performance anomaly simulation, realize the fine controllability of fault injection, avoid indiscriminate damage to the test environment, simulate the randomness and dynamism of real faults, and thus realize the fine management and risk control of the performance anomaly simulation process.

[0051] For example, in storage system testing within the financial and insurance sector, a specific scenario needs to be simulated: a core transaction database experiences periodic delays during read operations to assess the transaction system's responsiveness. First, testers configure fault injection parameters. For instance, through a web interface or configuration file, the fault type parameter is set to "read operation latency," and the fault control parameter is set to "fixed latency 100 milliseconds." These parameters are retrieved and loaded by the system. Next, when the transaction system initiates a series of I / O requests to the storage system, such as reading customer account information, these I / O requests are captured by pre-defined hook functions deployed in the kernel layer before reaching the actual block device. Each captured I / O request carries its read / write type identifier; for example, a request to read customer account information would be identified as "read." The system then matches the captured I / O request's read / write type identifier (e.g., "read") with the pre-defined fault type parameter ("read operation latency"). Since they match, the system determines that the I / O request belongs to the type of fault to be injected. Finally, since the I / O request is identified as a type of fault to be injected, the system will perform a fault injection operation on the I / O request according to the fault control parameters ("fixed delay of 100 milliseconds"). The I / O request will be paused for 100 milliseconds before being sent to the actual disk device for processing. As a result, the trading system will experience an additional 100 millisecond delay while waiting for customer account information, thus simulating the performance anomaly of disk read operation latency.

[0052] In summary, this invention provides a performance anomaly simulation method, apparatus, device, and medium. It acquires fault injection configuration parameters corresponding to a target fault scenario in the storage system. These parameters include fault type parameters and fault control parameters. A preset hook function captures I / O requests associated with the block device. Each I / O request carries a read / write type identifier. The preset hook function is deployed at the kernel layer. Based on the read / write type identifier and fault type parameters, it determines whether the I / O request belongs to the type of fault to be injected. If the I / O request belongs to the type of fault to be injected, a fault injection operation is performed on the eligible I / O requests based on the fault control parameters to complete the performance anomaly simulation. Therefore, this application improves the accuracy of performance anomaly simulation by acquiring fault injection configuration parameters, capturing I / O requests, dynamically determining whether to inject a fault based on the read / write type identifier and fault type parameters, and performing refined fault injection operations based on the fault control parameters. This meets the stringent requirements of the financial industry for storage system performance anomaly testing.

[0053] Please see Figure 3 , Figure 3 This is a schematic diagram of the performance anomaly simulation device provided in an embodiment of the present invention. This performance anomaly simulation device corresponds one-to-one with the performance anomaly simulation method in the above embodiments. Please refer to [link / reference] for details. Figure 2 as well as Figure 2 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 3 The performance anomaly simulation device 30 includes: an acquisition module 31, a capture module 32, a calculation module 33, and a simulation module 34.

[0054] The acquisition module 31 is used to acquire the fault injection configuration parameters corresponding to the target fault scenario in the storage system, wherein the fault injection configuration parameters include fault type parameters and fault control parameters. The capture module 32 is used to capture I / O requests associated with the block device using a preset hook function, wherein the I / O request carries a read / write type identifier; The determination module 33 is used to determine whether the I / O request belongs to the type of fault to be injected based on the read / write type identifier and the fault type parameter; The simulation module 34 is used to perform a fault injection operation on the I / O request that meets the conditions based on the fault control parameters if it is determined that the I / O request belongs to the type of fault to be injected, so as to complete the performance anomaly simulation.

[0055] Optionally, the aforementioned determining module 33 is specifically used for: The fault injection configuration parameters also include the target process identifier (PID) and the target block device name, and the I / O request also carries process ID information and block device association information; Determine whether the process ID in the I / O request matches the target process PID in the fault injection configuration parameters; If the process ID in the I / O request matches the target process PID in the fault injection configuration parameters, then the block device association information in the I / O request is matched with the target block device name in the fault injection configuration parameters for string consistency matching. If the matching result is successful, then the step of determining whether the I / O request belongs to the type of fault to be injected is executed based on the read / write type identifier and the fault type parameter.

[0056] Optionally, the aforementioned determining module 33 is specifically used for: Based on the read / write type identifier, collect multiple IO operation data of the I / O request within a preset period; Calculate the mean of the multiple IO operation data and input the mean into a pre-obtained fault type model, which is pre-constructed based on the IO operation data of multiple normal disks in a distributed cluster; Detect whether the fault type model meets the preset requirements after substituting the mean; If the preset requirements are met, the read / write type identifier will be matched with the fault type parameter; If the matching results are consistent, then the target I / O request is determined to belong to the type of fault to be injected.

[0057] Optionally, the simulation module 34 described above is specifically used for: The fault control parameters include probability control parameters; Call the random number generator function to generate random integers between 0 and 99; The random integer is compared with the probability control parameter to obtain the comparison result; Based on the comparison results, it is determined whether the I / O request should perform a fault injection operation; If it is determined that the I / O request will perform a fault injection operation, then a dynamic link library is loaded according to the fault injection operation, wherein the dynamic link library is used to store various types of simulated performance anomalies; Obtain target simulated fault information corresponding to the target fault scenario in the storage system, and retrieve the target simulated performance anomaly corresponding to the target simulated fault information from the dynamic link library; The target simulated performance anomaly is injected into the process under test to complete the performance anomaly simulation.

[0058] Optionally, the simulation module 34 described above is also used for: If the comparison result is that the random integer is less than the probability control parameter, then it is determined whether the cumulative runtime of the IO request from the request start time to the current time has reached the preset delay threshold. If the preset delay threshold is not reached, the time difference between the current cumulative running time and the preset delay threshold is calculated. Based on the time difference, the usleep function is used to make the cumulative runtime of the I / O request reach the preset delay threshold, and the I / O request is sent to the target block device driver after the delay ends; If the comparison result is that the random integer is greater than or equal to the probability control parameter, then the I / O request is directly sent to the target block device driver.

[0059] Optionally, the simulation module 34 described above is specifically used for: Establish a real-time monitoring link to continuously collect the operational status data of the fault injection operation. The operational status data includes the process execution progress, the target object response status, and the fault activation identifier. Obtain a set of termination trigger conditions, wherein the set of termination trigger conditions includes preset duration control parameters; Based on the operational status data, determine whether the fault injection operation satisfies the termination trigger condition set; If the fault injection operation satisfies the termination triggering condition set, a termination control signal is generated, wherein the termination control signal is used to trigger the fault injection operation to perform a termination operation; The monitoring link collects termination feedback data and determines whether the fault injection operation has been successfully terminated. If the fault injection operation fails to terminate, a termination control signal is sent again based on a preset retry strategy, and a termination failure log is recorded. If the fault injection operation is successfully terminated, a process termination report is generated, which includes the actual runtime, the scope of the fault impact, and the recovery status information.

[0060] Optionally, the simulation module 34 described above is further used for: The duration control parameters include a fault injection duration threshold and a maximum allowable delay duration threshold. Extract the actual start time of the fault injection operation from the running status data, calculate the time difference between the current time and the actual start time, and obtain the actual running time. Determine whether the actual runtime is greater than or equal to the fault injection duration threshold; If the actual runtime is greater than or equal to the fault injection duration threshold, then determine whether the response latency of the storage system is greater than or equal to the maximum allowable latency threshold. If the response latency of the storage system is greater than or equal to the maximum allowable latency threshold, then the fault injection operation is determined to meet the termination triggering condition based on the duration control parameter.

[0061] It should be noted that the information interaction and execution process between the above-mentioned units are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0062] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Figure 4 As shown, the computer device of this embodiment includes: at least one processor ( Figure 4 Only one is shown in the diagram), a memory, and a computer program stored in the memory and capable of running on at least one processor, wherein the processor executes the computer program to implement the steps in any of the above-described performance anomaly simulation method embodiments.

[0063] This computer device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 4 The examples of computer devices are merely examples and do not constitute a limitation on computer devices. Computer devices may include more or fewer components than shown in the illustration, or combinations of certain components, or different components, such as network interfaces, displays, and input systems.

[0064] In one embodiment, a computer-readable storage medium is provided that, when the instructions in the computer-readable storage medium are executed by a processor in a computer device, enables the computer device to perform the steps of any embodiment of the performance anomaly simulation method disclosed in this invention, which will not be repeated here. The computer-readable storage medium may be non-volatile or volatile.

[0065] The processor referred to can be a CPU, but it can also be other general-purpose processors, 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, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0066] Memory includes readable storage media, internal memory, etc., wherein internal memory can be the RAM of a computer device, providing an environment for the operation of the operating system and computer-readable instructions stored in the readable storage media. The readable storage media can be the hard drive of a computer device, or in other embodiments, it can be an external storage system of the computer device, such as a plug-in hard drive, SmartMediaCard (SMC), SecureDigital (SD) card, or FlashCard. Furthermore, memory can include both internal storage units and external storage systems of a computer device. Memory is used to store the operating system, cooperative applications, bootloader, data, and other programs, such as program code for computer programs. Memory can also be used to temporarily store data that has been output or will be output.

[0067] Those skilled in the art will understand that implementing all or part of the processes in the above embodiments can be accomplished by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0068] Those familiar with the technical field will understand that, for ease of description and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this invention. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0069] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for simulating performance anomalies, characterized in that, include: Obtain the fault injection configuration parameters corresponding to the target fault scenario in the storage system, wherein the fault injection configuration parameters include fault type parameters and fault control parameters; I / O requests associated with block devices are captured using a pre-defined hook function, wherein the I / O request carries a read / write type identifier, and the pre-defined hook function is deployed at the kernel level. Based on the read / write type identifier and the fault type parameter, determine whether the I / O request belongs to the type of fault to be injected; If it is determined that the I / O request belongs to the type of fault to be injected, then a fault injection operation is performed on the I / O request that meets the conditions based on the fault control parameters to complete the performance anomaly simulation.

2. The performance anomaly simulation method as described in claim 1, characterized in that, The fault injection configuration parameters also include the target process identifier (PID) and the target block device name. The I / O request also carries process ID information and block device association information. Before determining whether the I / O request belongs to the type of fault to be injected based on the read / write type identifier and the fault type parameters, the process includes: Determine whether the process ID in the I / O request matches the target process PID in the fault injection configuration parameters; If the process ID in the I / O request matches the target process PID in the fault injection configuration parameters, then the block device association information in the I / O request is matched with the target block device name in the fault injection configuration parameters for string consistency matching. If the matching result is successful, then the step of determining whether the I / O request belongs to the type of fault to be injected is executed based on the read / write type identifier and the fault type parameter.

3. The performance anomaly simulation method as described in claim 1, characterized in that, The step of determining whether the I / O request belongs to the type of fault to be injected based on the read / write type identifier and the fault type parameter includes: Based on the read / write type identifier, collect multiple IO operation data of the I / O request within a preset period; Calculate the mean of the multiple IO operation data and input the mean into a pre-obtained fault type model, which is pre-constructed based on the IO operation data of multiple normal disks in a distributed cluster; Detect whether the fault type model meets the preset requirements after substituting the mean; If the preset requirements are met, the read / write type identifier will be matched with the fault type parameter; If the matching results are consistent, then the target I / O request is determined to belong to the type of fault to be injected.

4. The performance anomaly simulation method as described in claim 1, characterized in that, The fault control parameters include probability control parameters. The step of performing fault injection operations on eligible I / O requests based on the fault control parameters to simulate performance anomalies includes: Call the random number generator function to generate random integers between 0 and 99; The random integer is compared with the probability control parameter to obtain the comparison result; Based on the comparison results, it is determined whether the I / O request should perform a fault injection operation; If it is determined that the I / O request will perform a fault injection operation, then a dynamic link library is loaded according to the fault injection operation, wherein the dynamic link library is used to store various types of simulated performance anomalies; Obtain target simulated fault information corresponding to the target fault scenario in the storage system, and retrieve the target simulated performance anomaly corresponding to the target simulated fault information from the dynamic link library; The target simulated performance anomaly is injected into the process under test to complete the performance anomaly simulation.

5. The performance anomaly simulation method as described in claim 4, characterized in that, The step of determining whether to perform a fault injection operation on the I / O request based on the comparison result includes: If the comparison result is that the random integer is less than the probability control parameter, then it is determined whether the cumulative runtime of the IO request from the request start time to the current time has reached the preset delay threshold. If the preset delay threshold is not reached, the time difference between the current cumulative running time and the preset delay threshold is calculated. Based on the time difference, the usleep function is used to make the cumulative runtime of the I / O request reach the preset delay threshold, and the I / O request is sent to the target block device driver after the delay ends. If the comparison result is that the random integer is greater than or equal to the probability control parameter, then the I / O request is directly sent to the target block device driver.

6. The performance anomaly simulation method as described in claim 1, characterized in that, After completing the performance anomaly simulation, the following is included: Establish a real-time monitoring link to continuously collect the operational status data of the fault injection operation. The operational status data includes the process execution progress, the target object response status, and the fault activation identifier. Obtain a set of termination trigger conditions, wherein the set of termination trigger conditions includes preset duration control parameters; Based on the operational status data, determine whether the fault injection operation satisfies the termination trigger condition set; If the fault injection operation satisfies the termination triggering condition set, a termination control signal is generated, wherein the termination control signal is used to trigger the fault injection operation to perform a termination operation. The monitoring link collects termination feedback data and determines whether the fault injection operation has been successfully terminated. If the fault injection operation fails to terminate successfully, a termination control signal is sent again based on a preset retry strategy, and a termination failure log is recorded. If the fault injection operation is successfully terminated, a process termination report is generated, which includes the actual runtime, the scope of the fault impact, and the recovery status information.

7. The performance anomaly simulation method as described in claim 6, characterized in that, The duration control parameters include a fault injection duration threshold and a maximum allowable delay duration threshold. The step of determining whether the fault injection operation satisfies the termination trigger condition set based on the operating status data includes: Extract the actual start time of the fault injection operation from the running status data, calculate the time difference between the current time and the actual start time, and obtain the actual running time. Determine whether the actual runtime is greater than or equal to the fault injection duration threshold; If the actual runtime is greater than or equal to the fault injection duration threshold, then determine whether the response latency of the storage system is greater than or equal to the maximum allowable latency threshold. If the response latency of the storage system is greater than or equal to the maximum allowable latency threshold, then the fault injection operation is determined to meet the termination triggering condition based on the duration control parameter.

8. A performance anomaly simulation device, characterized in that, include: The acquisition module is used to acquire fault injection configuration parameters corresponding to the target fault scenario in the storage system, wherein the fault injection configuration parameters include fault type parameters and fault control parameters; The capture module is used to capture I / O requests associated with the block device using a preset hook function, wherein the I / O request carries a read / write type identifier; The determination module is used to determine whether the I / O request belongs to the type of fault to be injected, based on the read / write type identifier and the fault type parameter; The simulation module is used to perform a fault injection operation on the I / O request that meets the conditions based on the fault control parameters if it is determined that the I / O request belongs to the type of fault to be injected, so as to complete the performance anomaly simulation.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the performance anomaly simulation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the performance anomaly simulation method as described in any one of claims 1 to 7.

Images