Memory jitter observation method and device, equipment, storage medium and program product

Abstract

The invention provides a memory jitter observation method and device, equipment, a storage medium and a program product, kernel events called by a memory application are obtained based on preset hook points, the hook points are trigger points corresponding to the kernel events, and memory information collection strategies corresponding to the kernel events are mounted on the hook points; performing memory information collection on the kernel event based on the memory information collection strategy, and performing mapping storage on the collected memory information to obtain a memory information file and a file descriptor which have a corresponding relationship; according to a preset jitter identification rule, whether memory jitter happens to the kernel event or not is judged, memory jitter marking is conducted on the kernel event where memory jitter happens, and the memory jitter mark is used for representing that memory information file data corresponding to the file descriptor is abnormal in the file descriptor; according to the method, real-time observability of memory jitter can be achieved by collecting kernel events under various triggering conditions.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a memory jitter observation method, apparatus, device, storage medium, and program product. Background Art

[0002] Memory jitter refers to the random fluctuations in memory access latency within a computer system. This fluctuation can be caused by a variety of factors, including hardware characteristics, system load, and memory management policies. Memory jitter can impact system performance, especially in real-time systems or high-performance computing environments. Understanding and monitoring memory jitter is crucial for optimizing system performance. The primary goal of memory jitter monitoring is to measure and analyze fluctuations in memory access latency to identify potential performance bottlenecks and optimization opportunities.

[0003] Existing technologies for observing memory jitter primarily rely on adding logging code to applications to record the time and amount of memory allocation and release, and then analyzing the log data offline. This approach can record specific memory operations as needed. However, this approach requires modifying application code, increasing the complexity of application development and maintenance. Because log records need to be exported and analyzed, it cannot provide real-time memory jitter information, potentially delaying problem discovery and resolution. Summary of the Invention

[0004] The present application provides a memory jitter observation method, apparatus, device, storage medium and program product to solve the problem that existing memory jitter observation technology requires modification of application code, memory recording and analysis are separated, and real-time observation of memory jitter cannot be performed.

[0005] In a first aspect, the present application provides a memory jitter observation method, comprising:

[0006] Obtaining kernel events invoked by memory requests based on preset hook points, wherein the hook points are trigger points corresponding to each kernel event, and the hook points are all mounted with memory information collection strategies corresponding to each kernel event;

[0007] Performing memory information collection on the kernel event based on the memory information collection strategy, mapping and storing the collected memory information, obtaining a memory information file and a file descriptor having a corresponding relationship, wherein the file descriptor is used by a user end to obtain the memory information file;

[0008] According to the preset jitter identification rules, it is determined whether the kernel event has memory jitter, and a memory jitter mark is performed on the kernel event that has memory jitter. The memory jitter mark is used to indicate in the file descriptor that the memory information file data corresponding to the file descriptor is abnormal.

[0009] Optionally, in the above method, collecting memory information for the kernel event based on the memory information collection policy includes:

[0010] The task identification number ID, memory water level status and memory capacity of the kernel event are collected.

[0011] Optionally, in the above method, the kernel event includes processing a page fault event and a global entry memory allocation event, and the collecting memory information for the kernel event based on the memory information collection strategy further includes:

[0012] The processing duration of the kernel event is collected.

[0013] Optionally, in the above method, the determining whether memory jitter occurs in the kernel event according to a preset jitter identification rule includes:

[0014] Determine whether the memory water level state threshold corresponding to the kernel event exceeds a preset first threshold;

[0015] If so, confirm that memory thrashing has occurred in this kernel event;

[0016] If not, confirm that no memory thrashing occurs in this kernel event.

[0017] Optionally, the method described above, before acquiring the kernel event of the memory request call based on the preset hook point, includes:

[0018] According to the kernel event corresponding to the hook point, at least one target memory information collection strategy that matches the kernel event is obtained from the memory information collection strategy library, and the target memory information collection strategy is mounted to the hook point. The memory information collection strategy library stores the correspondence between each memory information collection strategy and each target memory information collection strategy and the kernel event.

[0019] Optionally, the method described above, after marking the kernel event in which memory jitter occurs as memory jitter, further includes:

[0020] The memory information file containing the memory jitter mark is analyzed to generate a memory jitter result, and the memory jitter result is pushed to the user end.

[0021] Optionally, in the above method, analyzing the memory information file to generate the memory jitter result includes:

[0022] Summarize kernel events within a preset time period, and take kernel events containing the memory jitter mark as abnormal kernel events;

[0023] The task IDs of the abnormal kernel events are counted, and a memory jitter result is generated according to the task IDs obtained by the statistics and the abnormal kernel events corresponding to the task IDs.

[0024] In a second aspect, the present application provides a memory jitter observation device, comprising:

[0025] An event acquisition module, configured to acquire kernel events invoked by memory requests based on preset hook points, wherein the hook points are trigger points corresponding to each kernel event, and each hook point is equipped with a memory information collection strategy corresponding to each kernel event;

[0026] A collection module, configured to collect memory information of the kernel event based on the memory information collection strategy, map and store the collected memory information, obtain a memory information file and a file descriptor having a corresponding relationship, and use the file descriptor for the user end to obtain the memory jitter file;

[0027] The jitter marking module is used to determine whether the kernel event has memory jitter according to the preset jitter identification rules, and to mark the kernel event that has memory jitter as memory jitter. The memory jitter mark is used to indicate in the file descriptor that the memory information file data corresponding to the file descriptor is abnormal.

[0028] In a third aspect, the present application provides an electronic device comprising a memory, a processor, and computer-executable instructions stored in the memory and executable on the processor, wherein when the processor executes the computer-executable instructions, the memory jitter observation method described in any one of the first aspects above is implemented.

[0029] In a fourth aspect, the present application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the memory jitter observation method described in any one of the first aspects above.

[0030] In a fifth aspect, the present application provides a computer program product. When the computer program product is run on a terminal device, the terminal device executes the memory jitter observation method described in any one of the first aspects above.

[0031] The memory jitter observation method, apparatus, equipment, storage medium and program product provided in the present application obtain kernel events called by memory requests based on preset hook points, where the hook points are trigger points corresponding to each kernel event, and the hook points are all mounted with memory information collection strategies corresponding to each kernel event; memory information is collected for the kernel events based on the memory information collection strategies, and the collected memory information is mapped and stored to obtain memory information files and file descriptors with corresponding relationships, and the file descriptors are used by the user end to obtain the memory information files; whether memory jitter occurs in the kernel event is determined according to preset jitter identification rules, and a memory jitter mark is performed on the kernel event that has memory jitter, and the memory jitter mark is used to indicate in the file descriptor that the memory information file data corresponding to the file descriptor is abnormal, which can realize the collection of kernel events for various trigger conditions, thereby realizing real-time observability of memory jitter. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0033] Figure 1 A schematic diagram of an application scenario of the memory jitter observation method provided in an embodiment of the present application;

[0034] Figure 2 A flowchart of a memory jitter observation method provided in an embodiment of the present application;

[0035] Figure 3 A schematic diagram of a memory jitter observation device provided in an embodiment of the present application;

[0036] Figure 4 A schematic diagram of the structure of an electronic device suitable for a memory jitter observation method provided in an embodiment of the present application.

[0037] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0038] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0039] First, let’s explain the terms involved in this application:

[0040] Extended Berkeley Packet Filter (eBPF): is a lightweight kernel-based virtual machine that allows users to run custom programs in the kernel to achieve real-time monitoring and analysis of system events.

[0041] In related technologies, memory monitoring primarily focuses on memory leaks, while real-time observation of memory jitter is rarely possible. Currently, memory jitter monitoring is primarily accomplished by adding logging code to applications to record the time and amount of memory allocation and release, followed by offline analysis of the log data. However, this approach requires modifying application code and exporting and analyzing log records, failing to provide real-time memory jitter information, potentially delaying problem discovery and resolution.

[0042] In response to the above technical problems, the embodiments of the present application aim to propose a memory jitter observation method, device, equipment, storage medium and program product. The core concept of this method is: mounting the memory jitter path through a pre-set hook point, analyzing and processing the memory jitter information, and realizing the observability of memory jitter.

[0043] In order to better understand the solution of the embodiment of the present application, an application scenario involved in the embodiment of the present application is first introduced below.

[0044] See also Figure 1 , Figure 1 A schematic diagram of an application scenario of the memory jitter observation method provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the system includes a user terminal 100, a server 200, and a display terminal 300. A user can write an eBPF program on the user terminal 100 and send relevant instructions to the server 200. The server 200 can then load the written eBPF program into the kernel and attach it to a designated hook point. When a memory request occurs, the eBPF program in the hook point is automatically executed, and relevant memory information is collected and stored. This memory information can then be transmitted to the display terminal 300 via methods such as perf events (a tool for transmitting memory information, helping to transfer kernel data to user space). It should be noted that the display terminal 300 is primarily used to receive memory information collected by the server 200, and can also receive analysis results (such as whether there is memory jitter) processed and analyzed by the server 200. The display terminal 300 can be the same device as the user terminal 100.

[0045] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0046] Figure 2 This is a flow chart of the memory jitter observation method provided in the embodiment of the present application. Figure 2 As shown, the method of this embodiment includes:

[0047] S201: Obtain kernel events called by memory application based on preset hook points, wherein the hook points are trigger points corresponding to each kernel event, and the hook points are all mounted with memory information collection strategies corresponding to each kernel event.

[0048] The execution subject of the embodiment of the present application may be a server, or a memory jitter observation system in the server, wherein the memory jitter observation system may be implemented through software.

[0049] It's understood that kernel events refer to specific events that occur within the operating system kernel, such as memory allocation and deallocation. Hook points (also known as hook points) are specific locations within the kernel that are triggered when kernel events (such as memory allocation and deallocation) occur. Memory information collection policies are predefined policies that determine what memory information should be collected when kernel events occur, such as the allocated memory size, allocation time, and call stack. Memory information collection policies can be implemented using eBPF programs.

[0050] For example, when a hook point is set on the memory allocation function "kmalloc" in the system, when the system calls "kmalloc" for memory allocation, this hook point will be triggered, thereby executing the attached eBPF program to record the allocated memory size, timestamp, call stack information, etc. according to the collection strategy.

[0051] S202: Memory information is collected for the kernel event based on the memory information collection strategy, the collected memory information is mapped and stored, and a memory information file and a file descriptor having a corresponding relationship are obtained, and the file descriptor is used by the user end to obtain the memory information file.

[0052] It is understood that a file descriptor is an identifier assigned by the operating system to each open file for subsequent access to the file. Memory information is mapped and stored in the file system and managed through file descriptors, making it convenient for users to access this information. For example, the collected memory allocation information can be stored in the file " / var / log / memory_info_001", to which the system assigns the file descriptor "fd_001". Users can access this file through "fd_001" to read detailed information about memory allocations.

[0053] S203: Determine whether memory jitter occurs in the kernel event according to a preset jitter identification rule, and perform a memory jitter mark on the kernel event that memory jitter occurs. The memory jitter mark is used to indicate in the file descriptor that the memory information file data corresponding to the file descriptor is abnormal.

[0054] Memory jitter identification is used to discover and diagnose system performance issues. Memory jitter may cause system performance degradation and requires timely identification and processing. You can set preset jitter identification rules to determine whether there are abnormal fluctuations in memory operations, such as frequent allocation and release.

[0055] In this step, kernel events that indicate memory jitter are marked to facilitate subsequent analysis and processing. Marking memory jitter events can help system administrators or developers quickly locate and resolve memory jitter issues, improving system stability and performance. For example, if the system detects jitter in a memory allocation operation, it will be marked according to the jitter identification rules and a marker will be added to the file descriptor "fd_001", indicating that the memory information contained in the file is abnormal.

[0056] The memory jitter observation method provided in this embodiment obtains kernel events called by memory requests based on preset hook points, where the hook points are trigger points corresponding to each kernel event, and the hook points are all mounted with memory information collection strategies corresponding to each kernel event; memory information is collected for the kernel events based on the memory information collection strategies, and the collected memory information is mapped and stored to obtain memory information files and file descriptors with corresponding relationships, and the file descriptors are used by the user end to obtain the memory information files; according to preset jitter identification rules, it is determined whether memory jitter occurs in the kernel event, and a memory jitter mark is performed on the kernel event that has memory jitter, and the memory jitter mark is used to indicate in the file descriptor that the memory information file data corresponding to the file descriptor is abnormal, which can realize the collection of kernel events for various trigger conditions, thereby realizing real-time observability of memory jitter.

[0057] The following is a detailed introduction to the technical solution of the above-mentioned memory jitter observation method.

[0058] In a possible implementation, in the memory jitter observation method provided in this embodiment, memory information is collected for the kernel event based on the memory information collection strategy, including: collecting the task identification number ID, memory water level status and memory capacity of the kernel event.

[0059] It is understandable that the task identification number ID is a unique identifier assigned by the operating system to each process or thread to distinguish different tasks. Collecting the task identification number ID can help identify which process or thread triggered the kernel event, such as memory allocation or release. Furthermore, in a multi-tasking operating system, multiple processes or threads may perform memory operations at the same time. Collecting the task identification number ID can help track and analyze the memory usage of a specific task, making it easier to locate problems and optimize performance. For example, suppose there are two processes A and B in the system, each performing memory allocation operations. By collecting the task identification number ID, it is possible to distinguish whether these memory operations are triggered by process A or process B, thereby more accurately analyzing memory usage.

[0060] The memory water level status refers to the system's current memory usage, including the total amount of memory, used amount, and remaining amount. Collecting the memory water level status provides a global view of the system's current memory usage, helping to understand memory usage trends and pressure. Furthermore, by monitoring the memory water level status, problems such as insufficient memory or memory leaks can be promptly detected, preventing system performance degradation or crashes. For example, at a certain moment, the system has a total memory of 16GB, 12GB is used, and 4GB remains. By collecting this information, it is possible to determine whether the system is experiencing memory pressure and whether memory optimization or expansion is necessary.

[0061] Memory capacity refers to the amount of memory involved in a specific kernel event, such as memory allocation or release. Collecting memory capacity records the specific size of each memory operation, helping to analyze detailed memory usage. Understanding the specific size of each memory operation helps identify memory usage patterns, revealing unusually large memory allocations or frequent small memory allocations, which may be signs of memory jitter or memory leaks. For example, a process calls "memory allocate" to allocate 256KB of memory, and then calls "memory release" to release 128KB of memory. By collecting the specific sizes of these memory operations, you can analyze the process's memory usage pattern and determine whether any anomalies exist.

[0062] The kernel events include processing page fault events and overall entry memory allocation events. The memory information collection for the kernel events based on the memory information collection strategy further includes: collecting the processing duration of the kernel events.

[0063] In this embodiment, kernel events are pre-confirmed based on various memory jitter conditions. Therefore, kernel events may include memory page fault processing (do_swap_page), overall entry memory allocation (alloc_page), memory slow application (alloc_pages_slowpath), memory water level change (water_mark), memory synchronous reclaim (alloc_pates_direct_reclaim), memory synchronous compaction (alloc_pages_direct_compact), and memory synchronous reclaim triggering oom (alloc_pages_may_oom). Kernel events can also be added or deleted by the user end according to actual needs, and the corresponding hook points and eBPF programs can also be adjusted accordingly.

[0064] It is understandable that monitoring and processing page fault events and overall entry memory allocation events can provide a comprehensive understanding of the key operations of system memory management. Page fault events may lead to performance degradation, while memory allocation events directly affect the efficiency and stability of memory usage. Among them, processing page fault events refers to page fault interrupt events triggered when the memory page accessed by the process is not in the physical memory. The system needs to load the required memory pages from the disk into the physical memory; the overall entry memory allocation event refers to the entry event of the system performing memory allocation operations. For processing page fault events and overall entry memory allocation events, it is necessary to collect the processing time to understand the processing efficiency of this page fault event or overall entry memory allocation event, and to determine whether there is a performance bottleneck. The processing time refers to the time taken from the triggering of the kernel event to the completion of the processing.

[0065] For example, a process accesses a page that is not loaded into physical memory, triggering a page fault interrupt. The system starts loading the page from disk, collects information such as the task identification number ID, memory water level status, memory capacity, and records the processing time. By analyzing the frequency and duration of processing page fault events, it can be determined whether the system has insufficient memory or a disk I / O bottleneck.

[0066] Furthermore, determining whether memory jitter occurs in the kernel event according to a preset jitter identification rule includes: determining whether a memory water level status threshold corresponding to the kernel event exceeds a preset first threshold; if so, confirming that memory jitter occurs in the kernel event; if not, confirming that memory jitter does not occur in the kernel event.

[0067] It is understandable that the memory water level status threshold refers to a quantitative indicator of the system's current memory usage, such as memory usage rate, remaining memory amount, etc.; the preset first threshold is a critical value pre-set by the system, which is used to determine whether the memory usage is within the normal range. By comparing the memory water level status threshold and the preset first threshold, it can be determined whether the current memory usage is abnormal. For example, assuming that the first threshold set by the system is 80%, that is, when the memory usage rate exceeds 80%, the memory usage is considered abnormal. For example, the current memory usage rate is 85%, which exceeds the preset first threshold, so the memory usage is judged to be abnormal. Memory jitter may cause the system response time to become longer, or even cause the system to crash. Timely confirmation and processing of memory jitter can improve the stability and performance of the system. When memory usage is normal, confirming that memory jitter has not occurred can avoid unnecessary intervention and optimization, saving system resources and management costs.

[0068] In one possible implementation, the memory jitter observation method provided in this embodiment includes, before obtaining the kernel event of the memory application call based on the preset hook point, obtaining at least one target memory information collection strategy that matches the kernel event from the memory information collection strategy library according to the kernel event corresponding to the hook point, and mounting the target memory information collection strategy to the hook point. The memory information collection strategy library stores each memory information collection strategy and the correspondence between each target memory information collection strategy and the kernel event.

[0069] In this embodiment, the memory information collection policy library is a database that stores various memory information collection policies. Each policy defines the memory information that needs to be collected when a specific kernel event occurs. According to the kernel event corresponding to the hook point, a matching collection policy is obtained from the policy library to ensure that the required memory information can be collected when the kernel event occurs. Different kernel events may require different memory information collection policies. By obtaining matching policies from the policy library, various kernel events can be flexibly responded to to ensure that the collected information is targeted and effective. It is understandable that the policy library stores a variety of memory information collection policies, including policies for events such as memory allocation, memory release, and page fault interrupts. The system obtains the collection policy that matches the memory allocation event from the policy library. In addition, by storing the collection policies and their corresponding relationships, the flexibility and scalability of the system can be improved. When adding or modifying a collection policy, it is only necessary to update the policy library without changing the core code of the system.

[0070] It can be understood that mounting the collection strategy to the hook point can ensure that when a kernel event occurs, the corresponding collection strategy can be automatically executed to collect the required memory information.

[0071] In a possible implementation, the memory jitter observation method provided in this embodiment further includes, after the memory jitter marking is performed on the kernel event where the memory jitter occurs, analyzing the memory information file containing the memory jitter mark, generating a memory jitter result, and pushing the memory jitter result to the user end.

[0072] It is understandable that the memory information file is used to store the collected memory information, including detailed data such as memory usage, task identification number ID, memory water level status, memory capacity, etc. By analyzing the memory information file, the root cause of memory jitter can be identified, targeted optimization measures can be formulated, and system performance and stability can be improved. The memory jitter result is a summary and conclusion of the memory jitter analysis, including information such as the cause of memory jitter, scope of impact, and frequency. By generating memory jitter results, a clear memory jitter diagnostic report can be provided to system administrators or developers to help them quickly locate and solve problems. The memory jitter results are pushed in a timely manner, and users can view detailed jitter analysis reports through the interface, including jitter causes, scope of impact, and optimization suggestions. This can improve problem response speed, reduce the impact of memory jitter on system performance, and ensure stable system operation.

[0073] Furthermore, the memory information file is analyzed to generate a memory jitter result, which may specifically include: summarizing kernel events within a preset time period, and treating kernel events containing the memory jitter mark as abnormal kernel events; counting the task IDs of the abnormal kernel events, and generating a memory jitter result based on the statistically obtained task IDs and the abnormal kernel events corresponding to the task IDs.

[0074] It can be understood that by aggregating kernel events within a preset timeframe, we can focus on analyzing memory usage within a specific timeframe and identify the frequency and distribution of memory jitter. This provides a more comprehensive understanding of memory jitter occurrences and identifies time periods and events where memory jitter frequently occurs, facilitating subsequent analysis and optimization. Furthermore, by counting the task IDs of abnormal kernel events, we can identify which tasks are the primary sources of memory jitter. Identifying tasks with frequent memory jitter can help system administrators or developers locate issues, optimize memory usage for specific tasks, and reduce the occurrence of memory jitter. For example, the system can generate a memory jitter report based on the collected task IDs and corresponding abnormal kernel events. The report indicates that a certain task ID (e.g., process A) frequently experienced memory jitter within a specific timeframe and provides a detailed description of these abnormal kernel events. Using this report, system administrators can focus on optimizing process A's memory usage.

[0075] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all optional embodiments, and the actions and modules involved are not necessarily required by this application.

[0076] It should be further noted that, although the various steps in the flowchart are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps may be performed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but may be performed at different times. The execution order of these sub-steps or stages is not necessarily to be performed in sequence, but may be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0077] Figure 3 This is a schematic diagram of a memory jitter observation device provided in an embodiment of the present application. Figure 3 As shown, the memory jitter observation device includes:

[0078] An event acquisition module 31 is configured to acquire kernel events invoked by memory requests based on preset hook points, wherein the hook points are trigger points corresponding to respective kernel events, and the hook points are each equipped with a memory information collection policy corresponding to the respective kernel events;

[0079] A collection module 32 is configured to collect memory information of the kernel event based on the memory information collection strategy, map and store the collected memory information, and obtain a corresponding memory information file and a file descriptor, wherein the file descriptor is used by the user end to obtain the memory jitter file;

[0080] The jitter marking module 33 is used to determine whether the kernel event has memory jitter according to the preset jitter identification rules, and to mark the kernel event that has memory jitter as memory jitter. The memory jitter mark is used to indicate in the file descriptor that the memory information file data corresponding to the file descriptor is abnormal.

[0081] In one possible design, the acquisition module 32 is specifically configured to:

[0082] The task identification number ID, memory water level status and memory capacity of the kernel event are collected.

[0083] In one possible design, the kernel events include processing page fault events and overall entry memory allocation events, and the acquisition module 32 is specifically configured to:

[0084] The processing duration of the kernel event is collected.

[0085] In one possible design, the jitter marking module 33 is specifically configured to:

[0086] Determine whether the memory water level state threshold corresponding to the kernel event exceeds a preset first threshold;

[0087] If so, confirm that memory thrashing has occurred in this kernel event;

[0088] If not, confirm that no memory thrashing occurs in this kernel event.

[0089] In a possible design, the event acquisition module 31 is further specifically configured to:

[0090] According to the kernel event corresponding to the hook point, at least one target memory information collection strategy that matches the kernel event is obtained from the memory information collection strategy library, and the target memory information collection strategy is mounted to the hook point. The memory information collection strategy library stores the correspondence between each memory information collection strategy and each target memory information collection strategy and the kernel event.

[0091] In one possible design, the jitter marking module 33 is further specifically configured to:

[0092] The memory information file containing the memory jitter mark is analyzed to generate a memory jitter result, and the memory jitter result is pushed to the user end.

[0093] In one possible design, the jitter marking module 33 is further specifically configured to:

[0094] Summarize kernel events within a preset time period, and take kernel events containing the memory jitter mark as abnormal kernel events;

[0095] The task IDs of the abnormal kernel events are counted, and a memory jitter result is generated according to the task IDs obtained by the statistics and the abnormal kernel events corresponding to the task IDs.

[0096] It should be understood that the above-described device embodiments are merely illustrative, and the device of the present application may also be implemented in other ways. For example, the division of units / modules in the above-described embodiments is merely a logical functional division, and actual implementations may employ other division methods. For example, multiple units, modules, or components may be combined or integrated into another system, or some features may be omitted or not implemented.

[0097] In addition, unless otherwise specified, the functional units / modules in the various embodiments of the present application may be integrated into a single unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The aforementioned integrated units / modules may be implemented in the form of hardware or software program modules.

[0098] Figure 4 This is a schematic diagram of the structure of an electronic device suitable for a memory jitter observation method provided in an embodiment of the present application. Figure 4 As shown, the electronic device of this embodiment includes: at least one processor 40 ( Figure 4 Only one is shown in the figure) a processor, a memory 41, and a computer program stored in the memory 41 and executable on at least one processor 40. When the processor 40 executes the computer program, the steps of any of the above-mentioned method embodiments are implemented.

[0099] The electronic device may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will understand that Figure 4 These are merely examples of electronic devices and do not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, etc.

[0100] The processor 40 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor.

[0101] The specific implementation process of the processor 401 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0102] In some embodiments, the memory 41 may be an internal storage unit of the electronic device, such as the memory of the electronic device. In other embodiments, the memory 41 may also be an external storage device of the electronic device, such as a plug-in hard disk equipped on the electronic device, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card, etc. Furthermore, the memory 41 may also include both an internal storage unit of the electronic device and an external storage device. The memory 41 is used to store an operating system, application programs, a boot loader (BootLoader), data, and other programs, such as the program code of a computer program. The memory 41 may also be used to temporarily store data that has been output or is about to be output.

[0103] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0104] The computer-readable storage medium mentioned above can be implemented by any type of volatile or non-volatile memory 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 computer-readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0105] An exemplary readable storage medium is coupled to the processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in the above-mentioned electronic device.

[0106] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with 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. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0107] In the above embodiments, the description of each embodiment has its own emphasis. For parts not described in detail in a particular embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined in any way. To keep the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0108] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0109] It should be understood that the present application is not limited to the exact structure described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A memory jitter observation method, characterized in that: include: Acquire kernel events called by memory application based on preset hook points, wherein the hook points are trigger points corresponding to each kernel event, and the hook points are all mounted with memory information collection strategies corresponding to each kernel event; Based on the memory information collection strategy, memory information is collected for the kernel event, the collected memory information is mapped and stored, and a memory information file and a file descriptor having a corresponding relationship are obtained, wherein the file descriptor is used by the user end to obtain the memory information file; According to the preset jitter identification rule, it is determined whether the kernel event has memory jitter, and a memory jitter mark is performed on the kernel event that has memory jitter. The memory jitter mark is used to indicate in the file descriptor that the memory information file data corresponding to the file descriptor is abnormal.

2. The method according to claim 1, characterized in that The collecting memory information of the kernel event based on the memory information collection strategy includes: The task identification number ID, memory water level status and memory capacity of the kernel event are collected.

3. The method according to claim 2, characterized in that The kernel event includes processing a page fault event and a total entry memory allocation event, and the memory information collection for the kernel event based on the memory information collection strategy further includes: The processing duration of the kernel event is collected.

4. The method according to any one of claims 2 to 3, characterized in that: The determining whether memory jitter occurs in the kernel event according to a preset jitter identification rule includes: Determine whether the memory water level state threshold corresponding to the kernel event exceeds a preset first threshold; If so, confirm that memory jitter occurs in this kernel event; If not, confirm that no memory thrashing has occurred in this kernel event.

5. The method according to any one of claims 1 to 3, characterized in that: Before obtaining the kernel event of the memory application call based on the preset hook point, it includes: According to the kernel event corresponding to the hook point, at least one target memory information collection strategy matching the kernel event is obtained from the memory information collection strategy library, and the target memory information collection strategy is mounted to the hook point. The memory information collection strategy library stores the correspondence between each memory information collection strategy and each target memory information collection strategy and the kernel event.

6. The method according to claim 1, characterized in that After the memory jitter marking is performed on the kernel event where the memory jitter occurs, the method further includes: The memory information file containing the memory jitter mark is analyzed to generate a memory jitter result, and the memory jitter result is pushed to the user end.

7. The method according to claim 6, characterized in that The analyzing the memory information file to generate the memory jitter result includes: Summarize kernel events within a preset time period, and take kernel events containing the memory jitter mark as abnormal kernel events; The task IDs of the abnormal kernel events are counted, and a memory jitter result is generated according to the task IDs obtained by counting and the abnormal kernel events corresponding to the task IDs.

8. A memory jitter observation device, characterized in that: include: An event acquisition module, used to acquire kernel events called by memory application based on preset hook points, wherein the hook points are trigger points corresponding to each kernel event, and the hook points are all mounted with memory information collection strategies corresponding to each kernel event; A collection module, used for collecting memory information of the kernel event based on the memory information collection strategy, mapping and storing the collected memory information, obtaining a memory information file and a file descriptor having a corresponding relationship, and the file descriptor is used by the user end to obtain the memory jitter file; The jitter marking module is used to determine whether the kernel event has memory jitter according to preset jitter identification rules, and to mark the kernel event that has memory jitter as memory jitter. The memory jitter mark is used to indicate in the file descriptor that the memory information file data corresponding to the file descriptor is abnormal.

9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

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

11. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 7 when being executed by a processor.

Images