Lag monitoring method, electronic equipment, storage medium and program product

Abstract

The invention provides a lagging monitoring method, electronic equipment, a storage medium and a program product, relates to the field of computers, and can solve the problem that it is difficult to accurately monitor equipment lagging in the prior art. The method comprises the following steps: acquiring kernel performance information of the electronic equipment; the kernel performance information comprises performance parameters of a data structure and / or performance parameters of a service routine; and monitoring the electronic equipment based on the kernel performance information, and determining a lag monitoring result. According to the invention, the accuracy of lagging monitoring can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of computers, and more particularly to a method for monitoring lag, electronic devices, storage media, and program products. Background Technology

[0002] Electronic devices, especially mobile devices, have become important platforms for users in work, entertainment, and learning. With the evolution of technology, the number and complexity of applications and device functions on electronic devices are growing exponentially, which places higher demands on the performance and stability of electronic devices.

[0003] System lag can significantly impact the user experience. Monitoring system lag can facilitate analysis of its causes, leading to targeted solutions. However, accurately monitoring system lag in electronic devices is currently challenging. Summary of the Invention

[0004] This disclosure provides a method, electronic device, storage medium, and program product for monitoring device lag, which can at least solve the problem that related technologies have difficulty in accurately monitoring device lag.

[0005] On the one hand, a method for monitoring lag is provided, including:

[0006] Obtain kernel performance information of the electronic device; the kernel performance information includes performance parameters of data structures and / or performance parameters of service routines;

[0007] The electronic device is monitored based on the kernel performance information to determine the lag monitoring results.

[0008] On the other hand, a lag monitoring device is provided, comprising: an acquisition unit and a processing unit;

[0009] The acquisition unit is used to acquire kernel performance information of the electronic device; the kernel performance information includes performance parameters of data structures and / or performance parameters of service routines;

[0010] The processing unit is used to monitor the electronic device based on the kernel performance information and determine the lag monitoring results.

[0011] In another aspect, an electronic device is provided, comprising: a memory and a processor; the memory and the processor are coupled; the memory is used to store a computer program; and the processor, when executing the computer program, implements the method described in any of the above embodiments.

[0012] In another aspect, a computer-readable storage medium is provided, on which computer program instructions are stored, which, when executed by a processor, implement the method described in any of the above embodiments.

[0013] In another aspect, a computer program product is provided, the computer program product including computer program instructions that, when executed by a processor, implement the method described in any of the above embodiments.

[0014] In the technical solution provided in this disclosure, the electronic device obtains its kernel performance information and monitors the device based on this information to determine the lag monitoring results. Compared to related technologies that monitor lag by collecting coarse-grained data related to applications, this disclosure can collect finer-grained kernel performance information related to data structures and / or service routines in the system kernel layer. This kernel performance information can characterize the actual execution status of the electronic device during runtime. Therefore, the method of monitoring the electronic device based on kernel performance information in this disclosure can accurately analyze the lag situation of the electronic device and improve the accuracy of lag monitoring. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in this disclosure, the accompanying drawings used in some embodiments of this disclosure will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings.

[0016] Figure 1 An architecture diagram of a stuttering monitoring system provided for some embodiments of this disclosure;

[0017] Figure 2 This is an architecture diagram of yet another stuttering monitoring system provided in some embodiments of this disclosure;

[0018] Figure 3 A flowchart illustrating a stuttering monitoring method provided in some embodiments of this disclosure;

[0019] Figure 4 A flowchart illustrating yet another method for detecting stuttering provided in some embodiments of this disclosure;

[0020] Figure 5 A flowchart illustrating yet another method for detecting stuttering provided in some embodiments of this disclosure;

[0021] Figure 6 A structural diagram of a stuttering monitoring device provided in some embodiments of this disclosure;

[0022] Figure 7 This is a structural diagram of an electronic device provided for some embodiments of this disclosure. Detailed Implementation

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

[0024] It should be noted that, in this disclosure, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this disclosure should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0025] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0026] In the description of this disclosure, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "more than one" means two or more.

[0027] Electronic devices, especially mobile devices, have become important platforms for users in work, entertainment, and learning. With the evolution of technology, the number and complexity of applications and device functions on electronic devices are growing exponentially, which places higher demands on the performance and stability of electronic devices.

[0028] System lag can significantly impact the user experience. Monitoring system lag makes it easier to analyze its causes and develop targeted solutions. However, current lag monitoring technologies have several limitations, making it difficult to accurately monitor system lag in electronic devices.

[0029] Taking the Android system as an example, related technologies typically collect information through methods such as log data collection, metric data collection, and trace data collection.

[0030] Log data records events that occur in system modules at different times, along with the corresponding event types and levels (e.g., warning events, error events). However, log data has a coarse granularity, making it difficult to effectively analyze system lag.

[0031] Metric data collection uses tools like `top`, `ps`, and `iostat` to record numerical changes on a specific dimension, such as process CPU usage, memory usage, and the amount of data read per second by a process. Trace data collection uses tools like `systrace` and `perfetto` to identify the time, name, duration, and relationships between events. Neither metric nor trace data collection is programmable, and the performance metrics and behaviors cannot be customized.

[0032] Current technologies for monitoring device lag primarily target a specific application running on the device; that is, they monitor whether a particular application experiences lag during use, such as games or video streaming applications. These technologies typically monitor lag in the following ways:

[0033] Method 1: Determine if there is lag by setting up tracking points in the application and observing the page rendering time.

[0034] The relevant technology embeds data points in preset locations within the terminal application (such as key locations of the application, locations that need to be monitored, and locations prone to lag). These data points trigger calls to the main thread to monitor whether the rendering time of each frame exceeds a preset time threshold. If the rendering time exceeds the preset time threshold, lag is determined to have occurred.

[0035] However, setting up tracking points in an application requires inserting extra logic and code into the application code, which increases the complexity and amount of code in the application, affects the application's running efficiency, and leads to more lag issues.

[0036] Method 2: Determine if there is lag by checking the general logs and diagnostic information of the running application.

[0037] Related technologies use monitoring tools (such as devtools) to monitor the layout and status of the application's user interface (UI) components, determine whether UI performance is too low based on the layout components and status, and view general logs and diagnostic information related to the running application.

[0038] However, this solution generates a large amount of complex and tedious monitoring information, and requires manual analysis to determine the cause of application lag, thus making lag monitoring inefficient.

[0039] In summary, the relevant technologies currently have the following shortcomings:

[0040] (1) Insufficient monitoring accuracy makes it difficult for related technologies to obtain detailed information when the system lags, and coarse-grained data collection cannot accurately analyze lag problems.

[0041] (2) Insufficient real-time performance: the relevant technologies are not timely enough in monitoring and responding to lag, making it difficult to take immediate measures when lag occurs, which affects the user experience.

[0042] (3) Insufficient customizability: The system data collected when lag occurs is the basis for troubleshooting and resolving lag issues. The relevant technologies are difficult to flexibly configure and optimize the required data collection based on actual needs.

[0043] (4) High performance overhead: The method of judging whether stuttering occurs by monitoring the rendering time of each page of the system screen, frame rate, and application layer data will generate a lot of additional performance overhead, which will further affect the stability of the system.

[0044] In view of this, this disclosure provides a method for monitoring lag, which acquires kernel performance information of an electronic device and monitors the electronic device based on this kernel performance information to determine the lag monitoring results. Compared with related technologies that monitor lag by collecting coarse-grained data related to applications, this disclosure can collect finer-grained kernel performance information related to data structures and / or service routines in the system kernel layer. This kernel performance information can characterize the actual execution of the electronic device during runtime. Therefore, the method of monitoring the electronic device based on kernel performance information disclosed in this disclosure can accurately analyze the lag situation of the electronic device and improve the accuracy of lag monitoring.

[0045] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0046] Figure 1 This is an architecture diagram of a lag monitoring system provided in an embodiment of this disclosure. Figure 1 As shown, the lag monitoring system includes: a kernel information acquisition module 101, a kernel information receiving module 102, a lag monitoring module 103, and a kernel information storage module 104.

[0047] The kernel information acquisition module 101 is connected to the kernel information receiving module 102, the kernel information receiving module 102 is connected to the lag monitoring module 103, and the lag monitoring module 103 is connected to the kernel information storage module 104. The kernel information acquisition module 101 is a kernel mode module, while the kernel information receiving module 102, the lag monitoring module 103, and the kernel information storage module 104 are user mode modules.

[0048] Kernel mode refers to the privilege level at which the operating system kernel runs, possessing full access to system resources. Code executing in kernel mode can execute privileged instructions and access the system's underlying hardware and resources. User mode refers to a privilege level at which applications run outside of the operating system kernel mode. Applications in user mode do not have direct access to system resources and must operate through interfaces provided by the operating system. The stuttering monitoring system in this disclosure can receive control commands through a remote command prompt-style interactive interface, and monitors the loading and unloading of software systems that monitor system stuttering based on eBPF technology. The functional modules provided in this disclosure can also be automatically loaded into the system upon system startup.

[0049] For example, the kernel information acquisition module 101, the kernel information receiving module 102, the stuttering monitoring module 103, and the kernel information storage module 104 can be functional modules based on the extended Berkeley packet filter (eBPF).

[0050] eBPF is a technology that allows sandboxed programs to run within a privileged context (such as the operating system kernel), extending kernel functionality without modifying kernel source code or loading kernel modules. The system kernel, possessing privileges to supervise and control the entire system, has high requirements for stability and security. eBPF enables the running of sandboxed programs within the kernel, adding extra functionality to the running operating system by running eBPF programs, and ensuring security and execution efficiency through a verification engine and just-in-time compiler. eBPF can provide low-overhead, secure extraction of fine-grained performance data in various application scenarios, including modern data centers, cloud-native environments, and system performance monitoring. This helps application developers track application runtime status, efficiently locate performance faults, and ensure the security of applications and containers during runtime.

[0051] In addition, eBPF technology can also track kernel data structures and kernel functions in the system.

[0052] Users can write event-based programs based on eBPF to filter, save, and retrieve required information. Collected kernel data can be directly filtered or statistically analyzed within the kernel, enabling kernel data aggregation and summarization, thus avoiding the additional system overhead caused by copying large amounts of kernel data to user space. eBPF utilizes just-in-time (JIT) compilation technology to compile and load kernel code in user space, improving execution speed and reducing kernel dependency, ensuring low-overhead execution efficiency. eBPF code can perform security verification and restrictions during execution to prevent malicious or improper access to kernel resources, thereby ensuring system stability and security. By dynamically modifying kernel behavior, eBPF can adjust monitoring strategies in real time as needed without recompiling or restarting the system, and flexibly capture and process relevant events.

[0053] The kernel information acquisition module 101 is used to acquire kernel performance information of electronic devices.

[0054] Kernel performance information includes performance parameters of data structures and / or service routines. For example, performance parameters include those related to CPU, memory, input / output (I / O), and network. A service routine refers to function instructions within the system kernel layer, while a data structure refers to the structured data required for these function instructions to run.

[0055] In some embodiments, such as Figure 2 As shown, the kernel information acquisition module 101 includes a system pressure acquisition program 1011 and a performance information acquisition program 1012.

[0056] The system stress acquisition program 1011 is used to collect the system load of the electronic device, and the performance information acquisition program 1012 is used to collect the kernel performance information of the electronic device. For example, the system stress acquisition program 1011 and the performance information acquisition program 1012 can be kernel-mode eBPF programs, based on the libbpf_bootstrap framework, and programmed using BTF (BPF typeformat) and CO-RE (compile once-run everywhere) technologies. The kernel-mode eBPF program defines kernel mount points through tracepoints, k-probes, etc., thereby collecting kernel information related to system lag, such as performance parameters in CPU, memory, I / O, and network dimensions. The kernel-mode eBPF program can be compiled into BPF bytecode. The electronic device loads the BPF bytecode into the kernel through BPF system calls and mounts the eBPF program to the kernel mount point.

[0057] In one possible implementation, the kernel information acquisition module 101 can collect the system load of the electronic device through the system pressure acquisition program 1011. When the system load is greater than a preset threshold, the performance information acquisition program 1012 is triggered to collect the kernel performance information of the electronic device.

[0058] System load is used to characterize the operating pressure of electronic equipment. For example, system load can be represented by pressure stall information (PSI).

[0059] The kernel information receiving module 102 is used to receive kernel performance information from the kernel information acquisition module 101.

[0060] For example, the kernel information receiving module 102 can be a user-mode program. The user-mode program is compiled into an executable program for execution. The performance information acquisition program 1012 can create a Map to store the acquired kernel performance information. Both kernel-mode and user-mode eBPF programs can access the data in the Map. The electronic device can transmit the acquired kernel performance information to the user-mode program via a ring buffer (ringbuf) and a CPU circular buffer (perfbuf), and the user-mode program can control the acquisition of kernel information. In this way, the kernel information acquisition module 101 can directly filter or statistically analyze the acquired memory performance information within the kernel, and transmit the data to user mode via the Map, thereby significantly reducing data transmission overhead and improving system operating efficiency.

[0061] For example, information about the created Map can be stored in the system's / sys / fs / bpf / map / directory.

[0062] The stuttering monitoring module 103 is used to monitor electronic devices based on kernel performance information and determine stuttering monitoring results.

[0063] Among them, the lag monitoring results are used to characterize whether electronic devices experience lag.

[0064] For example, the stuttering monitoring module 103 can be a user-space program, and the electronic device can monitor system stuttering through machine learning. For instance, the stuttering monitoring module 103 inputs kernel performance information into the stuttering monitoring model to obtain the stuttering monitoring results of the electronic device.

[0065] In some embodiments, the stuttering detection model can be trained in the following manner:

[0066] Generate a model training dataset, and use the model training dataset to train the initial model to obtain the stuttering monitoring model.

[0067] The model training dataset includes multiple kernel performance information and corresponding stuttering monitoring results for each kernel performance information.

[0068] For example, an electronic device can collect kernel performance information by running a performance information collection program 1012. Then, based on the timestamps of the system log data related to stuttering generated during the operation of the electronic device, the kernel performance information is marked as stuttering, generating a model training dataset. In this way, the electronic device can train the initial model using machine learning algorithms to obtain a trained stuttering monitoring model.

[0069] The kernel information storage module 104 is used to store kernel performance information and corresponding stuttering monitoring results. For example, the kernel information storage module 104 can be a user-mode program. When the stuttering monitoring module 103 determines that stuttering has occurred, the kernel information storage module 104 stores the kernel performance information and corresponding stuttering monitoring results.

[0070] For example, kernel information storage module 104 can store data in the system's / data directory.

[0071] The stuttering monitoring system provided in this disclosure serves as the execution entity for the stuttering monitoring method. It can be an electronic device, the central processing unit (CPU) of the electronic device, or a collection of relevant functional modules within the electronic device used to execute the stuttering monitoring method. This disclosure uses an electronic device executing the stuttering monitoring method as an example to illustrate the stuttering monitoring method provided in this disclosure.

[0072] It should be noted that the various embodiments of this disclosure can be referenced or learned from each other. For example, the same or similar steps, method embodiments, system embodiments and device embodiments can be referenced from each other without limitation.

[0073] Figure 3 A flowchart illustrating a lag monitoring method provided in this embodiment of the disclosure. Figure 3 As shown, the method includes the following steps:

[0074] Step 301: Obtain the kernel performance information of the electronic device.

[0075] The kernel performance information includes performance parameters of data structures and / or service routines. For example, performance parameters include those related to CPU, memory, I / O, and network. Service routines refer to function instructions within the system kernel layer, and data structures refer to the structured data required for these function instructions to run. In other words, the performance information obtained in this disclosure can be refined to the level of a single data structure or service routine within the kernel, providing a more comprehensive characterization of the system's operational status and supporting subsequent stuttering monitoring.

[0076] For example, a data structure refers to the organization and management of related structured data within the kernel. The kernel can efficiently perform various tasks using data structures, which include one or more of the following:

[0077] Process Control Block (PCB): The PCB is a kernel data structure used to represent each process, including information such as process state, priority, memory mapping, CPU register snapshots, and open file list. The PCB is a core element of the operating system for scheduling and managing processes.

[0078] File system inodes (inodes): File system inodes are used to store file metadata, including file size, permissions, creation time, modification time, and indexes pointing to the actual data. The kernel can efficiently manage files and directories through file system inodes.

[0079] Linked lists and queues: Linked lists and queues are used to organize kernel objects, such as wait queues, ready queues, and request queues for device drivers.

[0080] Hash tables (also known as hash tables): Hash tables are used for fast lookup and access to objects in the kernel, such as network connections, device drivers, kernel modules, etc.

[0081] Memory management data structures: Memory management data structures are used to manage physical and virtual memory and improve memory utilization efficiency. Examples of memory management data structures include page tables, segment tables, and buffer caches.

[0082] Semaphores, mutexes, and read-write locks are used to synchronize threads that concurrently access shared resources, preventing conflicts caused by concurrent operations.

[0083] A service routine is a function or subroutine in the kernel used to perform a specific task. For example, the kernel can achieve the following functionalities by calling a service routine:

[0084] System calls: When a user-space program requests a kernel service, such as opening a file, creating a process, or reading or writing to a disk, the corresponding service routine in the kernel is called to handle these requests.

[0085] Interrupt handlers: When an electronic device sends an interrupt signal, the kernel's service routines respond to the interrupt and handle the electronic device's input / output operations, such as data reading, writing, or error reporting.

[0086] Timer callback: When the timer expires, the kernel will call the relevant service routine to execute the planned task, such as scheduling processes, cleaning up resources, and updating system statistics.

[0087] Kernel initialization and configuration: When the system starts, the kernel executes a series of initialization service routines, such as setting hardware parameters, loading drivers, and establishing memory management structures.

[0088] Exception handling: When the kernel detects an abnormal condition, such as a page fault, out-of-bounds address, or division by zero, it will call the corresponding service routine to handle these exceptions and prevent system crashes.

[0089] Device driver routines: Service routines in a device driver are responsible for interacting with the hardware to control the device and transmit data.

[0090] In some embodiments, the electronic device may mount a performance information acquisition program on a target mount point, and trigger the performance information acquisition program through the target mount point to collect the kernel performance information of the electronic device.

[0091] The target mount point is located on a service routine of the electronic device, and the performance information collection program runs in kernel mode. In this way, when the electronic device executes the service routine located at the target mount point, the performance information collection program in kernel mode can be triggered to collect the performance parameters of that service routine. This service routine can be a service routine related to electronic device lag, such as a service routine called when the device malfunctions, or a service routine called during data read / write operations.

[0092] For example, a performance information acquisition program may include a performance parameter acquisition instruction, which is used to acquire performance parameters of a data structure. This data structure can be a data structure processed in the service routine where the target mount point resides, or a data structure that affects the performance of the electronic device during the invocation of the service routine where the target mount point resides.

[0093] In this way, electronic devices can collect the performance parameters of the required data structure through the performance information collection program. Compared with the related technologies that collect specified performance parameters according to pre-defined collection instructions, this disclosure can customize the monitoring data and collect the performance parameters of the corresponding data structure, thereby realizing flexible configuration of information collection.

[0094] For example, the performance information acquisition program can be a kernel-mode eBPF program, based on the libbpf_bootstrap framework, and programmed using BTF (BPF type format) and CO-RE (compile once-run everywhere) technologies. The kernel-mode eBPF program defines kernel mount points through tracepoints, k-probes, etc., to collect kernel information related to system performance issues, such as performance parameters related to CPU, memory, I / O, and network. The kernel-mode eBPF program can be compiled into BPF bytecode. The electronic device loads the BPF bytecode into the kernel via BPF system calls and mounts the eBPF program to the kernel mount point.

[0095] Step 302: Monitor electronic devices based on kernel performance information and determine the lag monitoring results.

[0096] Among them, the lag monitoring results are used to characterize whether electronic devices experience lag.

[0097] In some embodiments, when the electronic device experiences lag as indicated by lag monitoring results, it can store the acquired kernel performance information and lag monitoring results to facilitate subsequent analysis of the cause of lag based on the stored information and the generation of corresponding lag solutions.

[0098] It should be noted that kernel performance information can characterize performance parameters in different dimensions of the system kernel (such as CPU, memory, I / O, network, etc.). Therefore, electronic devices can be analyzed based on weighted factors across different dimensions to determine whether the electronic device is experiencing lag. The weight of each dimension can be adjusted according to the actual situation, and this disclosure does not impose any restrictions on it.

[0099] In the technical solution provided in this disclosure, the electronic device can acquire its kernel performance information and monitor the device based on this information to determine the lag monitoring results. Compared to related technologies that monitor lag by collecting coarse-grained data related to applications, this disclosure can collect finer-grained kernel performance information related to data structures and / or service routines in the system kernel layer. This kernel performance information can characterize the actual execution status of the electronic device during runtime. Therefore, the method of monitoring the electronic device based on kernel performance information in this disclosure can accurately analyze the lag situation of the electronic device and improve the accuracy of lag monitoring.

[0100] Furthermore, this disclosure can execute the above-mentioned lag monitoring method by triggering a threshold, thereby reducing the frequency of information collection and further reducing system performance overhead.

[0101] As one possible embodiment of this disclosure, combined with Figure 3 The illustrated embodiments, such as Figure 4 As shown, step 301 above can also be achieved through the following steps 401-402.

[0102] Step 401: Obtain the system load of the electronic device.

[0103] System load is used to characterize the operating pressure of electronic equipment. For example, system load can be represented by pressure stall information (PSI).

[0104] In some embodiments, the electronic device may acquire the system load of the electronic device through a system stress acquisition program.

[0105] The system stress acquisition program runs in kernel mode. For example, the system stress acquisition program can be a kernel-mode eBPF program.

[0106] Step 402: When the system load exceeds a preset threshold, obtain the kernel performance information of the electronic device.

[0107] The preset threshold can be determined according to the actual situation, and this disclosure does not limit it.

[0108] For example, an electronic device can load a system stress acquisition program and a performance information acquisition program, and run the system stress acquisition program in kernel mode, the kernel information receiving program in user mode, and the stuttering monitoring program. The loaded program information can be stored in the ` / sys / fs / bpf / program / ` directory. Then, the electronic device determines its system load based on the kernel information about system resource pressure collected by the system stress acquisition program. If the system load exceeds a preset threshold, the performance information acquisition program is run to collect information, thereby obtaining kernel performance information when the system is under heavy load.

[0109] Based on the above technical solution, the electronic device in this disclosure can obtain the system load of the electronic device. When the system load exceeds a preset threshold, the kernel performance information of the electronic device can be obtained through threshold triggering. In this way, this disclosure can reduce the frequency of kernel performance information collection without affecting the lag monitoring, thereby reducing system performance overhead and avoiding affecting the normal operation of the electronic device.

[0110] Furthermore, this disclosure can also use machine learning to detect lag, thereby improving the efficiency of lag detection.

[0111] As one possible embodiment of this disclosure, combined with Figure 3 The illustrated embodiments, such as Figure 5As shown, step 302 above can also be achieved through the following step 501.

[0112] Step 501: Input the kernel performance information into the stuttering monitoring model to obtain the stuttering monitoring results of the electronic device.

[0113] In some embodiments, the stuttering detection model is trained in the following manner:

[0114] Generate a model training dataset, and use the model training dataset to train the initial model to obtain the stuttering monitoring model.

[0115] The model training dataset includes multiple kernel performance information and corresponding stuttering monitoring results for each kernel performance information.

[0116] For example, an electronic device can collect kernel performance information by running a performance information collection program. Then, based on the timestamps of the system log data related to stuttering generated during the operation of the electronic device, the kernel performance information is marked as stuttering, generating a model training dataset. In this way, the electronic device can train the initial model using machine learning algorithms to obtain a trained stuttering monitoring model.

[0117] Taking Gradient Boosting Decision Tree (GBDT) as an example, the generated model training dataset can be divided into a training set and a test set according to a preset ratio (e.g., 7:3) using the hold-out method. The initial model is trained using the training set, and the trained stuttering detection model is tested using the test set. Afterwards, the trained stuttering detection model can be exported as program code using the m2cgen tool, thus deploying the stuttering detection model in the stuttering detection module.

[0118] Based on the above technical solution, this disclosure can monitor device lag using a lag monitoring model, thereby achieving real-time monitoring of system lag. Compared with lag monitoring methods in related technologies, this disclosure can accurately determine whether the system is laging in real time.

[0119] It is understood that, in order to achieve the above-mentioned functions, electronic devices include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the algorithmic steps of the examples described in conjunction with the embodiments of this disclosure, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0120] This disclosure embodiment can divide an electronic device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one functional module. The integrated module can be implemented in hardware or software. It should be noted that the module division in this disclosure embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. The following description uses the example of dividing each functional module according to each function.

[0121] For example, taking the lag monitoring device as an electronic device in the above method embodiment as an example, Figure 6 This is a structural diagram of a stuttering monitoring device 60 provided in an embodiment of this disclosure. The stuttering monitoring device 60 can execute the stuttering monitoring method provided in the above-described method embodiment. Figure 6 As shown, the stuttering monitoring device 60 includes an acquisition unit 601 and a processing unit 602.

[0122] The acquisition unit 601 is used to acquire kernel performance information of the electronic device. Kernel performance information includes performance parameters of data structures and / or performance parameters of service routines.

[0123] The processing unit 602 is used to monitor electronic devices based on kernel performance information and determine the lag monitoring results.

[0124] In some embodiments, the acquisition unit 601 is used to acquire the system load of the electronic device; and when the system load is greater than a preset threshold, to acquire the kernel performance information of the electronic device.

[0125] In some embodiments, the acquisition unit 601 is used to acquire the system load of the electronic device through a system stress acquisition program; the system stress acquisition program runs in kernel mode.

[0126] In some embodiments, the processing unit 602 is used to mount a performance information acquisition program on a target mount point, and trigger the performance information acquisition program to collect kernel performance information of the electronic device through the target mount point; the target mount point is located on the service routine of the electronic device; the performance information acquisition program runs in kernel mode.

[0127] In some embodiments, the performance information acquisition program includes a performance parameter acquisition instruction; the performance parameter acquisition instruction is used to acquire the performance parameters of the data structure.

[0128] In some embodiments, the processing unit 602 is used to input kernel performance information into the stuttering monitoring model to obtain stuttering monitoring results of the electronic device.

[0129] In some embodiments, the stuttering monitoring model is trained by: generating a model training dataset; the model training dataset includes multiple kernel performance information and stuttering monitoring results corresponding to the multiple kernel performance information; and training the initial model using the model training dataset to obtain the stuttering monitoring model.

[0130] In implementing the functionality of the integrated modules described above using hardware, this disclosure provides another possible structure for the electronic device described in the above embodiments. For example... Figure 7 As shown, the electronic device 70 includes a processor 702 and a bus 704. Optionally, the electronic device 70 may also include a memory 701; alternatively, the electronic device 70 may also include a communication interface 703.

[0131] Processor 702 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 702 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 702 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0132] The communication interface 703 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0133] The memory 701 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0134] As one possible implementation, the memory 701 can exist independently of the processor 702. The memory 701 can be connected to the processor 702 via a bus 704 and is used to store instructions or program code. When the processor 702 calls and executes the instructions or program code stored in the memory 701, it can implement the method described in any embodiment of this disclosure.

[0135] In another possible implementation, the memory 701 can also be integrated with the processor 702.

[0136] The 704 bus can be an extended industry standard architecture (EISA) bus, etc. The 704 bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0137] Some embodiments of this disclosure provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing computer program instructions that, when executed on a computer, cause the computer to perform the methods described in any of the above embodiments.

[0138] For example, the computer-readable storage media described above may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical disks (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). The various computer-readable storage media described in this disclosure may represent one or more devices for storing information and / or other machine-readable storage media. The term "machine-readable storage media" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0139] This disclosure provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described in any of the above embodiments.

[0140] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions within the technical scope disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for detecting stuttering, characterized in that, include: Obtain kernel performance information of electronic devices; The kernel performance information includes performance parameters of data structures and / or performance parameters of service routines; The electronic device is monitored based on the kernel performance information to determine the lag monitoring results.

2. The method according to claim 1, characterized in that, The acquisition of kernel performance information of the electronic device includes: Obtain the system load of the electronic device; When the system load exceeds a preset threshold, the kernel performance information of the electronic device is obtained.

3. The method according to claim 2, characterized in that, The process of obtaining the system load of the electronic device includes: The system load of the electronic device is collected through a system load acquisition program; the system load acquisition program runs in kernel mode.

4. The method according to claim 1, characterized in that, The acquisition of kernel performance information of the electronic device includes: A performance information collection program is mounted on a target mount point, and the performance information collection program is triggered through the target mount point to collect the kernel performance information of the electronic device; the target mount point is located on the service routine of the electronic device; the performance information collection program runs in kernel mode.

5. The method according to claim 4, characterized in that, The performance information acquisition program includes performance parameter acquisition instructions; the performance parameter acquisition instructions are used to acquire the performance parameters of the data structure.

6. The method according to claim 1, characterized in that, The monitoring of the electronic device based on the kernel performance information to determine the lag monitoring results includes: The kernel performance information is input into the stuttering monitoring model to obtain the stuttering monitoring results of the electronic device.

7. The method according to claim 6, characterized in that, The stuttering detection model was trained in the following way: Generate a model training dataset; the model training dataset includes multiple kernel performance information and stuttering monitoring results corresponding to each of the multiple kernel performance information. The initial model is trained using the model training dataset to obtain the stuttering monitoring model.

8. An electronic device, characterized in that, include: Memory and processor; Memory and processor are coupled; The memory is used to store instructions that can be executed by the processor; When the processor executes the instructions, it performs the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7.

Images