Construction method and device for system operation lagging, equipment, medium and program product

Abstract

The invention provides a system operation lagging construction method and device, equipment, a medium and a program product. Relates to the technical field of system performance testing. The method comprises the steps that the CPU thread number and a watchdog threshold value of a current system are obtained; on the basis of the CPU thread number and the watchdog threshold value, the duration of the target thread executing busy waiting operation is calculated through a preset formula; initializing a spin lock of a kernel mode, and creating target threads of which the number is the same as that of the CPU threads, so that the target threads execute preset processing logic to construct system operation jamming; the preset processing logic comprises the following steps: periodically obtaining a spin lock; responding to the situation that the spin lock is not obtained, and continuing to execute the spin lock obtaining operation; and in response to obtaining the spin lock, executing a busy waiting operation. According to the method, CPU resources are continuously occupied through kernel spin lock competition, and a real system jamming scene is simulated. The busy waiting operation duration is dynamically calculated, it is ensured that the single-thread lock holding time is slightly lower than a watchdog threshold value, and crash of a system triggering unrecoverable is avoided.

Description

Technical Field

[0001] This application relates to the field of system performance testing technology, and in particular to a method, apparatus, device, medium, and program product for constructing a system operation lag test. Background Technology

[0002] In the context of rapid advancements in computer technology, the operating system, as the core intermediary layer between hardware and applications, directly determines the overall system's operational efficiency through its stability and responsiveness. Especially in critical areas such as block storage, virtualization, and real-time control, Linux systems must maintain reliable operation under complex scenarios involving high concurrency and resource contention. This places extremely high demands on the kernel's scheduling mechanism and resource management strategies. Therefore, artificially constructing extreme scenarios, such as system lag, to verify kernel behavior has become a core aspect of operating system testing and optimization. Such tests can effectively expose deep-seated issues such as soft deadlock detection and scheduler response, providing crucial evidence for improving system stability.

[0003] Currently, the industry primarily relies on user-space stress testing tools, such as `stress`, to simulate system load. These tools consume system resources by creating multiple processes or threads to perform CPU-intensive computations, memory allocation, and disk I / O tasks. For example, they might simulate high-load scenarios by concurrently executing floating-point operations to consume CPU resources or by repeatedly requesting memory to trigger page swapping. Furthermore, some tools disrupt system scheduling by frequently creating and destroying processes, indirectly affecting system response speed.

[0004] However, current methods can only simulate user-mode load and cannot address kernel-mode resource contention. They are difficult to reproduce the operational lag caused by prolonged kernel-mode CPU occupation in real-world scenarios. Furthermore, they lack direct control over the kernel synchronization mechanism, making it impossible to accurately construct kernel-mode resource monopoly scenarios. Test results depend on hardware performance, resulting in poor stability and repeatability. Summary of the Invention

[0005] The system operation lag construction method, apparatus, device, medium and program product provided in the embodiments of this application are used to realize kernel mode resource competition and construct system operation lag phenomenon.

[0006] In a first aspect, embodiments of this application provide a method for addressing system operation lag, the method comprising:

[0007] Get the current number of CPU threads and watchdog threshold of the system;

[0008] Based on the number of CPU threads and the watchdog threshold, the duration of the target thread's busy-wait operation is calculated using a preset formula.

[0009] Initialize the kernel-mode spinlock and create the same number of target threads as the CPU threads, so that each target thread executes preset processing logic to prevent system operation lag;

[0010] The preset processing logic includes: periodically acquiring the spinlock;

[0011] In response to the failure to acquire the spinlock, the spinlock acquisition operation continues;

[0012] In response to acquiring the spinlock, a busy-wait operation is performed.

[0013] In one possible implementation, it also includes:

[0014] In response to the busy waiting operation being completed, the spinlock is released and the process pauses for a preset time before continuing to execute the spinlock acquisition operation.

[0015] In one possible implementation, after creating the target thread that is the same number as the CPU threads, the method further includes:

[0016] Get the current system's remaining memory;

[0017] At least one memory-consuming thread is created based on a memory block of a preset size and the remaining memory, so that the memory-consuming thread periodically sends memory request requests to the system and keeps occupying the memory until the system memory usage reaches a preset threshold to trigger a memory page replacement operation.

[0018] In one possible implementation, it also includes:

[0019] Get the current CPU utilization of the system;

[0020] The busy wait time adjustment ratio is determined based on the CPU utilization and the preset utilization threshold.

[0021] The busy waiting operation duration is adjusted according to the busy waiting operation duration adjustment ratio to obtain the target busy waiting operation duration, and the busy waiting operation is executed according to the target busy waiting operation duration.

[0022] In one possible implementation, it also includes:

[0023] The target number of threads to receive user input and the busy wait time;

[0024] The system creates a target thread based on the target number of threads input by the user, and executes preset processing logic cyclically based on the busy wait operation duration input by the user to compete for the spinlock to prevent system operation lag.

[0025] In one possible implementation, the response after acquiring the spinlock further includes:

[0026] Store the current thread ID, current time, and lock-holding start flag into a target subfile in the preset log folder;

[0027] In response to the release of the spinlock, the total duration of lock holding at the current time and the CPU utilization during the lock holding period are stored in the target sub-file.

[0028] Secondly, embodiments of this application provide a device for constructing a system operation lag prevention system, comprising:

[0029] The acquisition module is used to obtain the current system's CPU thread count and watchdog threshold.

[0030] The calculation module is used to calculate the duration of the target thread's busy-wait operation based on the number of CPU threads and the watchdog threshold using a preset formula.

[0031] The initialization module is used to initialize the spinlock in kernel mode;

[0032] A creation module is used to create target threads with the same number of CPU threads, so that each target thread executes preset processing logic to prevent system operation from lagging.

[0033] The preset processing logic includes: periodically acquiring the spinlock;

[0034] In response to the failure to acquire the spinlock, the spinlock acquisition operation continues;

[0035] In response to acquiring the spinlock, a busy-wait operation is performed.

[0036] Thirdly, embodiments of this application provide a device for constructing a system with lag, including: a memory and a processor;

[0037] The memory stores computer-executed instructions;

[0038] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0040] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0041] The system operation lag simulation method, apparatus, device, medium, and program products provided in this application embodiment utilize the CPU thread count as a crucial hardware resource indicator. Obtaining this value allows the lag simulation method to be adjusted according to system resources, avoiding inaccurate lag simulations or failure to effectively simulate real-world scenarios. The watchdog threshold is a safety parameter used by the system to prevent program unresponsiveness or deadlock. Obtaining it prevents system protection from being triggered during lag simulations, preventing build interruptions or system anomalies. By combining these two parameters with a preset formula to calculate the busy-wait operation duration, the degree of lag can be scientifically and reasonably controlled. Different CPU thread counts represent different parallel processing capabilities. The watchdog threshold limits the safe running time of the program, and the preset formula dynamically adjusts the busy-wait duration accordingly, making the simulated lag effect more realistic. This method is applicable to various system environments, eliminating the need for extensive manual adjustments and testing for each system, improving versatility and portability, and reducing development and maintenance costs. Initializing a kernel-mode spinlock and creating a target thread with the same number of CPU threads can simulate multi-threaded competition for shared resources, fully utilizing parallel processing capabilities and accurately simulating high-load lag performance. Periodically acquiring spinlocks often results in threads continuously waiting due to lock occupancy, leading to resource waste, execution delays, and stuttering. When a thread successfully acquires the spinlock and performs a busy-wait operation, it further consumes CPU resources, exacerbating the stuttering. This method effectively simulates severe stuttering caused by excessive thread resource consumption, providing a typical test scenario for system performance analysis and optimization, and exhibits good stability and repeatability. Attached Figure Description

[0042] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0043] Figure 1 An application scenario diagram for a system operation lag construction method provided in this application;

[0044] Figure 2 A flowchart illustrating a method for constructing a system operation lag mechanism according to an embodiment of this application;

[0045] Figure 3 A flowchart illustrating a method for constructing a system operation lag mechanism according to another embodiment of this application;

[0046] Figure 4 A schematic diagram of the structure of a device for constructing a system to prevent lag in an embodiment of this application;

[0047] Figure 5 This is a schematic diagram of the structure of a construction device for system operation lag provided in an embodiment of this application.

[0048] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0049] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0050] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0051] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0052] In today's rapidly evolving computer technology landscape, the operating system plays a crucial role as the core intermediary layer between hardware and applications. Its stability and responsiveness are decisive for the overall system performance. Linux systems must operate stably and reliably in complex environments such as high-concurrency processing and intense resource contention, posing extremely stringent challenges to the kernel's scheduling algorithms and resource allocation strategies. Therefore, artificially creating extreme usage scenarios, such as system lag, to test the kernel's performance under special conditions has become a key step in operating system testing and optimization. Currently, the industry primarily utilizes user-space stress testing tools, such as `stress`, to simulate system load. These tools generate multiple processes or threads, causing them to perform high-intensity CPU calculations, memory allocation, and disk I / O tasks, thereby consuming system resources. For example, multiple processes or threads may simultaneously perform floating-point operations to consume CPU resources, or repeatedly request memory space to trigger page replacement operations, thus simulating a high-load system state. Additionally, some tools frequently create and destroy processes, interfering with the system's scheduling mechanism and indirectly affecting system responsiveness. However, these methods can only simulate user-mode load and cannot delve into kernel mode to simulate resource contention, making it difficult to reproduce the operational lag issues caused by prolonged CPU occupation in real-world scenarios. Furthermore, these methods lack direct control over kernel synchronization mechanisms and cannot accurately construct scenarios where kernel resources are exclusively occupied. Additionally, test results are significantly affected by hardware performance, and stability and repeatability are unsatisfactory.

[0053] Therefore, when facing technical problems in existing technologies, in order to construct system operation lag more scientifically and reasonably, it is necessary to obtain the number of CPU threads and the watchdog threshold of the current system. Different thread numbers mean different capabilities of the system in handling multitasking; the watchdog threshold is a parameter related to the system's safety mechanism used to monitor and prevent programs from being unresponsive for a long time or deadlocking, which limits the safe running time range of the program. Obtaining these two parameters can provide a basis for subsequent lag scenario construction, avoiding inaccurate lag effects or inability to effectively simulate real scenarios due to not considering differences in system hardware. In order to ensure that the constructed lag effect can simulate the lag situations that may occur in the actual system, and not become unrecoverable due to excessively long lag times, a preset formula is used in combination with the number of CPU threads and the watchdog threshold to calculate the busy-wait time of the target thread. The preset formula can dynamically adjust the busy-wait time according to these factors, so that suitable lag scenarios can be constructed in different system environments. In order to simulate the competition for shared resources in a multi-threaded environment and more accurately simulate the lag performance of the system under high load, a kernel-mode spinlock is initialized, and a target thread with the same number of CPU threads is created. Spin locks are a synchronization mechanism used to protect shared resources. In a multi-threaded environment, multiple threads may compete for this lock resource simultaneously. Creating a number of target threads equal to the number of CPU threads can fully utilize the system's parallel processing capabilities, putting the system under high load. Each target thread executes pre-defined processing logic to create system lag. When a thread fails to acquire the spin lock, it continues to attempt to acquire it. In most cases, because the lock is already held by other threads, the thread will remain in a state of waiting to acquire the lock. This continuous competition and waiting process leads to wasted system resources and delays in thread execution, thus continuously creating the effect of system lag. When a thread successfully acquires the spin lock, it performs a busy-wait operation. The busy-wait operation causes the thread to continuously consume CPU time in a loop without performing any useful work. This further consumes CPU resources, preventing other threads from acquiring CPU time slices in time, exacerbating the system lag. In this way, we can more effectively simulate severe lag caused by some threads excessively consuming resources in the system, providing a more typical test scenario for system performance analysis and optimization.

[0054] Figure 1 This is an application scenario diagram illustrating the construction method for reducing system lag provided in this application, such as... Figure 1As shown in the diagram, the scenario diagram corresponding to the system operation lag construction method provided in this application includes: a server under test 101, a monitoring terminal 102, and a system operation lag construction device 103. Optionally, the system operation lag construction device 103 can be integrated into the server under test 101, such as existing in the form of a kernel module, or it can be deployed separately as an independent device and communicate with the server under test 101 through a kernel interface.

[0055] Understandably, after remotely logging into the server under test 101 via monitoring terminal 102, testers can trigger a build process that causes system lag. If it is necessary to verify the stability of the server under high concurrency lock contention, the tester sends a start command, and the build device 103 that causes system lag begins to execute preset logic; if it is necessary to terminate the test, a stop command can be sent to resolve the lag.

[0056] Optionally, when the system operation lag device 103 is integrated into the server under test 101, if it exists in the form of a kernel module, the tester can control the start and end of the test by loading and unloading the module.

[0057] Specifically, the tester initiates a lag test request on monitoring terminal 102. After receiving the request, the system lag detection device 103 first obtains the current number of CPU threads and the watchdog threshold. Using a preset formula, it calculates the busy-wait duration of the target thread based on these parameters. Subsequently, the device initializes a kernel-mode spinlock and creates a target thread with the same number of CPU threads. Each target thread enters a loop logic: continuously attempting to acquire the spinlock; if unsuccessful, it maintains a spin; if acquired, it performs a busy-wait operation, releases the lock, briefly sleeps, and then repeats the competition. After the test, the tester sends a stop command through monitoring terminal 102. The system lag detection device 103 destroys the target thread, releases the spinlock, and the tested server 101 resumes normal response.

[0058] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0059] Figure 2 A flowchart illustrating a method for constructing a system operation lag mechanism according to an embodiment of this application is shown below. Figure 2As shown, the execution subject of this embodiment is a system operation lag construction device. This device can be implemented through a computer program, or through a medium storing the relevant computer program, such as a USB flash drive and / or optical disc, or through a physical device integrating or installing the relevant computer program, such as a chip or a system operation lag construction device. The system operation lag construction device can be a server, server cluster, etc. The system operation lag construction method provided in this embodiment includes the following steps:

[0060] S201. Obtain the current number of CPU threads and watchdog threshold of the system.

[0061] The number of CPU threads refers to the number of logical CPU cores in the current system that can independently execute tasks. For example, an 8-core, 16-thread CPU has 16 threads.

[0062] The watchdog threshold, or kernel parameter `watchdog_thresh`, is measured in seconds and controls the kernel's sensitivity to soft lockups. When a CPU core runs continuously in kernel mode for more than this threshold, the system triggers a warning to prevent the core from being permanently occupied.

[0063] Specifically, the current number of CPUs in the system is obtained by accessing the fixed path ` / proc / cpuinfo` in the Linux system, which records hardware configurations. This file contains detailed information for each logical CPU core, such as the processor number and the number of cores. The ` / proc / cpuinfo` file is traversed, and the number of entries containing the `processor` field is counted. Each entry corresponds to one logical CPU thread, and this count represents the total number of CPU threads in the current system. For example, if there are 16 `processor` entries in the file, the number of CPU threads is 16. The watchdog threshold is obtained by reading the path ` / proc / sys / kernel / watchdog_thresh`, which is used to expose kernel parameters in the Linux system. This file directly stores the soft watchdog threshold value in seconds. The file is opened, its text content is read, and converted to an integer to obtain the current watchdog threshold. For example, if the file content is 10, it means the threshold is 10 seconds, meaning that a soft lock-up warning will be triggered if a CPU core is continuously occupied for more than 10 seconds.

[0064] S202. Based on the number of CPU threads and the watchdog threshold, calculate the duration of the target thread's busy-wait operation using a preset formula.

[0065] The target thread refers to the kernel-mode thread created to compete for spinlocks and perform busy-wait operations. Its number is consistent with the number of CPU threads in the system, with the aim of maximizing the use of CPU resources to create stuttering.

[0066] Busy wait operation refers to a thread acquiring a spin lock but not executing actual business logic, instead continuously occupying the CPU for idle time, such as a loop waiting operation. The duration of this operation is the duration of the busy wait operation, which is the core parameter for controlling the intensity of lag.

[0067] The preset formula is a calculation rule pre-set based on the number of CPU threads and the watchdog threshold. It is used to ensure that the busy wait time is long enough to cause a stutter, but does not exceed the watchdog threshold to trigger a soft lock-up warning.

[0068] Optionally, the design principle of the preset formula is that the busy wait time of a single target thread must be less than the watchdog threshold, and the total competition time of all threads should accumulate to significantly consume CPU resources. For example, busy wait time = (watchdog threshold - safety redundancy time) × 1000 ÷ number of CPU threads. Among them, the safety redundancy time is usually set to 1 second to avoid the busy wait time being close to or equal to the watchdog threshold.

[0069] Specifically, after obtaining the number of CPU threads and the watchdog threshold, subtract the safety redundancy time from the watchdog threshold. For example, 10 seconds - 1 second = 9 seconds, which is 9000 milliseconds. Distribute the safe available time evenly among all target threads, i.e., 9000 milliseconds ÷ 16 ≈ 562 milliseconds. The resulting 562 milliseconds is the duration for a single target thread to perform a busy-wait operation.

[0070] Optionally, after the calculation is completed, it is necessary to ensure that the result meets two conditions: the busy-wait time of a single thread is much less than the watchdog threshold to avoid triggering a soft deadlock warning; and the total cumulative time of all threads taking turns holding the lock and executing busy-wait operations should keep the CPU under high load, such as utilization of over 90%, to ensure that the stuttering phenomenon can be reproduced. If the result does not meet the requirements, such as a very small number of threads leading to excessively long single-thread time, the safety redundancy time should be dynamically adjusted, such as increasing it to 2 seconds, and recalculated until the requirements are met.

[0071] S203. Initialize the kernel-mode spinlock and create the same number of target threads as the number of CPU threads, so that each target thread executes the preset processing logic to prevent system operation from lagging.

[0072] The preset processing logic includes: periodically acquiring spinlocks;

[0073] In response to the failure to acquire a spinlock, continue executing the spinlock acquisition operation;

[0074] In response to acquiring the spinlock, a busy-wait operation is performed.

[0075] Among them, kernel-mode spinlocks are a synchronization mechanism used in kernel space to control access to shared resources by multiple kernel threads. When a thread fails to acquire the lock, it continuously checks the lock's state, i.e., spins, without releasing CPU resources, until it successfully acquires the lock.

[0076] The preset processing logic refers to the fixed execution flow followed by the target thread. The core of this process is to continuously occupy the CPU by cyclically competing for spin locks and executing busy waiting to simulate the lag caused by kernel-mode resource competition.

[0077] Among them, periodic acquisition of spin locks means that the target thread does not attempt to acquire the lock all at once, but repeatedly initiates acquisition requests at a fixed frequency to ensure that lock contention continues.

[0078] Specifically, a pre-defined spinlock object is converted from an uninitialized state to an available state through a dedicated interface provided by the system kernel. After initialization, the initial state of the spinlock is unlocked, meaning any thread is allowed to attempt to acquire it. Based on the number of CPU threads acquired in the previous steps, the total number of target threads to be created is determined. Through the kernel thread creation interface, all target threads are started sequentially, bringing them to the ready state and beginning to execute pre-defined processing logic. After each target thread starts, it enters an infinite loop, repeatedly attempting to acquire the spinlock at fixed intervals, such as microseconds. For example, a thread checks the lock's state every 10 microseconds and initiates an acquisition request. If the spinlock is already held by another thread (locked state), the current thread does not release the CPU but continues to repeatedly initiate acquisition requests in the loop, i.e., spin-waiting, continuously occupying its assigned CPU core and preventing other tasks from executing. If the spinlock is unlocked, the current thread successfully acquires the lock and immediately performs a busy-wait operation. It idles for a preset time, such as repeatedly executing meaningless loop counting, without releasing the spinlock and continuously occupying the CPU core.

[0079] Optionally, spinlock attributes can be set to ensure exclusivity, meaning only one thread can hold the spinlock at a time; uninterruptibility can also be set, ensuring the thread cannot be interrupted by other events while acquiring the lock, guaranteeing the continuity of contention. Thread attributes can be set to allocate an independent kernel-mode execution context, such as stack space and thread ID, to each target thread, and set its priority to the kernel's default medium priority. This avoids excessively high priority threads preempting critical system threads, or excessively low priority threads failing to participate in contention.

[0080] Optionally, when starting the target thread, the CPU core to which the thread is bound can be specified using `set_cpus_allowed_ptr` to avoid single-core overload. This simulates cross-core resource contention in a distributed system and verifies the load balancing performance of the multi-core scheduler.

[0081] The system operation lag construction method provided in this application embodiment utilizes the fact that the number of CPU threads is an important hardware resource indicator. Obtaining this value allows the lag construction method to be adjusted according to system resources, avoiding inaccurate lag simulation or failure to effectively simulate real-world scenarios. The watchdog threshold is a safety parameter used by the system to prevent program unresponsiveness or deadlock. Obtaining it prevents system protection from being triggered during lag construction, preventing construction interruption or system anomalies. By combining these two parameters with a preset formula to calculate the busy-wait operation duration, the degree of lag can be scientifically and reasonably controlled. Different numbers of CPU threads represent different parallel processing capabilities. The watchdog threshold limits the safe running time of the program, and the preset formula dynamically adjusts the busy-wait duration accordingly, making the constructed lag effect more realistic. This method is applicable to various system environments, eliminating the need for extensive manual adjustments and testing for each system, improving versatility and portability, and reducing development and maintenance costs. Initializing a kernel-mode spinlock and creating a target thread with the same number of CPU threads can simulate multi-threaded competition for shared resources, fully utilizing parallel processing capabilities and accurately simulating high-load lag performance. Periodically acquiring spinlocks often results in threads continuously waiting due to lock occupancy, leading to resource waste, execution delays, and stuttering. When a thread successfully acquires the spinlock and performs a busy-wait operation, it further consumes CPU resources, exacerbating the stuttering. This method effectively simulates severe stuttering caused by excessive thread resource consumption, providing a typical test scenario for system performance analysis and optimization, and exhibits good stability and repeatability.

[0082] As an optional implementation, based on the above embodiments, it further includes:

[0083] In response to the busy waiting operation being completed, the spinlock is released and the process pauses for a preset time before continuing to execute the spinlock acquisition operation.

[0084] Releasing a spinlock refers to the process where the target thread holding the spinlock, after completing a busy-wait operation, resets the lock's state from locked to unlocked, allowing other threads to acquire the lock.

[0085] The sleep preset duration refers to the period after a thread releases the lock, actively relinquishes CPU resources, and enters a short sleep state, meaning it does not participate in scheduling. The duration is determined by a preset fixed value.

[0086] Specifically, when the target thread performs a busy-wait operation, it monitors its idle time in real time, such as through a kernel timer. When the accumulated time reaches a preset busy-wait duration, the busy-wait operation is considered complete. The target thread calls the kernel-provided spinlock release interface to change the spinlock's state from locked to unlocked. At this time, other threads that are spinning and waiting can detect that the lock has been released and have a chance to acquire it. After releasing the lock, the thread does not immediately initiate lock contention again, but actively calls the kernel's sleep interface, passing in a preset sleep duration. After the thread enters sleep mode, it is removed from the CPU's run queue, temporarily relinquishing CPU resources. When the preset sleep duration ends, the kernel adds the thread back to the run queue, restoring it to the ready state and waiting for CPU scheduling. After the thread is scheduled for execution, it immediately returns to the starting point of the preset processing logic and periodically initiates spinlock acquisition requests again to continue participating in lock contention.

[0087] The system operation lag construction method provided in this application allows for adjusting the rhythm and intensity of system lag by setting a preset sleep duration. By reasonably setting the sleep duration, the degree of lag can be flexibly controlled to meet the needs of different testing scenarios. After a busy-wait operation is completed, immediately reacquiring the spinlock may cause the system to experience a sudden surge in load. The preset sleep duration allows threads to pause lock contention for a period of time, giving other threads some execution time, reducing the sudden load on the system, preventing system crashes or other abnormal situations due to excessive load, and ensuring system stability during testing.

[0088] As an optional implementation, based on the above embodiments, after creating a target thread with the same number of CPU threads, the method further includes:

[0089] Get the current system's remaining memory;

[0090] At least one memory-consuming thread is created based on a memory block of a preset size and the remaining memory. This memory-consuming thread periodically sends memory request requests to the system and maintains its position until the system memory usage reaches a preset threshold, triggering a memory page replacement operation.

[0091] Remaining memory refers to the amount of physical memory that is not currently occupied in the system, and it is a key indicator for judging the idle state of system memory.

[0092] Among them, memory-consuming threads refer to kernel-mode threads that are specifically used to occupy system memory. By continuously requesting and holding memory blocks, they increase the system memory load and, together with CPU lock contention, create complex stuttering scenarios.

[0093] The preset size memory block refers to a pre-defined unit for single memory allocation, such as 100MB. Each time a memory-consuming thread allocates memory, it uses this unit as the unit to ensure that memory usage is controllable.

[0094] Among them, memory page replacement refers to the process by which the kernel temporarily writes some infrequently used memory data to the disk when the system's physical memory is insufficient, thereby freeing up physical memory for newly allocated memory. This operation can significantly increase system overhead and exacerbate lag.

[0095] Specifically, the remaining system memory is obtained by reading the ` / proc / meminfo` file, which records memory usage in the Linux system. This file contains several memory metrics, such as total memory, used memory, and free memory. The values ​​of free memory and freeable cache memory are extracted from ` / proc / meminfo` and summed to obtain the total amount of remaining memory that can be allocated. The required number of threads is calculated based on the total remaining memory and the preset memory block size. For example, if the remaining memory is 3GB and the preset memory block size is 100MB, at least 30 threads are needed to ensure that most of the remaining memory is covered. Each memory-consuming thread is assigned an independent execution context and its priority is set slightly lower than that of the target thread. After each memory-consuming thread starts, it enters a loop logic, requesting memory from the system at fixed intervals, such as once per second, each time requesting a memory block of a preset size, such as 100MB. The requested memory must be marked as non-swappable to ensure that it actually occupies physical memory. After a thread obtains memory, it writes random data, such as filling it with meaningless characters, to prevent the memory from being optimized and released by the kernel, and holds the memory block continuously without performing a release operation. When the total amount of memory requested by all memory-consuming threads reaches a preset threshold, such as 90% of the remaining memory, the system's physical memory is nearly exhausted. The kernel will automatically trigger a memory page swapping operation, writing some infrequently used memory data to the swap partition. At this time, due to frequent disk I / O and memory management overhead, the system's lag will be further aggravated.

[0096] The system operation lag construction method provided in this application adds a memory-consuming thread, further increasing the system load from a memory resource perspective. This more comprehensively simulates the multi-dimensional resource competition scenarios that the system may face in actual operation. Creating a memory-consuming thread can better simulate the system's operating state under such real business scenarios, making the test results more practically valuable. During the continuous memory allocation and occupation by the memory-consuming thread, if a memory leak exists in the system, the memory usage will continuously increase. Even after reaching a preset threshold and triggering a page replacement operation, the memory cannot be released normally. This approach can more effectively detect potential memory leaks in the system, allowing for timely repairs and preventing system crashes or performance degradation due to memory leaks in actual operation.

[0097] As an optional implementation, based on the above embodiments, it further includes:

[0098] Get the current CPU utilization of the system;

[0099] The busy wait time adjustment ratio is determined based on CPU utilization and preset utilization threshold.

[0100] The busy waiting operation duration is adjusted according to the busy waiting operation duration adjustment ratio to obtain the target busy waiting operation duration, and the busy waiting operation is executed according to the target busy waiting operation duration.

[0101] CPU utilization refers to the overall usage ratio of all CPU cores in the current system, usually expressed as a percentage, reflecting the level of CPU activity due to task usage.

[0102] The preset utilization threshold refers to a pre-set CPU utilization benchmark value, such as 70%, which is used to determine the current system load status and serves as a reference standard for adjusting busy wait time.

[0103] The busy wait time adjustment ratio refers to the adjustment coefficient calculated based on the difference between CPU utilization and a preset threshold, such as increasing by 20% or decreasing by 15%, which is used to dynamically change the busy wait time of the target thread to adapt to changes in system load.

[0104] The target busy-wait operation duration refers to the busy-wait duration after adjustment ratio correction. It is the actual duration of the target thread executing the busy-wait operation, ensuring that the lag intensity matches the system load.

[0105] Specifically, the current system CPU utilization is obtained by accessing the ` / proc / stat` file in the Linux system, which records CPU usage. This file contains data such as total CPU runtime, idle time, and user / kernel mode usage time. ` / proc / stat` is read twice at fixed intervals, and the total CPU time and idle time are recorded twice. The difference between the two total times is subtracted from the difference in idle time to obtain the actual CPU usage time during that period. Finally, the current CPU utilization is calculated as: (Used time ÷ Total time difference) × 100%.

[0106] Furthermore, the adjustment ratio is determined based on CPU utilization and a preset threshold. The threshold range and corresponding strategy can be as follows: If the current CPU utilization is below the threshold (e.g., 50% < 70%), it indicates insufficient system load and inadequate lag, requiring an extended busy-wait duration. The adjustment ratio is set to a positive value, such as an increase of 20%. If the current CPU utilization is above the threshold (e.g., 85% > 70%), it indicates excessive system load and potential near-crash, requiring a shortened busy-wait duration. The adjustment ratio is set to a negative value, such as a decrease of 15%. If the current CPU utilization is close to the threshold (e.g., 68%-72%), it indicates moderate lag, and no adjustment is needed.

[0107] Furthermore, the adjustment ratio is refined based on the deviation between the actual utilization rate and the threshold. For example, for every 10 percentage points the utilization rate falls below the threshold, the adjustment ratio increases by 5%. If the utilization rate is 50% and 20 percentage points lower than the threshold, the adjustment ratio is +10%. The new target duration is obtained by multiplying the current busy-wait duration by (1 + adjustment ratio). After the target thread acquires the spinlock again, it no longer uses the original duration but instead performs idle operations according to the new target busy-wait duration. If the CPU utilization rate changes subsequently, the above dynamic adjustment is repeated to ensure that the system always remains in a state where stuttering is controllable.

[0108] The system operation lag construction method provided in this application, by obtaining the current CPU utilization and adjusting the busy-wait operation duration accordingly, enables the constructed lag scenario to more closely resemble the actual load of the system at different times, rather than simply simulating with a fixed busy-wait duration, thereby improving the realism of the simulation. By adjusting the busy-wait operation duration based on CPU utilization, this solution can adapt to systems with various configurations without requiring cumbersome parameter adjustments for each system, thus improving the versatility and flexibility of the testing solution.

[0109] As an optional implementation, based on the above embodiments, it further includes:

[0110] The target number of threads to receive user input and the busy wait time;

[0111] The system creates a target thread based on the target number of threads input by the user, and executes a preset processing logic in a loop based on the busy wait operation duration input by the user, competing for a spin lock to create a system operation lag phenomenon.

[0112] The target number of threads input by the user refers to the number of kernel threads used to compete for spinlocks, which are manually specified by the tester through the terminal or control interface. This number may differ from the number of system CPU threads and can be used to flexibly adjust the intensity of CPU competition.

[0113] Among them, the busy wait operation duration input by the user refers to the duration of the target thread's idle operation after acquiring the spin lock, which is manually set by the tester. It directly determines the CPU usage time of a single thread and is a manual parameter to control the degree of lag.

[0114] Specifically, testers can input the number of threads = 8 and the busy wait duration = 400 milliseconds via terminal commands. The exposed control interface receives the parameters input by the tester. If target threads have been created previously, they are terminated first via the kernel thread destruction interface to release their CPU and memory resources and avoid conflicts between old and new threads. Based on the user-inputted number of threads, the kernel thread creation interface is called to allocate an independent execution context to each new thread and set the same priority as the previously automatically created threads. The newly created target thread is bound to an initialized kernel-mode spinlock, making this lock the object of contention for all threads. After the target thread starts, the busy wait duration calculated by the formula is no longer used; instead, the fixed value input by the user is adopted as the execution benchmark. The thread enters the same preset processing flow as in automatic mode: periodically attempting to acquire the spinlock, and continuously spinning and waiting if unsuccessful; after acquiring the lock, performing a busy wait operation according to the user-input duration; after the busy wait ends, the lock is released, and after a brief sleep, the contention is repeated until the tester terminates the thread.

[0115] The system operation lag simulation method provided in this application embodiment has varying requirements for lag simulation depending on different application scenarios and testing objectives. Receiving the target number of threads input by the user allows testers to flexibly adjust according to actual needs, simulating various scales of thread competition scenarios to meet diverse testing requirements.

[0116] As an optional implementation, based on the above embodiments, in response to acquiring the spinlock, the method further includes:

[0117] Store the current thread ID, current time, and lock-holding start flag into a target subfile in the preset log folder;

[0118] In response to releasing the spinlock, the total duration of the lock holding at the current time and the CPU utilization during the lock holding period are stored in the target sub-file.

[0119] The thread ID is a unique identifier, such as a number, assigned by the kernel to each target thread to distinguish different competing threads and facilitate tracking the lock contention behavior of a single thread.

[0120] The lock start flag is a special flag used to mark the starting point of log recording, such as LOCK_ACQUIRED, which explicitly records the current entry as the starting event of a thread acquiring the lock.

[0121] The preset log folder refers to a pre-specified directory for storing test logs, which centrally manages all records related to lock contention.

[0122] The target subfile refers to a log file created separately for each thread in the preset log folder, such as thread_1.log named after the thread ID, to avoid the mixing of logs from multiple threads and to facilitate the analysis of the behavior of a single thread.

[0123] The total lock holding time refers to the duration from when a thread acquires the spin lock to when it releases the lock. It reflects the actual time a thread holds the lock and is a key indicator for measuring the intensity of stuttering.

[0124] Specifically, when the target thread successfully acquires the spinlock, i.e., switches from a spin-waiting state to a lock-holding state, the logging logic is immediately triggered. The current thread ID is read, the current system time is obtained, and a lock-holding start identifier is generated. A target subfile named after the current thread ID is located in the preset log folder; if it does not exist, it is created automatically. The above information is written to the file according to a fixed format, completing the initial recording. When the thread completes the busy-waiting operation and releases the spinlock, the end information recording logic is triggered. The current system time is obtained, and the lock-acquisition time is subtracted from the lock-release time to obtain the total lock-holding duration. The percentage of CPU cores used by the thread during the lock-holding period is obtained through the kernel CPU statistics interface. End information is appended to the same target subfile, forming a complete lock lifecycle record with the start information.

[0125] The system operation lag construction method provided in this application embodiment can clearly trace the execution subject of each lock-holding operation by storing the current thread ID in the log file, quickly locate the thread that may have problems, and then analyze its code logic and execution flow to find the root cause of the exception.

[0126] Figure 3 A flowchart illustrating a method for constructing a system operation lag mechanism according to another embodiment of this application is shown below. Figure 3 As shown, the system operation lag construction method provided in this embodiment includes the following steps:

[0127] S301. Obtain the current number of CPU threads and watchdog threshold of the system.

[0128] S302. Based on the number of CPU threads and the watchdog threshold, calculate the duration of the target thread's busy-wait operation using a preset formula.

[0129] S303. Initialize the kernel-mode spinlock and create a target thread with the same number of CPU threads.

[0130] S304. Get the remaining memory of the current system.

[0131] S305. Create at least one memory-consuming thread based on a memory block of a preset size and the remaining memory, so that the memory-consuming thread periodically sends memory request requests to the system and keeps occupying the memory until the system memory usage reaches a preset threshold to trigger a memory page replacement operation.

[0132] After the target thread is created, the target thread will execute steps 306-309:

[0133] S306, Periodically acquire spinlocks.

[0134] S307. In response to the failure to acquire the spinlock, continue to perform the spinlock acquisition operation.

[0135] S308. In response to acquiring the spinlock, perform a busy-wait operation and store the current thread ID, current time, and lock-holding start flag in the target subfile of the preset log folder.

[0136] S309. In response to the completion of the busy wait operation, release the spinlock and sleep for a preset time before continuing to execute the spinlock acquisition operation, and store the total lock holding time at the current time and the CPU usage during the lock holding period into the target sub-file.

[0137] S3010: Obtain the current system CPU utilization.

[0138] S311. Determine the busy wait time adjustment ratio based on CPU utilization and preset utilization threshold.

[0139] S312. Adjust the busy waiting operation duration according to the busy waiting operation duration adjustment ratio to obtain the target busy waiting operation duration, and execute the busy waiting operation according to the target busy waiting operation duration. It should be noted that the execution order of S307-S308 is not important.

[0140] In this embodiment, the implementation method and technical effect of S301-S312 are similar to those of the corresponding solutions in the above embodiments, and will not be repeated here.

[0141] Figure 4 A schematic diagram of the structure of the device for constructing a system to prevent lag provided in this application is shown below. Figure 4 As shown, the system operation lag construction device 40 provided in this embodiment includes: an acquisition module 41, a calculation module 42, an initialization module 43, and a creation module 44.

[0142] The system includes: an acquisition module 41 for acquiring the current number of CPU threads and the watchdog threshold; a calculation module 42 for calculating the duration of a target thread's busy-wait operation based on the number of CPU threads and the watchdog threshold using a preset formula; an initialization module 43 for initializing the kernel-mode spinlock; and a creation module 44 for creating target threads with the same number of CPU threads, so that each target thread executes preset processing logic to prevent system lag. The preset processing logic includes: periodically acquiring the spinlock; continuing to acquire the spinlock if it is not acquired; and performing a busy-wait operation if the spinlock is acquired.

[0143] The system operation lag-reducing device provided in this embodiment can execute... Figure 2 The implementation principles and technical effects of the methods shown are similar, and will not be repeated here.

[0144] Optionally, the system operation lag construction device provided in this embodiment also includes a release module.

[0145] Accordingly, the release module is used to release the spinlock and sleep for a preset time after the busy wait operation is completed before continuing to execute the spinlock acquisition operation.

[0146] Optionally, the acquisition module 41 is also used to acquire the remaining memory of the current system; the creation module 44 is also used to create at least one memory-consuming thread based on a memory block of a preset size and the remaining memory, so that the memory-consuming thread periodically sends memory request requests to the system and keeps occupying the memory until the system memory usage reaches a preset threshold to trigger a memory page replacement operation.

[0147] Optionally, the system operation lag construction device provided in this embodiment further includes a determination module and an adjustment module.

[0148] Accordingly, the acquisition module 41 is also used to acquire the CPU utilization of the current system; the determination module is used to determine the busy waiting operation duration adjustment ratio based on the CPU utilization and the preset utilization threshold; and the adjustment module is used to adjust the busy waiting operation duration according to the busy waiting operation duration adjustment ratio to obtain the target busy waiting operation duration, and to execute the busy waiting operation according to the target busy waiting duration.

[0149] Optionally, the system operation lag construction device provided in this embodiment further includes a receiving module and an execution module.

[0150] Accordingly, the receiving module is used to receive the target number of threads and the busy-wait operation duration input by the user; the creation module 44 is also used to create target threads based on the target number of threads input by the user; and the execution module is used to cyclically execute preset processing logic based on the busy-wait operation duration input by the user to construct a system operation lag phenomenon by competing for spin locks.

[0151] Optionally, the system operation lag construction device provided in this embodiment also includes a storage module.

[0152] Accordingly, the storage module is used to store the current thread ID, the current time, and the lock holding start identifier into a target subfile of a preset log folder; in response to releasing the spinlock, it stores the total lock holding time at the current time and the CPU utilization during the lock holding period into the target subfile.

[0153] Figure 5 A schematic diagram of the construction device for the system operation lag provided in this application. (See attached diagram.) Figure 5 As shown, the system operation lag mitigation device 50 provided in this embodiment includes a processor 51 and a memory 52. ​​The processor 51 and the memory 52 are connected via a bus and communicate with each other.

[0154] In the specific implementation process, the processor 51 executes the computer execution instructions stored in the memory 52, causing the processor 51 to perform the above-described method.

[0155] The specific implementation process of processor 51 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0156] In the above embodiments, it should be understood that the processor 51 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0157] The memory 52 may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0158] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0159] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0160] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0161] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0162] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0163] The division of units is merely a logical functional division; 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 indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0165] In addition, the functional units in the various embodiments of the present invention 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.

[0166] If a function 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. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0167] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0168] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for constructing a system operation lag prevention mechanism, characterized in that, The method includes: Get the current number of CPU threads and watchdog threshold of the system; Based on the number of CPU threads and the watchdog threshold, the duration of the target thread's busy-wait operation is calculated using a preset formula. Initialize the kernel-mode spinlock and create the same number of target threads as the CPU threads, so that each target thread executes preset processing logic to prevent system operation lag; The preset processing logic includes: periodically acquiring the spinlock; In response to the failure to acquire the spinlock, the spinlock acquisition operation continues; In response to acquiring the spinlock, a busy-wait operation is performed.

2. The method according to claim 1, characterized in that, Also includes: In response to the busy waiting operation being completed, the spinlock is released and the process pauses for a preset time before continuing to execute the spinlock acquisition operation.

3. The method according to claim 1, characterized in that, After creating the target thread with the same number of CPU threads, the method further includes: Get the current system's remaining memory; At least one memory-consuming thread is created based on a memory block of a preset size and the remaining memory, so that the memory-consuming thread periodically sends memory request requests to the system and keeps occupying the memory until the system memory usage reaches a preset threshold to trigger a memory page replacement operation.

4. The method according to claim 1, characterized in that, Also includes: Get the current CPU utilization of the system; The busy wait time adjustment ratio is determined based on the CPU utilization and the preset utilization threshold. The busy waiting operation duration is adjusted according to the busy waiting operation duration adjustment ratio to obtain the target busy waiting operation duration, and the busy waiting operation is executed according to the target busy waiting operation duration.

5. The method according to claim 1, characterized in that, Also includes: The target number of threads to receive user input and the busy wait time; The system creates a target thread based on the target number of threads input by the user, and executes preset processing logic cyclically based on the busy wait operation duration input by the user to compete for the spinlock to prevent system operation lag.

6. The method according to claim 1, characterized in that, The response after acquiring the spinlock also includes: Store the current thread ID, current time, and lock-holding start flag into a target subfile in the preset log folder; In response to the release of the spinlock, the total duration of lock holding at the current time and the CPU utilization during the lock holding period are stored in the target sub-file.

7. A construction device for system operation lag, characterized in that, include: The acquisition module is used to obtain the current system's CPU thread count and watchdog threshold. The calculation module is used to calculate the duration of the target thread's busy-wait operation based on the number of CPU threads and the watchdog threshold using a preset formula. The initialization module is used to initialize the spinlock in kernel mode; A creation module is used to create target threads with the same number of CPU threads, so that each target thread executes preset processing logic to prevent system operation from lagging. The preset processing logic includes: periodically acquiring the spinlock; In response to the failure to acquire the spinlock, the spinlock acquisition operation continues; In response to acquiring the spinlock, a busy-wait operation is performed.

8. A construction device with system operation lag, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images