Data monitoring method and system for application, and electronic device

Abstract

Disclosed in the embodiments of the present disclosure are a data monitoring method and system for an application, and an electronic device. The method comprises: during the running of an application program, in response to a memory request instruction generated by the application program on an operating system platform, monitoring a free memory space in the operating system platform; if the attribute value of the free memory space is less than an attribute threshold, controlling the operating system platform to execute at least one memory reclamation operation, wherein the attribute value is used for indicating a storage capacity, which is available for a storage operation, of the free memory space; acquiring the time taken by the operating system platform for executing the memory reclamation operation; and on the basis of the time, determining a delay duration during which a request from the application program for a required memory from the operating system platform is delayed.

Description

[0001] Application Data Monitoring Method, System, and Electronic Device Cross-Reference This disclosure claims priority to Chinese patent application number 202311843491.1, filed with the China Patent Office on December 27, 2023, entitled "Application Data Monitoring Method, System, and Electronic Device," the entire contents of which are incorporated herein by reference. Technical Field: Embodiments of the present disclosure relate to the field of computers, and more specifically, to an application data monitoring method, system, and electronic device. Background: Currently, during the execution of an application, if an operating system (OS) encounters a page fault exception or other issues, memory allocation is required from the OS kernel (Linux). However, if memory is insufficient, sufficient memory can only be obtained through memory reclamation, which can cause application delays and other issues. This can further lead to application delay jitter and other issues, impacting the continuity of service for the application. Therefore, it is crucial to monitor the application's memory request process in real time and address issues such as delay jitter caused by this process during application execution. However, in related art Linux systems, the health of an entire application is typically measured from the perspective of overall machine resources. However, the aforementioned methods are less targeted at application latency and consumption, and can easily lead to misjudgments. Therefore, the technical problem of being unable to effectively detect the duration of delays when an application requests memory remains. Currently, no effective solution has been proposed to address this issue. SUMMARY OF THE INVENTION Embodiments of the present disclosure provide a method, system, and electronic device for monitoring application data to at least address the technical problem of being unable to effectively monitor the duration of delays when an application requests memory. According to one aspect of the embodiments of the present disclosure, a method for monitoring application data is provided. The method may include: during the execution of an application, in response to a memory request instruction generated by the application on the operating system platform, monitoring idle memory space in the operating system platform; if an attribute value of the idle memory space is lower than an attribute threshold, controlling the operating system platform to perform at least one memory reclamation operation, wherein the attribute value represents the amount of memory allowed for storage operations in the idle memory space; obtaining the duration consumed by the operating system platform in performing the memory reclamation operation; and, based on the duration, determining the duration of the delay in the application requesting the required memory from the operating system platform. According to another aspect of an embodiment of the present disclosure, a method for monitoring the delay duration of an application requesting memory is provided.The method may include: determining an application to be monitored in response to a data monitoring instruction applied to an operation interface; controlling the application to run in response to a program execution instruction applied to the operation interface; displaying idle memory space in the operating system platform on the operation interface in response to a memory request instruction generated by the application on the operating system platform; controlling the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is lower than an attribute threshold, wherein the attribute value represents the amount of memory allowed for storage operations in the idle memory space; and displaying on the operation interface the delay duration of the application requesting the required memory from the operating system platform, wherein the delay duration is determined based on the duration consumed by the operating system platform performing the memory reclamation operation. According to another aspect of an embodiment of the present disclosure, a method for monitoring application memory requests is provided. The method may include: determining identification information of an application to be monitored by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the identification information; monitoring idle memory space in the operating system platform in response to memory request instructions generated by the application on the operating system platform based on the identification information during the application's execution; controlling the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is lower than an attribute threshold, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space; obtaining the duration consumed by the operating system platform in performing the memory reclamation operation; determining, based on the duration, the delay duration of the application requesting the required memory from the operating system platform; and outputting the delay duration by calling a second interface, wherein the second interface includes a second parameter whose parameter value is the delay duration. According to another aspect of an embodiment of the present disclosure, a system for monitoring application data is also provided. The system may include: a terminal device, configured to upload identification information of an application to be monitored; a server, configured to monitor idle memory space in the operating system platform in response to a memory request instruction generated by the application on the operating system platform during the running of the application; if an attribute value of the idle memory space is lower than an attribute threshold, controlling the operating system platform to perform at least one memory reclamation operation, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space; obtaining a duration consumed by the operating system platform in performing the memory reclamation operation; and determining, based on the duration, a delay duration for the application to request the required memory from the operating system platform.According to another embodiment of the present disclosure, an electronic device is provided. The electronic device may include a memory and a processor: the memory is configured to store computer-executable instructions, and the processor is configured to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the computer-executable instructions implement any of the aforementioned application data monitoring methods. According to another embodiment of the present disclosure, a processor is provided. The processor is configured to run a program. When the program is executed, the processor executes any of the aforementioned application data monitoring methods. According to another embodiment of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored program. When the program is executed, the device containing the storage medium is controlled to execute any of the aforementioned application data monitoring methods. According to another embodiment of the present disclosure, a computer program product is provided. The computer program, when executed by the processor, implements any of the aforementioned application data monitoring methods. According to another embodiment of the present disclosure, a computer program, when executed by the processor, implements any of the aforementioned application data monitoring methods. In embodiments of the present disclosure, the running process of an application can be monitored in real time to determine whether a memory request instruction is generated on the operating system platform associated with the application. If no memory request instruction exists, this indicates that the current application does not need to request memory, and monitoring of the application can continue. If a memory request instruction exists, this indicates that the current application does need to request memory. Based on the memory request instruction, the state of the memory space in the operating system platform can be monitored to determine whether any of the memory spaces are idle. If any memory space is idle, the amount of storage allowed for storage operations in that memory space can be determined. This is done by comparing an attribute value with an attribute threshold. If the attribute value is lower than the attribute threshold, the duration required for the operating system platform to execute a memory reclamation operation must be determined. This duration can then be used to determine the delay required for the application to request memory from the operating system platform based on the memory request instruction.Considering that related technologies measure application health solely from the perspective of overall machine resources, which can lead to misjudgments and low accuracy, embodiments of the present disclosure can provide a dedicated latency metric for determining application memory requests, specifically determining the latency duration, to accurately measure the latency of applications requesting memory. This effectively avoids jitter caused by memory allocation delays, thereby achieving the technical effect of effectively monitoring the latency duration of applications requesting memory, and resolving the technical issue of being unable to effectively monitor the latency duration of applications requesting memory. It should be noted that the general description above and the detailed description that follow are intended only to illustrate and explain the present disclosure and do not constitute limitations of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are provided to explain the present disclosure and do not constitute undue limitations of the present disclosure. In the accompanying drawings: FIG1 is a schematic diagram of an application scenario of a method for monitoring data of an application program according to an embodiment of the present disclosure; FIG2 is a structural block diagram of a computing environment of a method for monitoring data of an application program according to an embodiment of the present disclosure; FIG3 is a flow chart of a method for monitoring data of an application program according to an embodiment of the present disclosure; FIG4 is a flow chart of a method for monitoring the delay duration of an application program requesting memory according to an embodiment of the present disclosure; FIG5 is a flow chart of a method for monitoring data of an application program requesting memory according to an embodiment of the present disclosure; FIG6 is a schematic diagram of a system for monitoring data of an application program according to an embodiment of the present disclosure; FIG7 is a flow chart of a method for allocating page frames in a kernel of an operating system platform according to an embodiment of the present disclosure; FIG8 is a schematic diagram of a method for measuring the delay of an application program requesting heap memory in a kernel of an operating system platform according to an embodiment of the present disclosure; FIG9 is a schematic diagram of a method for visually displaying delay duration according to an embodiment of the present disclosure; FIG10 is a schematic diagram of a device for monitoring data of an application program according to an embodiment of the present disclosure; FIG11 is a schematic diagram of a device for monitoring the delay duration of an application program requesting memory according to an embodiment of the present disclosure; FIG12 is a schematic diagram of a device for monitoring data of an application program requesting memory according to an embodiment of the present disclosure; FIG13 is a structural block diagram of a computer terminal according to an embodiment of the present disclosure; FIG14 is a block diagram of an electronic device for monitoring data of an application program according to an embodiment of the present disclosure; FIG15 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for monitoring application data according to an embodiment of the present disclosure.DETAILED DESCRIPTION To help those skilled in the art better understand the present disclosure, the following will provide a clear and complete description of the technical solutions in the embodiments of the present disclosure, in conjunction with the accompanying drawings. It should be noted that the described embodiments represent only a portion of the embodiments of the present disclosure, and are not exhaustive. Based on the embodiments of the present disclosure, all other embodiments devised by persons of ordinary skill in the art without inventive effort should fall within the scope of protection of the present disclosure. It should be noted that the terms "first," "second," and so on, in the specification and claims of the present disclosure, and in the accompanying drawings, are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that such terms are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or components is not necessarily limited to the steps or components expressly listed, but may include other steps or components not expressly listed or inherent to such process, method, product, or apparatus. First, some nouns or terms that appear in the description of the embodiments of the present disclosure are subject to the following explanations: memory zone list (zonelist) and memory zone (zone). In the Linux kernel, the memory manager divides the system's physical memory into different zones (zones). Each zone has an associated zonelist. A zonelist is a doubly linked list containing multiple zones / ZONEs. Each zone represents a continuous area of ​​physical memory; each zone has different characteristics and uses, such as the direct memory access area (ZONE.DMA), the general area (ZONE-NORMAL) and the high-end memory area (ZONE.HIGHMEM). These areas may have different access rights, mapping methods or available memory sizes, etc.; direct memory reclamation, during the slow memory allocation process of the Linux kernel, if page frames cannot be allocated from all zones in zonel ist, and after memory regularization, page frames still cannot be allocated, all zones in zonel ist will be reclaimed, blocking the application process; page fault exception, when the processor fetches instructions or data, the processor's memory management component needs to convert virtual addresses into physical addresses.If the virtual machine also fails to find the physical page, or lacks access rights, the processor will generate a page fault exception, known as a page fault exception. According to an embodiment of the present disclosure, a method for monitoring application data is provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system, such as a set of computer-executable instructions. While the flowcharts illustrate a logical sequence, in some cases, the steps shown or described may be executed in a different order. According to one aspect of an embodiment of the present disclosure, a method for monitoring application data is provided. As an optional implementation, the aforementioned method for monitoring application data may be, but is not limited to, applied to the application scenario shown in FIG1 . FIG1 is a schematic diagram of an application scenario of the method for monitoring application data according to an embodiment of the present disclosure. As shown in FIG1 , in the application scenario, a terminal device 102 may, but is not limited to, communicate with a server 106 via a network 104. The server 106 may, but is not limited to, perform operations on a database 108, such as write or read data operations. The terminal device 102 may, but is not limited to, include a human-computer interaction screen, a processor, and memory. The human-computer interaction screen may, but is not limited to, be used to display identification information, etc., of the application to be monitored on the terminal device 102. The processor may be configured, but is not limited to, to respond to the human-computer interaction operation and execute a corresponding operation, or to generate a corresponding instruction and send the generated instruction to the server 106. The memory may be configured to store relevant processing data, such as identification information of the application to be monitored, memory request instructions generated by the application, memory space in the operating system platform, and the duration of the memory delay required by the application. Alternatively, the following steps in the application data monitoring method may be performed on the server 106: Step S102: During the application's execution, in response to memory request instructions generated by the application on the operating system platform, monitor idle memory space in the operating system platform; Step S104: If an attribute value of the idle memory space is lower than an attribute threshold, control the operating system platform to perform at least one memory reclamation operation, wherein the attribute value represents the amount of memory allowed for storage operations in the idle memory space; Step S106: Obtain the duration consumed by the operating system platform to execute the memory reclamation operation; Step S108: Based on the duration, determine the duration of the delay caused by the application requesting the required memory from the operating system platform. By adopting the above method, the running process of the application can be monitored in real time to detect whether a memory request instruction is generated on the operating system platform associated with the application.If present, it indicates that the current application needs to request memory. Based on the memory request instruction, the memory space status in the operating system platform can be monitored to determine whether any of the memory spaces are idle. If any memory space is idle, the amount of storage allowed for storage operations in that memory space can be determined, i.e., the difference between the attribute value and the attribute threshold can be determined. If the attribute value is lower than the attribute threshold, the duration required for the operating system platform to perform memory reclamation operations must be determined. This duration can then be used to determine the delay required for the application to request memory from the operating system platform based on the memory request instruction. By providing a dedicated delay metric for determining application memory requests, i.e., determining the delay duration, the application's memory request delay can be accurately measured, effectively avoiding jitter caused by memory allocation delays. This effectively monitors the application's memory request delay, resolving the technical issue of being unable to effectively monitor the application's memory request delay. FIG2 is a block diagram of a computing environment for determining the layout information of sensing devices according to an embodiment of the present disclosure. As shown in FIG2 , computing environment 201 includes multiple computing nodes (e.g., servers) (illustrated as 210-1 and 210-2 in the figure) running on a distributed network. Each computing node includes local processing and memory resources. End users 202 can remotely run applications or store data in computing environment 201. Applications can be provided as multiple services 220-1, 220-2, 220-3, and 220-4 in computing environment 201, representing services "A," "D," "E," and "H," respectively. End users 202 can provision and access services through a web browser or other software application on a client. In some embodiments, end users 202's provisioning and / or requests can be provided to a portal gateway 230. The portal gateway 230 can include a corresponding agent to handle provisioning and / or requests for services (e.g., one or more services provided in computing environment 201). Services are provided or deployed based on various virtualization technologies supported by computing environment 201. In some embodiments, services may be provided based on virtual machine (VM)-based virtualization, container-based virtualization, and / or similar approaches. VM-based virtualization can simulate a real computer by initializing a virtual machine, allowing programs and applications to execute without directly accessing any actual hardware resources.While virtual machines virtualize machines, container-based virtualization can launch containers to virtualize entire operating systems, allowing multiple workloads to run on a single operating system instance. In one embodiment of container-based virtualization, several service containers can be assembled into a pod (e.g., a Kubernetes pod). For example, as shown in Figure 2, service 220-2 can be configured. One or more Pods 240-1, 240-2, 240-N (collectively referred to as Pods). A Pod may include an agent 245 and one or more containers 242-1,

[0002] 242-2, 242-M (collectively referred to as containers). One or more containers in a pod process requests related to one or more corresponding functions of a service. Proxy 245 typically controls network functions related to the service, such as routing and load balancing. Other services may also be equipped with pods similar to pods. During operation, executing a user request from end user 202 may require invoking one or more services in computing environment 201. Executing one or more functions of one service may require invoking one or more functions of another service. As shown in Figure 2, service "A" 220-1 receives a user request from end user 202 from ingress gateway 230. Service "A" 220-1 may invoke service "D" 220-2, and service "D" 220-2 may request service "E" 220-3 to execute one or more functions. The computing environment described above may be a cloud computing environment, where resource allocation is managed by the cloud service provider, allowing for feature development without having to worry about implementing, adjusting, or scaling servers. This computing environment allows developers to execute code in response to events without building or maintaining complex infrastructure. Instead of expanding a single hardware device to handle potential load, services can be segmented to complete a set of functions that can be automatically and independently scaled. In the aforementioned operating environment, the present disclosure provides an application data monitoring method as shown in Figure 3. It should be noted that the application data monitoring method of this embodiment can be executed by the mobile terminal of the embodiment shown in Figure 1. Figure 3 is a flow chart of an application data monitoring method according to an embodiment of the present disclosure. As shown in Figure 3, the method may include the following steps: Step S302: During the application's execution, in response to a memory request instruction generated by the application on the operating system platform, monitor idle memory space on the operating system platform. In the technical solution provided in step S302 of the present disclosure, during the application's execution, it is possible to monitor in real time whether the application generates a memory request instruction on the operating system platform. After detecting that a memory request instruction is generated on the operating system platform during the application's execution, the memory request instruction can be used to monitor idle memory space on the operating system platform. Applications may also be referred to as applications. The operating system platform can be used to allocate memory for applications and may be an OS system. The OS system may include an OS kernel, also referred to as Linux. Memory request instructions can be used to indicate memory requests issued by an application to an operating system platform. For example, instructions can be used to request heap memory for an application. The kernel of an operating system platform may include a memory manager. Memory space in the idle (free) state is also referred to as free memory.Memory space can also be referred to as memory or memory pages. Optionally, during application execution, instructions triggered by the application can be monitored in real time. If a memory request is needed, the corresponding operation can be executed to generate a memory request instruction. When a memory request instruction from an application is detected, the application can be controlled to send the memory request instruction to the corresponding operating system platform. Optionally, during application execution, if the operating system platform receives a memory request instruction from an application, the operating system platform can monitor the memory space status within the operating system platform in real time. For example, it can detect whether there is free memory space in the memory space available for the application to request. For example, the kernel within the operating system platform can monitor in real time whether a memory request instruction from an application has been received. Optionally, the memory manager can divide the operating system platform's physical memory into different zones, each of which has an associated memory zone list. The memory zone list is a doubly linked list that can contain multiple zones. Each zone represents a contiguous area within physical memory. Each zone has different characteristics and uses, such as the direct memory access zone (zone_DMA), the general zone (zone_Normal), and the high-end memory zone (zone-highmem). These zones may have different access permissions, mapping methods, or available memory sizes. It should be noted that the zones, characteristics, and uses included in the internal space described above are merely examples and are not specifically limited herein. Optionally, upon detecting that the operating system platform has received a memory request instruction from an application, the operating system platform may check a memory list contained in the memory list to determine the status of the memory zones included in the list, that is, to determine whether any memory zones are in an idle state. For example, all memory zones in the kernel may be traversed to determine the status of each memory zone during the traversal process. Idle memory zones may be designated as zone-free. In step S304, if the attribute value of the idle memory space is lower than the attribute threshold, the operating system platform is controlled to perform at least one memory reclamation operation. The attribute value represents the storage capacity allowed for storage operations in the idle memory space. In the technical solution provided in the above step S304 of the present disclosure, after monitoring the idle memory space in the operating system platform in response to the memory request instruction, if the attribute value of the idle memory space is lower than the attribute threshold, the operating system platform can be controlled to perform at least one memory reclaiming operation.The attribute value can be used to represent the amount of storage allowed for storage operations in idle memory space. The attribute value can be the number of free pages, free page frames, or free page frames. The attribute threshold, also known as the memory watermark, memory level, low memory level, or memory low watermark, can be used to indicate whether memory space is sufficient. For example, if the attribute value is lower than the attribute threshold, it indicates insufficient idle memory space; if the attribute value is greater than or equal to the attribute threshold, it indicates sufficient idle memory space. Memory reclamation operations, also known as memory reclamation behaviors, can include asynchronous memory reclamation phases, memory compression (memory regularization) phases, and direct memory reclamation phases. It should be noted that the number of phases and the operations performed in each phase of the aforementioned memory reclamation operations are for illustrative purposes only and are not intended to be limiting. Optionally, after determining the idle memory space from the kernel of the operating system platform, the number of pages in the idle memory space, that is, the size of the attribute value, can be determined, and the relationship between the attribute value and the attribute threshold can be determined. If the attribute value is less than the attribute threshold, it can indicate that the idle memory is insufficient, and corresponding memory reclamation operations need to be performed to increase the memory. Step S306: Obtain the duration consumed by the operating system platform in executing the memory reclamation operation. In the technical solution provided in step S306 of the present disclosure, after determining that the attribute value of the idle memory space is less than the attribute threshold and controlling the operating system platform to execute at least one memory reclamation operation, the duration consumed by the operating system platform in executing the memory reclamation operation can be obtained. The duration consumed in executing the memory reclamation operation can be used to indicate the delay consumed in each reclamation phase of the memory reclamation operation, and can also be referred to as memory reclamation delay. Optionally, after detecting that the number of free pages in a memory interval is lower than the memory low level, a memory reclamation process can be initiated. Specifically, the process can enter the asynchronous memory reclamation phase, the memory consolidation phase, and the direct memory reclamation phase. During this process, an Extended Berkeley Packet Filter (EBPF) can be used to initiate tracing of corresponding memory reclamation-related functions to calculate the duration of the memory reclamation operation. Each phase of the memory reclamation operation includes entry and exit tracepoints, which can be collectively referred to as entry and exit tracepoints.It should be noted that the above-mentioned process and method for calculating the duration consumed by a memory reclamation operation are provided for illustrative purposes only and are not specifically limited herein. Any process and method for calculating the duration consumed by a memory reclamation operation and thereby determining the latency consumed is within the scope of the embodiments of the present disclosure. For example, during the memory consolidation phase, fragmented, discontinuous small memory pages can be migrated and merged into larger, continuous memory pages. This phase is relatively time-consuming, and the entry and exit tracepoints of memory compression can be traced to determine the corresponding latency consumed. Step S308 determines the duration of the delay in the application program requesting the required memory from the operating system platform based on the duration. In the technical solution provided in step S308 of the present disclosure, after obtaining the duration consumed by the operating system platform in executing the memory reclamation operation, the duration of the delay in the application program requesting the required memory from the operating system platform can be determined based on the duration. The delay duration can be used to represent the application program's process memory request delay and can also be referred to as a process request delay indicator or a process request memory delay indicator. Optionally, based on the determined duration consumed by each memory reclamation phase during the memory reclamation operation, the overall delay duration when the application requests the required memory from the operating system platform can be determined. For example, the memory reclamation delays determined in the three memory reclamation phases can be accumulated to obtain the final process memory request delay. It should be noted that the above-described process and method for determining process memory request delay are merely illustrative and are not specifically limited herein. Any process and method capable of quantifying the delay duration based on the duration consumed by the memory reclamation operation is within the scope of protection of the embodiments of the present disclosure. Optionally, the obtained process memory request delay indicator is visualized. Because the Linux system in the related art lacks specific metrics to measure the delay consumption of an application when requesting memory during operation, and because Linux memory allocation delays can cause application jitter during actual application operation, the related art can also use a weak correlation approach to analyze applications, using this approach to measure the health of individual applications from the perspective of overall machine resources. However, this approach is prone to misjudgment and other issues, resulting in a technical problem of low accuracy in determining the delay consumption of Linux systems.However, in the disclosed embodiments, regular monitoring of free memory in the Linux memory normal zone and the corresponding memory watermark is performed. Delay consumption is then determined for memory reclamation, including asynchronous memory reclamation, memory compression, and direct memory reclamation. Since delay consumption can be obtained during memory reclamation, it is possible to determine not only whether delay consumption is incurred when the application requests memory, but also the extent of the delay consumption incurred. This achieves the goal of quantifying delay consumption with a specific metric, thereby improving the accuracy of determining delay consumption in Linux systems. Because the OS employs a delayed allocation principle when allocating memory to applications, actual memory requests occur when the application requires memory access. The OS generates a page fault exception, resulting in memory page frames being allocated from the OS kernel memory subsystem. Generally, when memory is sufficient, the application delay caused by the memory allocation process is negligible. However, when memory is insufficient, memory reclamation is required to obtain sufficient memory page frames. This resulting application delay can reach milliseconds or even seconds, which can lead to technical issues such as delay jitter in the application. However, in the embodiments of the present disclosure, considering the aforementioned application delay jitter, during the monitoring of the application's running process, the application's memory request latency can be visualized. During application execution, if a memory request instruction is detected, the number of free pages in the normal zone memory interval on the operating system platform can be monitored, and the free page count and the memory low watermark can be determined. If the number of free pages falls below the low watermark, EBPF can be used to initiate tracing of memory reclamation-related functions, calculate the delays in each memory reclamation phase during the memory reclamation operation, and ultimately determine the duration of the application's request for the required memory from the operating system platform. This achieves the goal of visualizing the memory request latency indicator for the process and further achieves the technical effect of avoiding delay jitter for the application. Through steps S302 to S308 of the present disclosure, the application's running process can be monitored in real time to detect whether a memory request instruction is generated on the operating system platform associated with the application. If no memory request instruction is present, it indicates that the current application does not need to request memory, and monitoring of the application can continue.If present, it indicates that the current application needs to request memory. Based on the memory request instruction, the memory space status in the operating system platform can be monitored to determine whether any of the included memory spaces are idle. If any memory space is idle, the amount of storage allowed for storage operations in that memory space can be determined, i.e., the difference between the attribute value and the attribute threshold can be determined. If the attribute value is lower than the attribute threshold, the duration required for the operating system platform to perform memory reclamation operations must be determined. This duration can then be used to determine the delay required for the application to request memory from the operating system platform based on the memory request instruction. The disclosed embodiment can provide a delay metric specifically for determining the application's memory request, namely, the delay duration, to accurately measure the application's memory request delay, thereby effectively avoiding jitter caused by memory allocation delays. This effectively monitors the application's memory request delay, resolving the technical issue of being unable to effectively monitor the application's memory request delay. The above-mentioned method of this embodiment is further described below. As an optional implementation, step S304, if the attribute value of the idle memory space is lower than the attribute threshold, controlling the operating system platform to perform at least one memory reclamation operation, includes: if the attribute value of the idle memory space is lower than the attribute threshold, controlling the operating system platform to call a memory reclamation function to control the operating system platform to perform the memory reclamation operation. In this embodiment, if the attribute value of the idle memory space is lower than the attribute threshold, the operating system platform may be controlled to call the memory reclamation function to perform the memory reclamation operation, where the memory reclamation function may be a memory reclamation-related function. Optionally, after receiving a memory request instruction from an application, the operating system platform may monitor the status of the memory space included in the operating system platform and determine the idle memory space from the memory space. The relationship between the attribute value of the idle memory space and the attribute threshold may be determined. If the attribute value is lower than the attribute threshold, it may indicate that the operating system platform is insufficiently equipped with memory. In this case, the operating system platform needs to be controlled to perform the corresponding memory reclamation operation to ensure that the operating system platform has sufficient memory required by the current memory request instruction for the application. If the attribute value is greater than or equal to the attribute threshold, the idle memory space can be directly provided to the corresponding application.Optionally, when it is determined that the attribute value of the idle memory space is lower than the attribute threshold, the operating system platform can be controlled to initiate a memory reclamation function through EBPF. The memory reclamation function controls the operating system platform to execute relevant phases of the memory reclamation operation. During the corresponding phases, the memory reclamation function is used to track the trace point at which the operating system platform is located. For example, the number of free pages in the normal zone memory interval and the memory low level watermark can be monitored. If the number of free pages is lower than the memory low level watermark, the system platform can be controlled to execute the asynchronous memory reclamation phase, the memory consolidation phase, and the direct memory reclamation phase of the memory reclamation operation. During this process, tracing of the memory reclamation-related functions can be initiated through EBPF, and the entry and exit trace points corresponding to the asynchronous memory reclamation phase, the memory consolidation phase, and the direct memory reclamation phase of the memory reclamation operation can be monitored. It should be noted that the above-mentioned process and method for controlling the operating system platform to execute the memory reclamation operation, as well as the memory reclamation function used, are merely illustrative and are not specifically limited herein. Any process or method capable of monitoring the duration of a memory reclamation operation is within the scope of protection of the embodiments of the present disclosure. As an optional implementation, step S306, obtaining the duration of the memory reclamation operation performed by the operating system platform, includes: tracing the calling process of the memory reclamation function to obtain a first tracing result; and determining the duration of the memory reclamation operation performed by the operating system platform based on the first tracing result. In this embodiment, the calling process of the memory reclamation function can be traced to obtain the first tracing result, and the duration of the memory reclamation operation performed by the operating system platform can be determined based on the first tracing result. The first tracing result can be used to indicate the tracking of exit and entry tracing points corresponding to each stage of the memory reclamation operation. Optionally, corresponding memory reclamation functions can be used to control different stages of the memory reclamation operation. That is, calling the corresponding memory reclamation function can control the operating system platform to execute the corresponding stage of the memory reclamation operation. The calling process of the memory recovery function can be traced, that is, the tracing of the memory recovery related functions is started through EBPF, thereby obtaining the first tracing result.Optionally, if the control operating system platform needs to perform an asynchronous memory reclamation phase in a memory reclamation operation, this phase can be divided into two scenarios, namely, reclamation by an integrated recovery unit (IRU) and reclamation by a memory allocation mechanism (slab), taking into account blocking points. It is necessary to track each of these two scenarios separately to obtain final first tracking results, and to determine the duration consumed by each scenario, thereby determining the duration consumed by the entire asynchronous memory reclamation phase. Optionally, if the control operating system platform needs to perform a memory consolidation phase in a memory reclamation operation, this memory consolidation phase can migrate and merge discontinuous small memory pages in the operating system platform into continuous, larger memory pages. This phase is relatively time-consuming, and the first tracking result of memory compression performed during this phase can be determined. Specifically, the exit and entry tracking points of the memory compression are tracked, and the duration consumed by the entire memory consolidation phase can be determined based on the times of these two tracking points. Optionally, if the control operating system platform needs to perform the direct memory reclamation phase of a memory reclamation operation, the memory reclamation time cost and reclamation intensity of this direct memory reclamation phase are higher than those of the asynchronous memory reclamation phase and the memory consolidation phase. Therefore, the latency consumed by this direct memory reclamation phase is also higher than those of the asynchronous memory reclamation phase and the memory consolidation phase. A first tracing result for direct memory reclamation during this phase can be determined. Specifically, the exit and entry tracing points of the direct memory reclamation phase are tracked, and the duration of the entire direct memory reclamation phase is determined based on the times of these two tracing points. As an optional implementation, the first tracing result includes a first moment when the memory reclamation operation begins and a second moment when the memory reclamation operation ends. Tracing the calling process of the memory reclamation function to obtain the first tracing result includes: obtaining the application process running state; if the running state is a process blocked state, tracking the first moment when the memory reclamation operation begins and the second moment when the memory reclamation operation ends during the calling process of the memory reclamation function. In this embodiment, while tracing the calling process of the memory reclamation function to obtain the first tracing result, the application process running state can be obtained to determine whether the process running state is in a blocked state. If so, the first time when the memory reclamation operation starts and the second time when the memory reclamation operation ends can be tracked during the calling process of the memory reclamation function to obtain the first tracing result. The first tracing result may include the first time and the second time included in each stage of the memory reclamation operation. The first time may be the entry tracing point.The second moment can be the exit trace point. Optionally, if the operating system platform is performing an asynchronous memory reclamation phase during a memory reclamation operation, this phase is inherently asynchronous and will not block the application process. However, potential blocking points need to be considered, such as IRU reclamation and slab reclamation. Optionally, when reclaiming memory pages in the inactive integrated reclamation unit (IRU) linked list, the application process may be blocked due to waiting for 10 seconds. Therefore, the memory reclamation function of io_schedule needs to be used for tracking. Finally, the call stack can be filtered to determine the latency caused by IRU reclamation. For example, for IRU reclamation, kernel debugging tools (kprobes) can be used to track the pre- and post-reclamation phase, tracking the entry and exit trace points of the memory reclamation phase. Specifically, the entry trace point is kprobe / io_schedule, and the exit trace point is retkprobe / io_schedule. The first moment corresponding to the entry trace point is T1, and the second moment corresponding to the exit trace point is T2. Optionally, the process of partially reclaiming slabs may cause the application process to be blocked. Therefore, the entry and exit trace points of slab reclaim can be tracked to obtain the final delay of the slab reclaim phase. For example, for slab reclaim, the situation before and after the reclaim phase can be monitored, and the entry and exit trace points of the slab reclaim phase can be obtained. Specifically, the entry trace point is tracepoint / trace_mm_shr ink-slab-start, and the first time corresponding to the entry trace point can be T3. The exit trace point can be tracepoint / trace_mm_shr ink_slab.end, and the second time corresponding to the exit trace point can be T4. It should be noted that the above-mentioned methods of tracing the functions used for the entry and exit trace points and setting the corresponding trace point names are merely illustrative and are not specifically limited herein. As an optional implementation, determining the duration consumed by the operating system platform for executing the memory reclaim operation based on the first tracking result includes: obtaining an interval between the second moment and the first moment; and determining the interval as the duration consumed by the operating system platform for executing the memory reclaim operation.In this embodiment, after obtaining the first and second times, the interval between the second and first times can be determined based on the first and second times. This interval can be determined as the duration consumed by the operating system platform when executing the corresponding phase of the memory reclamation operation. Optionally, for the IRU reclamation phase within the asynchronous memory reclamation phase, the difference between the second and first times of this phase can be determined as the delay incurred by the operating system platform when executing the IRU reclamation phase, i.e., the duration consumed. For example, if the first time of the IRU reclamation phase is T1 and the second time is T2, (T2-T1) can be determined as the delay incurred by the IRU reclamation phase, i.e., the duration consumed by the IRU reclamation phase. Optionally, for the slab reclamation phase within the asynchronous memory reclamation phase, the difference between the second and first times of this phase can be determined as the delay incurred by the operating system platform when executing the slab reclamation phase, i.e., the duration consumed. For example, if the first moment of the S Lab recovery phase is T3 and the second moment is T4, (T4-T3) can be determined as the delay generated by the S Lab recovery, that is, the duration consumed by the S Lab recovery phase. Alternatively, for the memory consolidation phase, the difference between the second moment and the first moment of the phase can be determined as the delay generated by the operating system platform when executing the memory consolidation phase, that is, the duration consumed. For example, if the first moment of the memory consolidation phase is T5 and the second moment is T6, (T6-T5) can be determined as the delay generated by the memory consolidation phase, that is, the duration consumed by the memory consolidation phase. Alternatively, for the direct memory consolidation phase, the difference between the second moment and the first moment of the phase can be determined as the delay generated by the operating system platform when executing the direct memory consolidation phase, that is, the duration consumed. For example, the first time of the direct memory reclamation phase is T7, and the second time is T8. (T8 - T7) can be determined as the delay generated by the direct memory reclamation phase, that is, the duration consumed by the direct memory reclamation phase. As an optional implementation, during the calling process of a memory reclamation function, tracking the first time when the memory reclamation operation begins and the second time when the memory reclamation operation ends includes: tracing the entry tracing point during the calling process of the memory reclamation function to obtain the first time; and tracing the exit tracing point during the calling process of the memory reclamation function to obtain the second time.In this embodiment, the entry tracing point during the memory reclamation function call process can be tracked to obtain a first moment, and the exit tracing point during the memory reclamation function call process can be tracked to obtain a second moment. The entry tracing point can be used to indicate the time point at which the corresponding phase of the memory reclamation operation begins. The exit tracing point can be used to indicate the time point at which the corresponding phase of the memory reclamation operation ends. Optionally, for each phase of the memory reclamation operation executed by the operating system platform, the time point at which each phase begins can be determined as the entry tracing point, and this time point can be recorded as the first moment. The time point at which the corresponding phase ends can be determined as the exit tracing point, and this time point can be recorded as the second moment. Optionally, if the operating system is performing the memory compaction phase of a memory reclamation operation, the operating system can detect the conditions before and after the memory compression operation in this phase. The start of the memory compression operation can be determined as the entry trace point. Specifically, the entry trace point can be tracepoint / trace_mm_compaction_begin, the exit active point can be tracepoint / trace_mm_compaction_end, and the first time corresponding to the entry trace point can be T5, while the second time corresponding to the exit trace point can be T6. Alternatively, if the operating system is performing the internal direct reclamation phase of a memory reclamation operation, the operating system can detect the conditions before and after the internal direct reclamation operation in this phase. The start of the direct memory reclamation operation can be determined as the entry trace point. Specifically, the first time corresponding to the entry trace point can be set to T7, and the entry trace point can be set to tracepoint / trace_mm_vmscan_di:rect_:reclaim_begin. The exit trace point can be set to tracepoint / trace_mm-vmscan-direct-reclaim_end, and the second time corresponding to the exit trace point can be determined as T8. As an optional implementation, step S308, based on the duration, determines the delay duration of the application program requesting the required memory from the operating system platform. This includes: obtaining overlapping durations from multiple durations corresponding to multiple memory reclaim operations; filtering out the overlapping durations from the multiple durations; and determining the delay duration based on the filtered multiple durations.In this embodiment, when determining the delay duration of an application program requesting required memory from the operating system platform based on the duration, overlapping durations from multiple durations corresponding to various memory reclamation operations can be obtained. The overlapping durations can be filtered out from the multiple durations, and the delay duration can be determined based on the filtered multiple durations. The overlapping durations can be overlapping data during the memory reclamation operation, for example, overlapping data between an asynchronous memory reclamation phase and a direct memory reclamation phase. Filtering out the overlapping durations from the multiple durations can be a data cleansing operation. Optionally, a data cleansing operation can be performed on the durations obtained during the asynchronous memory reclamation phase to filter out overlapping durations from the multiple obtained durations. That is, for the durations during the asynchronous memory reclamation phase, it can be determined whether any of the determined durations overlap with those during the direct memory reclamation phase. If so, the overlapping durations can be removed from the durations during the asynchronous memory reclamation phase, and the delay duration can be determined from the remaining durations. Optionally, IRU recovery call stack information and SLab recovery call stack information are obtained. Based on these two call stack information, the portion of the call stack containing direct memory recovery data can be filtered out, and the filtered asynchronous memory recovery delay can be determined. For example, the data call stack captured during the asynchronous memory recovery phase can be obtained, and the portion of the call stack containing direct memory recovery functions can be filtered out to obtain the filtered delay duration, namely, T4 - T3 + T2 - TL. It should be noted that the above data cleaning process and method are merely illustrative and are not specifically limited herein. Any process and method that can eliminate the duration obtained during the asynchronous memory recovery phase that overlaps with the duration during the direct memory recovery phase is within the scope of the present disclosure. As an optional implementation, determining the delay duration based on multiple filtered durations includes: accumulating the multiple filtered durations to obtain an accumulated duration; and determining the delay duration based on the accumulated duration. In this embodiment, the filtered durations can be accumulated to obtain an accumulated duration, which can be determined as the delay duration. The accumulated duration can also be referred to as delay data. Optionally, the duration of the asynchronous memory reclamation phase obtained after data cleaning is accumulated with the duration of the memory regularization phase and the duration of the direct memory reclamation phase to obtain the final delay duration.For example, the duration of the asynchronous memory reclamation phase is (T4-T3+T2-T1), the duration of the memory cleanup phase is (T6-T5), and the duration of the direct memory reclamation phase is (T8-T7). The durations of these three phases of the memory reclamation operation are accumulated, that is, all memory reclamation delays are accumulated to obtain T8-T7+T6-T5+(T4-T3+T2-T1). As an optional implementation, determining the delay duration based on the accumulated durations includes: determining the abnormal duration of the application in the primary page fault abnormal state within the accumulated durations; and filtering out the abnormal durations from the accumulated durations to obtain the delay duration. In this embodiment, when determining the delay duration based on the accumulated duration, the abnormal duration of the application in the major page fault state can be determined from the accumulated duration. The abnormal duration can then be filtered out from the accumulated duration to obtain the final delay duration. The abnormal duration of the major page fault state can be data from the process in which the major page fault occurred. In the disclosed embodiment, to ensure the accuracy of the determined delay duration, the accuracy of the accumulated duration must be considered. Specifically, whether the accumulated duration corresponds to the major page fault state is considered. If so, the abnormal duration corresponding to the major page fault state can be eliminated. The final accumulated duration after elimination is then determined as the delay duration. This ensures the accuracy of the accumulated duration, thereby achieving the technical effect of improving the accuracy of the delay duration determination. For example, the data of the process that has a primary page fault exception can be filtered out, and the application's process memory request delay is T8-T7+T6-T5 + (T4-T3+T2-T1). oAs an optional implementation, the method further includes: determining the storage area where the memory space is located in the operating system platform; determining an attribute threshold matching the storage area, wherein the attribute threshold is used to represent the minimum storage capacity allowed for storage operations in the storage area. In this embodiment, the storage area where the memory control is located in the operating system platform can be determined, and an attribute threshold matching the storage area can be determined, wherein the attribute threshold is used to represent the minimum storage capacity allowed for storage operations in the storage area. Optionally, the attribute threshold matching the threshold is determined based on the size of the storage area in the kernel of the operating system platform. For example, the attribute threshold can be determined based on the low-level memory watermark value and reserved memory. For another example, the memory low-level watermark = the low-level memory watermark value + the reserved memory. As an optional implementation, the method further includes: calling a memory request function to request memory required by the application from the operating system platform; tracing the calling process of the memory request function to obtain a second tracing result; and, in response to a failure to obtain the duration consumed by the operating system platform to perform the memory reclamation operation, determining a delay duration based on the second tracing result. In this embodiment, a memory allocation function can be called to request memory required by an application from the operating system platform. The calling process of the memory allocation function can be tracked to obtain a second tracing result. If the time consumed by the operating system platform to execute a memory reclamation operation fails to be obtained, the delay duration can be determined based on the second tracing result. The second tracing result can be used to indicate the result obtained by tracing the entry and exit of the memory allocation function in the kernel by calling the memory allocation function. In the disclosed embodiment, the second tracing result can be obtained directly by tracing the entry and exit of the memory allocation function in the kernel, that is, by tracing the entry and exit tracing points of the calling process of the memory allocation function. A first time corresponding to the entry and exit tracing points and a second time corresponding to the exit tracing point can be determined. The delay duration can be determined by the difference between the second time and the first time. In the disclosed embodiments, two methods can be designed to determine the delay duration. The first method involves tracking the calling process of the memory reclamation function. By determining the first and second times corresponding to each stage in the calling process, the duration consumed by each stage is determined, and the final delay duration is accumulated. However, if an exception occurs during the execution of the above method, for example, the calculation of the duration consumed by the memory reclamation operation fails, the second method can be used to calculate the delay duration. In other words, the memory request delay can be obtained by directly tracking the entry and exit of the memory request function in the kernel of the operating system platform.However, while the second method is simple to operate and easy to implement, memory requests are hotspots in the system, and the trace points themselves incur overhead of a few tenths of a microsecond or even several microseconds, which can reduce performance during normal memory requests. Therefore, the second method can be set as a backup solution. In the event of an exception with the first method, the second method can be urgently invoked to ensure efficiency during memory requests. As an optional embodiment, the method further includes: displaying the delay duration on an operation interface; and / or outputting a prompt message corresponding to the delay duration. In this embodiment, the delay duration can be displayed on the operation interface, or a prompt message corresponding to the delay duration can be displayed on the operation interface, where the prompt message is used to issue an alarm. Alternatively, corresponding alarm rules can be preconfigured for the operating system platform. If a delay is detected, a corresponding prompt message can be issued on the operation interface of the terminal device corresponding to the application to indicate the delay. Optionally, to more clearly display the metrics used to measure whether memory requests during application execution incur delay consumption, a visual presentation can be used. That is, the obtained delay duration can be conveyed to the user interface for display through a visual design. For example, the delay duration can be processed in various graphical formats and displayed on the user interface at a specific coordinate, such as a line graph. The delay duration can also be displayed numerically on the user interface. It should be noted that the above-mentioned formats and methods for displaying the delay duration on the user interface are merely illustrative and are not specifically limited herein. Any process or method capable of determining the delay duration and visually displaying it on the user interface is within the scope of the embodiments of this disclosure. As an optional embodiment, the at least one memory reclamation operation includes at least one of the following: an asynchronous memory reclamation operation; a memory consolidation operation; or a direct memory reclamation operation. In this embodiment, the at least one memory reclamation operation can include at least one of the following: an asynchronous memory reclamation operation; a memory consolidation operation; and a direct memory reclamation operation. The asynchronous memory reclamation operation can be performed during the asynchronous memory reclamation phase. The memory consolidation operation can be performed during the memory consolidation phase. The direct memory reclamation operation can be performed during the direct memory reclamation phase. Optionally, in the case of memory reclamation, the memory page frame allocation delay is generally at the level of a few tenths of a microsecond or several microseconds, and its impact can be ignored, so the allocation delay can be considered zero. When memory reclamation is involved, there is a non-negligible delay. Therefore, the embodiment of the present disclosure needs to calculate the delay caused by the memory reclamation operation as the delay of the operating system platform allocating memory to the application.Optionally, based on the above analysis, to ensure accurate calculation of the delay during the memory reclamation operation, it is necessary to focus on the operations involved in the memory reclamation operation. Specifically, the duration of each stage during the memory reclamation operation needs to be determined, thereby accumulating the duration of the entire memory reclamation operation process. This ensures the accuracy of the determined delay duration. The present embodiment also provides a method for monitoring the delay duration of an application requesting memory, based on a human-computer interaction example. FIG4 is a flowchart of a method for monitoring the delay duration of an application requesting memory, according to an embodiment of the present disclosure. As shown in FIG4 , the method may include the following steps: Step S402: Responding to a data monitoring instruction on an operation interface, determining an application to be monitored. In the technical solution provided in step S402 of the present disclosure, a corresponding operation can be performed on the operation interface to generate a corresponding data monitoring instruction, based on whether it is necessary to monitor whether there is any delay consumed when the application requests memory from the operating system platform. This determines the application to be monitored. Optionally, if a data monitoring instruction is detected on the operation interface, the application associated with the current operating system platform can be monitored to detect whether the application needs to start running. In other words, the application can be detected to determine whether it has sent a program run instruction. Detection of a program run instruction indicates that the application has started running. Step S404: Control the application's execution in response to the program run instruction on the operation interface. In the technical solution provided in step S404 of the present disclosure, upon detecting the program run instruction on the operation interface, the application can be controlled to execute. Optionally, during the execution of the application, it can be detected whether the application needs to request memory space from the associated operating system platform. In other words, upon detecting the memory request instruction generated by the application on the operating system platform, it can be detected. Step S406: In response to the memory request instruction generated by the application on the operating system platform, the idle memory space on the operating system platform can be displayed on the operation interface. In the technical solution provided in step S406 of the present disclosure, upon detecting the memory request instruction generated by the application on the operating system platform, the idle memory space on the operating system platform can be displayed on the operation interface. Optionally, when it is detected that the operating system platform receives a memory request instruction from an application, the memory list contained in the operating system platform can be checked to determine the status of the memory areas contained in the memory list, that is, to determine whether there is an idle memory area in the memory area.Optionally, if idle memory space in the operating system platform is determined based on the memory request instruction, the idle memory space can be displayed on the operation interface. In step S408, if the attribute value of the idle memory space is lower than the attribute threshold, the operating system platform is controlled to perform at least one memory reclamation operation, where the attribute value indicates the amount of storage allowed for storage operations in the idle memory space. In the technical solution provided in step S408 of the present disclosure, if the attribute value of the idle memory space is lower than the attribute threshold, the operating system platform is controlled to perform at least one memory reclamation operation, where the attribute value indicates the amount of storage allowed for storage operations in the idle memory space. Optionally, after determining the idle memory space in the operating system platform kernel, the number of pages in the idle memory space, that is, the size of the attribute value, can be determined, and the relationship between the attribute value and the attribute threshold can be determined. If the attribute value is lower than the attribute threshold, it can indicate that the idle memory is insufficient, and a corresponding memory reclamation operation needs to be performed to increase the memory capacity. In embodiments of the present disclosure, regular monitoring of free memory in the Linux memory normal zone and the corresponding memory watermark can be performed. Delay consumption can then be determined for memory reclamation stages such as asynchronous memory reclamation, memory compression, and direct memory reclamation. Since delay consumption can be obtained during memory reclamation, during application execution, not only can it be determined whether delay consumption occurs when the application requests memory, but also the extent of the delay consumption incurred can be determined. This achieves the goal of quantifying delay consumption using a specific metric, thereby improving the accuracy of determining delay consumption in Linux systems. Step S410 displays the delay duration of the application requesting the required memory from the operating system platform on the operation interface. The delay duration is determined based on the duration of the memory reclamation operation performed by the operating system platform. In the technical solution provided by step S410 of the present disclosure, the delay duration of the application requesting the required memory from the operating system platform can be displayed on the operation interface. The delay duration can be determined based on the duration of the memory reclamation operation performed by the operating system platform. Optionally, after detecting that the number of free pages in the memory interval is lower than the memory low level, a memory reclamation process may be initiated, that is, the asynchronous memory reclamation phase, the memory consolidation phase, and the direct memory reclamation phase may be entered.During this process, EBPF can be used to enable tracing of the corresponding memory reclamation-related functions to calculate the duration of the memory reclamation operation. Alternatively, based on the durations determined for each memory reclamation phase, the overall delay in the application requesting the required memory from the operating system platform can be determined. For example, the memory reclamation delays determined for the three memory reclamation phases can be accumulated to obtain the final process memory request delay. Optionally, after the delay duration is determined based on the above steps, it can be sent to a user interface for visualization. Through steps S402 to S410 of the present disclosure, in response to a data monitoring instruction on the operation interface, an application to be monitored is determined; in response to a program execution instruction on the operation interface, the application execution is controlled; in response to a memory request instruction generated by the application on the operating system platform, idle memory space in the operating system platform is displayed on the operation interface; if an attribute value of the idle memory space is lower than an attribute threshold, the operating system platform is controlled to perform at least one memory reclamation operation, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space; and the delay duration of the application requesting the required memory from the operating system platform is displayed on the operation interface, wherein the delay duration is determined based on the time consumed by the operating system platform to perform the memory reclamation operation. This achieves the technical effect of effectively monitoring the delay duration when the application requests memory, resolving the technical problem of being unable to effectively monitor the delay duration when the application requests memory. The present disclosure also provides a method for monitoring data on application memory requests. Figure 5 is a flowchart of a method for monitoring application memory requests according to an embodiment of the present disclosure. As shown in Figure 5, the method may include the following steps: Step S502: Determine identification information of the application to be monitored by calling a first interface, wherein the first interface includes a first parameter, the parameter value of which is identification information. In the technical solution provided in step S502 of the present disclosure, the identification information of the application to be monitored can be determined by calling the first interface, wherein the first interface may include a first parameter, the parameter value of which may be representation information. The identification information can be used to label different applications, for example, by assigning a number to each application. It should be noted that the above identification information is for illustrative purposes only and is not a specific limitation herein. Alternatively, each application can be pre-numbered to obtain corresponding identification information. The identification information can reflect the memory request requirements and operational requirements of different applications.In step S504, during the application's execution, based on the identification information and in response to memory request instructions generated by the application on the operating system platform, the idle memory space on the operating system platform is monitored. In the technical solution provided in step S504 of the present disclosure, during the application's execution, it is possible to monitor in real time whether the application generates memory request instructions on the operating system platform. Optionally, by detecting the acquired identification information, the application's execution status and whether it has a memory request requirement can be determined. If the identification information indicates that the application is in the execution state, the application can be monitored to determine whether a memory request instruction has been generated on the operating system platform. Optionally, during the application's execution, if there is a need to request memory, corresponding operations can be performed to generate a memory request instruction. The application can also be controlled to send the memory request instruction to the corresponding operating system platform. Optionally, during the application's execution, the kernel in the operating system platform can monitor in real time to determine whether a memory request instruction from a particular application has been received. Optionally, after monitoring the generation of a memory request instruction on the operating system platform during the execution of an application, the operating system platform can monitor idle memory space based on the memory request instruction. Optionally, after monitoring the reception of a memory request instruction from an application by the operating system platform, the operating system platform can detect a memory list contained in the operating system platform to determine the status of the memory areas contained in the memory list, that is, to determine whether there are idle memory areas in the memory list. Optionally, all memory zones in the kernel can be traversed to determine the status of each memory zone during the traversal process, and idle memory zones can be determined as zone-free. In step S506, if the attribute value of the idle memory space is lower than an attribute threshold, the operating system platform is controlled to perform at least one memory reclamation operation, where the attribute value represents the storage capacity allowed for storage operations in the idle memory space. In the technical solution provided in step S506 of the present disclosure, after monitoring the idle memory space in the operating system platform in response to the memory request instruction, if the attribute value of the idle memory space is lower than the attribute threshold, the operating system platform can be controlled to perform at least one memory reclamation operation.Optionally, after determining the memory space in the idle state from the kernel of the operating system platform, the number of pages in the idle memory space, that is, the size of the attribute value, can be determined, and the relationship between the attribute value and the attribute threshold can be determined. If the attribute value is less than the attribute threshold, it can be indicated that the idle memory is insufficient. In this case, a corresponding memory reclamation operation needs to be performed to increase the memory to ensure that the memory size required for the currently received memory request instruction is met. Step S508: The duration consumed by the operating system platform in executing the memory reclamation operation is obtained. In the technical solution provided in step S508 of the present disclosure, after determining that the attribute value of the idle memory space is less than the attribute threshold and controlling the operating system platform to execute at least one memory reclamation operation, the duration consumed by the operating system platform in executing the memory reclamation operation can be obtained. Optionally, after monitoring that the number of free pages in the memory interval is less than the memory low level, the memory reclamation operation process can be initiated, that is, the asynchronous memory reclamation phase, the memory consolidation phase, and the direct memory reclamation phase can be entered. During this process, EBPF can be used to enable tracing of corresponding memory reclamation-related functions to calculate the duration consumed by the memory reclamation operation. In step S510, based on the duration, the delay duration of the application program requesting the required memory from the operating system platform is determined. In the technical solution provided in step S510 of the present disclosure, after obtaining the duration consumed by the operating system platform in executing the memory reclamation operation, the duration of the delay duration of the application program requesting the required memory from the operating system platform can be determined based on the duration. Alternatively, the overall delay duration of the application program requesting the required memory from the operating system platform can be determined based on the duration consumed by each memory reclamation phase in the memory reclamation operation. For example, the memory reclamation delays determined in the three memory reclamation phases can be accumulated to obtain the final process memory request delay. In step S512, the delay duration is output by calling a second interface, where the second interface includes a second parameter whose value is the delay duration. In the technical solution provided in step S512 of the present disclosure, the delay duration can be output by calling a second interface. The second interface can include a second parameter, and the second parameter can be the delay duration. Optionally, the delay duration can be transmitted to an operation interface through the second interface, and the delay duration can be visually presented on the operation interface.Through steps S502 to S512 of the present disclosure, the identification information of the application to be monitored is determined by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the application. During the execution of the application, based on the identification information, idle memory space in the operating system platform is monitored in response to a memory request instruction generated by the application on the operating system platform. If an attribute value of the idle memory space is lower than an attribute threshold, the operating system platform is controlled to perform at least one memory reclamation operation, wherein the attribute value represents the storage capacity allowed for storage operations in the idle memory space. The duration consumed by the operating system platform to perform the memory reclamation operation is obtained. Based on the duration, the delay duration caused by the application requesting the required memory from the operating system platform is determined. The delay duration is output by calling a second interface, wherein the second interface includes a second parameter whose parameter value is the delay duration. This achieves the technical effect of being able to effectively monitor the delay duration when the application requests memory, and solves the technical problem of being unable to effectively monitor the delay duration when the application requests memory. According to an embodiment of the present disclosure, an embodiment of an application data monitoring system is also provided. FIG6 is a schematic diagram of an application data monitoring system according to an embodiment of the present disclosure. As shown in FIG6 , application data monitoring system 600 may include a terminal device 601 and a server 602. Terminal device 601 is used to upload identification information of an application to be monitored. In this embodiment, identification information of an application to be monitored can be uploaded via terminal device 601. Optionally, an application with unique identification information can be deployed in the terminal device. Through a one-to-many association between the terminal device and the server, the server can monitor the identification information uploaded by the terminal device to analyze whether the application corresponding to the received identification information is in operation and whether it has a memory request from the operating system platform. Server 602 is configured to monitor idle memory space in the operating system platform in response to a memory request instruction generated by the application on the operating system platform during application execution; control the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is lower than an attribute threshold, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space; obtain a duration consumed by the operating system platform in performing the memory reclamation operation; and determine, based on the duration, a delay duration for the application to request the required memory from the operating system platform.In this embodiment, after receiving the identification information sent by the terminal device 601, the server 602 can analyze whether the application corresponding to the identification information is currently running. If so, the server 602 can monitor whether the application has a memory request instruction on the operating system platform. If so, the server 602 can monitor the idle memory space on the operating system platform based on the memory request instruction. The server 602 can also monitor the attribute value of the idle memory space to determine whether the attribute value is below an attribute threshold. If the attribute value is below the attribute threshold, it indicates that there is insufficient memory. The server 602 can then control the operating system platform to perform a corresponding memory reclamation operation to increase the memory in the operating system platform. The server 602 can also obtain the time consumed by the memory reclamation operation to determine the delay duration. Optionally, if there is a need to request memory during the running of the application, the server 602 can perform a corresponding operation to generate a memory request instruction. The server can then control the application to send the memory request instruction to the corresponding operating system platform. Optionally, the memory manager can divide the physical memory of the operating system platform into different zones, each zone having an associated memory zone list. The memory zone list is a doubly linked list that can contain multiple zones. Each zone represents a contiguous area within a segment of physical memory. Each zone has different characteristics and uses, such as the direct memory access zone (zone_DMA), the general zone (zone_Normal), and the high-end memory zone (zone-highmem). These zones may have different access permissions, mapping methods, or available memory sizes. Optionally, upon detecting that the operating system platform has received a memory request instruction from an application, the memory list contained in the operating system platform can be checked to determine the status of the memory zones included in the memory list, that is, to determine whether there are any idle memory zones within the memory list. Optionally, after determining the idle memory space from the operating system platform kernel, the number of pages in the idle memory space can be determined, that is, the size of the attribute value, and the relationship between the attribute value and the attribute threshold can be determined. If the attribute value is less than the attribute threshold, it indicates that the idle memory is insufficient, and appropriate memory reclamation operations need to be performed to increase memory capacity. Optionally, after detecting that the number of free pages in the memory interval is lower than the memory low level, a memory reclamation process may be initiated, that is, the asynchronous memory reclamation phase, the memory consolidation phase, and the direct memory reclamation phase may be entered.During this process, EBPF can be used to enable tracing of corresponding memory reclamation-related functions to calculate the duration consumed by the memory reclamation operation. Alternatively, the overall delay in the application requesting the required memory from the operating system platform can be determined based on the duration consumed by each memory reclamation phase. For example, the memory reclamation delays determined in the three memory reclamation phases can be accumulated to obtain the final process memory request delay. This embodiment provides an application data monitoring system. The system uploads identification information of an application to be monitored via a terminal device; monitors memory request instructions generated by the application on an operating system platform while the application is running, via a server; monitors idle memory space in the operating system platform in response to the memory request instructions; controls the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is lower than an attribute threshold, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space; obtains the duration consumed by the operating system platform in performing the memory reclamation operation; and, based on the duration, determines the duration of the delay caused by the application requesting the required memory from the operating system platform. This achieves the technical effect of effectively monitoring the delay duration when the application requests memory, and solves the technical problem of being unable to effectively monitor the delay duration when the application requests memory. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in this disclosure, such as data used for verification, are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation interfaces are provided for users to choose to authorize or deny. Currently, there are no specific metrics in the Linux system to measure the latency consumption when an application requests memory during operation. In actual operation and maintenance, application jitter is caused by kernel memory allocation delays. Existing analysis methods use a weak correlation approach, that is, measuring the health of individual applications from the perspective of overall machine resources, which is prone to misjudgment. Therefore, there is still a technical problem of being unable to effectively monitor the delay duration when an application requests memory. During application execution, applications frequently request heap memory. Generally, the OS allocates memory to applications using the principle of delayed allocation. Therefore, actual memory request occurs when an application needs to access memory. The system generates a page fault exception and allocates memory page frames from the OS kernel memory subsystem.Generally, when memory is abundant, the application latency caused by this allocation process is negligible. However, when memory is insufficient, memory reclamation is required to obtain sufficient memory page frames, resulting in application latency that can reach milliseconds or even seconds. This can cause application jitter and impact service continuity. Therefore, visualizing application memory request latency is crucial for monitoring daily application operations. Currently, there are no specific metrics in Linux systems to measure whether and how much latency is incurred when an application requests memory during operation. Even in actual operations and maintenance, existing analysis methods employ weak correlations. For example, if an application experiences an anomaly, they check for drops or sudden increases in the overall machine memory level, or use system monitoring commands to check for memory reclamation-related statistics within a corresponding time interval (10-minute interval). If so, the anomaly is likely due to insufficient memory and memory reclamation. This approach measures the health of individual applications from the perspective of overall machine resources, which can easily lead to misjudgments. Because the application may not have requested memory when the system is reclaiming memory, the anomaly may be caused by other reasons. Therefore, the technical problem of being unable to effectively monitor the delay duration when an application requests memory remains. Furthermore, the present disclosure provides a method for measuring heap memory latency in Linux system applications. This method addresses the technical problem of being unable to effectively monitor the delay duration when an application requests memory. Unlike traditional solutions that measure application health solely from the perspective of overall machine resources, which can lead to misjudgments and low accuracy, this method addresses the technical problem of being unable to effectively monitor the delay duration when an application requests memory. In an embodiment of the present disclosure, the running process of an application can be monitored in real time to detect whether a memory request instruction is generated on the operating system platform associated with the application. If so, this indicates that the current application needs to request memory. Based on the memory request instruction, the memory space status in the operating system platform can be monitored to determine whether any of the included memory spaces are idle. If any memory space is idle and the attribute value of the idle memory space is below an attribute threshold, the duration required for the operating system platform to perform a memory reclamation operation needs to be determined. The delay time required for the application program to request memory from the operating system platform based on the memory request instruction can be determined based on the delay time.The embodiments of the present disclosure can design a method specifically for determining a delay metric, namely, the delay duration, when an application requests memory. This method accurately measures the delay issue when an application requests memory, thereby effectively avoiding jitter caused by memory allocation delays. This method effectively monitors the delay duration when an application requests memory, resolving the technical issue of being unable to effectively monitor the delay duration when an application requests memory. The above-mentioned method of this embodiment is further described below. In this embodiment, FIG7 is a flowchart of a method for allocating page frames in the kernel of an operating system platform according to an embodiment of the present disclosure. As shown in FIG7 , the method may include the following steps: Step S701: Traverse memory areas in the operating system platform to obtain idle memory areas. In the technical solution provided in step S701 of the present disclosure, memory areas in the operating system platform can be traversed to determine idle memory areas. Optionally, during the execution of an application, if there is a need to request memory, corresponding operations can be performed to generate a memory request instruction. The application can also be controlled to send the memory request instruction to the corresponding operating system platform. Optionally, upon detecting that the operating system platform has received a memory request instruction from an application, the operating system platform may check a memory list contained in the operating system platform to determine the status of the memory areas contained in the memory list, that is, to determine whether any memory areas are in an idle state. Optionally, all memory zones in the kernel of the operating system platform may be traversed to determine the status of each memory zone during the traversal process. Memory zones in an idle state may be determined as zone-free. Step S702 determines whether the number of free page frames is less than the memory watermark. In the technical solution provided in step S702 of the present disclosure, it is determined whether the number of free page frames in the idle memory space is less than the memory watermark. If so, step S703 may be executed; otherwise, step S713 may be executed. Optionally, the memory low level watermark = the low-range memory watermark value + the reserved memory. That is, the memory watermark is the sum of the low-range watermark and the reserved memory. Step S703 initiates memory reclamation. In the technical solution provided in step S703 of the present disclosure, since the number of free page frames is less than the memory watermark, it can be indicated that the operating system platform is currently running low on memory. A memory reclamation operation can be initiated to reclaim more memory for the corresponding application. Step S704 determines whether the number of free page frames is greater than the memory watermark.In the technical solution provided in step S704 of the present disclosure, after initiating the memory reclamation process, it is possible to monitor whether the number of free page frames corresponding to the memory in the idle state after memory reclamation is greater than the memory watermark. If so, step S713 is executed; otherwise, step S705 is executed. Step S705 determines whether the memory area has been completely traversed. In the technical solution provided in step S705 of the present disclosure, it is possible to detect whether the memory area in the operating system platform has been completely traversed. If so, step S706 is executed; otherwise, the process returns to continue traversing the remaining memory area, i.e., step S710 is executed. Step S706 performs a memory consolidation operation. In the technical solution provided in step S706 of the present disclosure, during the memory consolidation phase, fragmented, discontinuous small memory pages can be migrated and merged into larger, continuous memory pages. This phase is relatively time-consuming, and the entry and exit tracepoints of memory compression can be tracked to determine the corresponding latency consumption. Optionally, if the operating system performs a memory compaction operation during memory reclamation, it can detect the conditions before and after the memory compaction operation is performed during this phase. The start of the memory compaction operation can be determined as the entry trace point. That is, the entry trace point is tracepoint / trace_mm_compaction_begin, the exit active point can be tracepoint / trace_mm_compaction_end, and the first time corresponding to the entry trace point can be T5, while the second time corresponding to the exit trace point can be T6. Step S707: Whether the memory page is acquired. In the technical solution provided in step S707 of the present disclosure, it is possible to monitor whether the memory page is acquired. If so, the process can be terminated; otherwise, step S708 can be executed. Step S708: Direct memory reclamation operation. In the technical solution provided in step S708 of the present disclosure, if the control operating system platform needs to perform the direct memory reclamation phase of the memory reclamation operation, the memory reclamation time cost and reclamation intensity of this direct memory reclamation phase are higher than those of the asynchronous memory reclamation phase and the memory consolidation phase. Therefore, the latency consumed by the direct memory reclamation phase is also higher than those of the asynchronous memory reclamation phase and the memory consolidation phase. The exit and entry trace points during direct memory reclamation in this phase can be determined and tracked. Based on the times of these two trace points, the duration of the entire direct memory reclamation phase can be determined. Step S709: Whether the memory page is retrieved.In the technical solution provided in step S709 of the present disclosure, it is possible to monitor whether a memory page is obtained. If so, the process can be terminated; otherwise, step S710 can be executed. Step S710: Memory is released. In the technical solution provided in step S710 of the present disclosure, Out of Memory (OOM) is encountered, and memory in the operating system platform needs to be released. Step S711: Whether there are no killable processes is determined. In the technical solution provided in step S711 of the present disclosure, it is possible to detect whether there are no killable processes in the application. If so, step S712 can be executed; otherwise, step S713 can be executed. Step S712: A kernel error notification message is sent. In the technical solution provided in step S712 of the present disclosure, this indicates a kernel error in the operating system platform. A corresponding notification message can be issued to indicate the kernel error and facilitate troubleshooting and resolution of the kernel error in the operating system platform by relevant personnel. Step S713: Memory page is obtained. In the technical solution provided in step S713 of the present disclosure, memory pages can be obtained. Specifically, corresponding memory pages can be obtained based on the memory size requirements of the corresponding application. In this embodiment, FIG8 is a schematic diagram of a method for measuring heap memory latency for kernel applications on an operating system platform according to an embodiment of the present disclosure. As shown in FIG8 , the method may include the following steps: Step S801: Monitoring whether an idle memory area is below a memory watermark. In the technical solution provided in step S801 of the present disclosure, monitoring whether an idle memory area is below a memory watermark can be performed. Specifically, the number of free pages in the normal zone memory area and the memory low watermark can be monitored. When the number of free pages is below the memory low watermark, EBPF can be used to enable tracing of memory reclamation-related functions. Specifically, the progress of the memory reclamation operation can be determined, and step S703 can be executed. Furthermore, during the application's memory request process, the major page fault count of a specified process can be monitored. Step S802: Enabling EBPF to trace memory reclamation-related functions. In the technical solution provided in step S802 of the present disclosure, after detecting that the number of free pages in the memory interval is lower than the memory 100 level, the memory reclamation operation process can be initiated by controlling the EBPF to track memory reclamation-related functions. That is, the asynchronous memory reclamation phase, the memory consolidation phase, and the direct memory reclamation phase can be entered.During this process, EBPF can be used to enable tracing of corresponding memory reclamation-related functions to calculate the duration of memory reclamation operations. Optionally, as shown in Figure 8 , if the control operating system platform needs to perform an asynchronous memory reclamation phase within the memory reclamation operation, this phase can be divided into two scenarios, IRU reclamation and slab reclamation, taking into account blocking points. Tracing of each of these scenarios is required to obtain the final first and second moments. Optionally, as shown in Figure 8 , for IRU reclamation, the kernel debugging tool (kprobe) can be used to trace the phase before and after execution, tracking the entry and exit trace points of the memory reclamation phase. Specifically, the entry trace point is kprobe / io-schedule, and the exit trace point is retkprobe / io-schedule. The first moment corresponding to the entry trace point is T1, and the second moment corresponding to the exit trace point is T2. Optionally, as shown in FIG8 , for slab reclamation, the conditions before and after the reclamation phase can be monitored, ultimately reaching the entry and exit trace points of the slab reclamation phase. Specifically, the entry trace point is tracepoint / trace_mm_shr ink-slab-start, and the first time corresponding to the entry trace point can be T3. The exit trace point can be tracepoint / trace_mm_shr ink_slab.end, and the second time corresponding to the exit trace point can be T4. Alternatively, as shown in FIG8 , if the operating system is performing an internal direct reclamation phase in a memory reclamation operation, the conditions before and after the internal direct reclamation phase can be monitored, and the start of the direct memory reclamation operation can be determined as the entry trace point. Specifically, the entry trace point can be set to tracepoint / trace_mm-vmscan-direct-reclam_begin, and the first time corresponding to the entry trace point can be set to T7. The second time corresponding to the exit trace point may be determined as T8, and the exit trace point may be set as tracepoint / trace-mm_vmscan_direct-reclaim-end. oOptionally, two methods can be designed to determine the latency. The first method tracks the calling process of the memory reclamation function. By determining the first and second moments corresponding to each stage of the calling process, the duration of each stage can be determined, and the final latency can be accumulated. However, if an exception occurs during the execution of the above method, for example, if the calculation of the duration of the memory reclamation operation fails, the second method can be used to calculate the latency. Specifically, the entry and exit points of the memory allocation function in the kernel of the operating system platform can be directly traced to obtain the memory allocation latency. However, while the second method is simple to operate and easy to implement, memory allocation is a hot path in the system, and the tracing point itself has an overhead of a few tenths of a microsecond or even several microseconds, which can reduce the performance of normal memory allocation. Therefore, the second method can be set as a backup solution. In the event of an exception in the first method, the second method can be urgently called to replace it to ensure efficiency in the memory allocation process. Optionally, the IR U recovery call stack information and the s lab recovery call stack information are obtained. Based on the above two call stack information, the part of the call stack containing direct memory recovery data can be filtered out, and the asynchronous memory recovery delay after filtering is determined. Step S803: Data cleaning of the asynchronous memory recovery phase. In the technical solution provided in the above step S803 of the present disclosure, a data cleaning operation can be performed on the duration obtained in the asynchronous memory recovery phase to filter out overlapping durations from the multiple durations obtained. That is, for the duration in the asynchronous memory recovery phase, it can be determined whether the determined duration has an overlapping duration with that in the direct memory recovery phase. If so, the overlapping duration can be removed from the duration in the asynchronous memory recovery phase. Based on the two call stack information, the portion of the call stack containing direct memory reclamation data can be filtered out, and the filtered asynchronous memory reclamation delay can be determined. For example, when obtaining the data call stack captured during the asynchronous memory reclamation phase, the portion of data related to the direct memory reclamation function contained in the call stack can be filtered out, thereby obtaining the filtered delay duration, namely, T4 - T3 + T2 - TL. It should be noted that the above data cleaning process and method are merely illustrative and are not specifically limited herein. Any process and method that can eliminate the duration obtained during the asynchronous memory reclamation phase that overlaps with the duration during the direct memory reclamation phase is within the scope of protection of the embodiments of the present disclosure. Optionally, the duration of the asynchronous memory reclamation phase is (T4-T3+T2-T1), the duration of the memory regularization phase is (T6-T5), and the duration of the direct memory reclamation phase is (T8-T7). The durations of the three phases of the above memory reclamation operation are accumulated, that is, all memory reclamation delays are accumulated to obtain T8-T7+T6-T5+(T4-T3+T2-T1). Step S804: Determine the memory reclamation delay. In the technical solution provided in step S804 of the present disclosure, the memory reclamation delay, that is, the delay time of the memory reclamation delay, can be determined. Step S805: Monitor the designated process and count the number of processes with primary page fault exceptions. In the technical solution provided in step S805 of the present disclosure, the count of primary page fault exception processes by a specified process can be monitored. Specifically, in determining the delay duration based on the accumulated duration, the abnormal duration of the application in the primary page fault exception state can be determined from the accumulated duration. The abnormal duration can then be filtered out from the accumulated duration to obtain the final delay duration. In step S806, delay data for the specified process is filtered. In the technical solution provided in step S806 of the present disclosure, the number of delays for the specified process can be determined based on the process context. In step S807, the process memory request delay is determined. In the technical solution provided in step S807 of the present disclosure, the final process memory request delay can be obtained based on the aforementioned delay number and the memory reclaim delay. For example, data for processes experiencing primary page fault exceptions can be filtered out, and the application's process memory request delay is calculated as T8 - T7 + T6 - T5 + ( T4 - T3 + T2 - T1 ) oOptionally, the process memory request delay can be presented visually in the user interface. Specifically, the obtained delay duration can be transferred to the user interface for display through a visual design. For example, the delay duration can be processed in various graphical formats and displayed on the user interface at a specific coordinate, such as a line graph. For example, FIG9 is a schematic diagram of a visual display of delay duration according to an embodiment of the present disclosure. As shown in FIG9 , if the application is MySQL, the MySQL OS memory request delay can be displayed on the user interface. The process memory request delay data for this application over a period of time can also be plotted in a grid-like horizontal and vertical coordinate graph. The horizontal axis represents the time when the delay occurred, for example, from 2023-09-05 00:00 to 2023-09-09 00:00, and the vertical axis represents the duration of the delay, for example, 0ms, 1ms, 2ms, 3ms, and 4ms. During MySQL's operation, if it needs to request memory from the OS, this information can be recorded and a corresponding line graph can be plotted in the image. For example, at 09:00:00 on September 5, 2023, a memory delay of 2 ms occurred. After recording the memory delay for a period of time, the minimum (Min), average (Mean), and maximum (Max) values ​​of the memory delay within that period can be calculated. For example, during the five days of MySQL operation shown in Figure 9, the minimum memory delay was 0 ms, the average was 0.00628 ms, and the maximum was 2.30 ms. It should be noted that the above-mentioned form and method for displaying the delay duration on the operation interface are merely illustrative and are not specifically limited herein. Any process or method capable of determining the delay duration and visually displaying it on the operation interface is within the scope of protection of the embodiments of the present disclosure. In the embodiments of the present disclosure, the application's operation process can be monitored in real time to detect whether memory request instructions are generated on the operating system platform associated with the application. If no memory request instruction exists, it indicates that the current application does not need to request memory, and monitoring of the application can continue. If a memory request instruction exists, it indicates that the current application needs to request memory. Based on the memory request instruction, the memory space status in the operating system platform can be monitored to determine whether any of the memory spaces are idle. If any memory space is idle, the amount of storage allowed for storage operations in the memory space can be determined. In other words, the difference between the attribute value and the attribute threshold can be determined.If the attribute value is lower than the attribute threshold, it is necessary to determine the duration of the memory reclamation operation performed by the operating system platform. This duration can be used to determine the delay required for the application to request memory from the operating system platform based on the memory request instruction. Considering that related technologies measure application health solely from the perspective of overall machine resources, which can lead to misjudgments and low accuracy, the present embodiments design a delay metric specifically for determining the application's memory request delay, namely, the delay duration, to accurately measure the application's memory request delay, thereby effectively avoiding jitter caused by memory allocation delays. This effectively monitors the application's memory request delay, resolving the technical issue of being unable to effectively monitor the application's memory request delay. Furthermore, the present embodiments provide an application data monitoring device for implementing the application data monitoring method shown in FIG3 . FIG10 is a schematic diagram of an application data monitoring device according to an embodiment of the present disclosure. As shown in FIG10 , the application data monitoring device 1000 may include a first monitoring component 1002, a first control component 1004, a first acquisition component 1006, and a first determination component 1008. The first monitoring component 1002 is configured to monitor idle memory space on the operating system platform in response to memory request instructions generated by the application on the operating system platform during the application's execution. The first control component 1004 is configured to control the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is lower than an attribute threshold. The attribute value represents the amount of storage allowed for storage operations in the idle memory space. The first acquisition component 1006 is configured to obtain the duration consumed by the operating system platform in performing the memory reclamation operation. The first determination component 1008 is configured to determine, based on the duration, the delay in the application requesting the required memory from the operating system platform. Here, the first monitoring component 1002, the first control component 1004, the first acquisition component 1006 and the first determination component 1008 correspond to steps S302 to S308 in the above embodiment. The four components and the corresponding steps implement the same instances and application scenarios, but are not limited to the contents disclosed in the above embodiment.It should be noted that the above-mentioned components may be hardware components or software components stored in a memory (e.g., memory 1504) and processed by one or more processors (e.g., processors 1502a, 1502b, ..., 1502n). The above-mentioned components may also be part of a device and run in the computer terminal 150 provided in the embodiments of the present disclosure. According to embodiments of the present disclosure, a device for monitoring the delay duration of an application requesting memory is also provided for implementing the method for monitoring the delay duration of an application requesting memory shown in FIG. 4 . FIG. 11 is a schematic diagram of a device for monitoring the delay duration of an application requesting memory according to an embodiment of the present disclosure. As shown in FIG. 11 , the device 1100 for monitoring the delay duration of an application requesting memory may include: a second determining component 1102, a second controlling component 1104, a first display component 1106, a third controlling component 1108, and a second display component 1110. The second acquiring component 1102 is configured to determine an application to be monitored in response to a data monitoring instruction issued on an operation interface. The third acquisition component 1104 is configured to respond to program execution instructions issued on the operation interface and control the execution of the application. The first display component 1106 is configured to respond to memory request instructions generated by the application on the operating system platform and display the idle memory space on the operating system platform on the operation interface. The third control component 1108 is configured to control the operating system platform to perform at least one memory reclamation operation if the attribute value of the idle memory space is lower than an attribute threshold, where the attribute value represents the amount of memory allowed for storage operations in the idle memory space. The second display component 1110 is configured to display on the operation interface the delay duration of the application requesting the required memory from the operating system platform, where the delay duration is determined based on the duration consumed by the operating system platform to perform the memory reclamation operation. It should be noted that the second determination component 1102, the second control component 1104, the first display component 1106, the third control component 1108, and the second display component 1110 correspond to steps S402 to S410 in the above-described embodiment. These five components implement the same examples and application scenarios as the corresponding steps, but are not limited to the contents disclosed in the above-described embodiment. It should be noted that the above-described components may be hardware components or software components stored in a memory (e.g., memory 1504) and processed by one or more processors (e.g., processors 1502a, 1502b, ..., 1502n). These components may also be part of a device and run in the computer terminal 150 provided in the embodiments of the present disclosure.According to an embodiment of the present disclosure, a device for monitoring application memory application data is also provided for implementing the method for monitoring application memory application data shown in FIG. 5 . FIG. 12 is a schematic diagram of a device for monitoring application memory application data according to an embodiment of the present disclosure. As shown in FIG. 12 , device 1200 may include: a first calling component 1202, a second monitoring component 1204, a third control component 1206, a second acquisition component 1208, a second determination component 1210, and a second calling component 1212. First calling component 1202 is configured to determine identification information of an application to be monitored by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the application. Second monitoring component 1204 is configured to monitor idle memory space in the operating system platform based on the identification information and in response to memory application instructions generated by the application on the operating system platform during the application's execution. Third control component 1206 is configured to control the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is below an attribute threshold, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space. The second acquisition component 1208 is configured to obtain the duration of memory reclaiming operations performed by the operating system platform. The second determination component 1210 is configured to determine, based on the duration, the duration of the delay in the application requesting the required memory from the operating system platform. The second calling component 1212 is configured to output the delay duration by calling a second interface, wherein the second interface includes a second parameter whose parameter value is the delay duration. It should be noted that the first calling component 1202, the second monitoring component 1204, the third control component 1206, the second acquisition component 1208, the second determination component 1210, and the second calling component 1212 correspond to steps S502 to S512 in the above-described embodiment. The examples and application scenarios implemented by these six components and corresponding steps are the same, but are not limited to the contents disclosed in the above-described embodiment. It should be noted that the aforementioned components may be hardware components or software components stored in a memory (e.g., memory 1504) and processed by one or more processors (e.g., processors 1502a, 1502b, ..., 1502n). These components may also be part of a device that can be run on the computer terminal 150 provided in the embodiments of the present disclosure. In the data monitoring device for this application, the running process of the application can be monitored in real time to detect whether memory request instructions are generated on the operating system platform associated with the application.If no memory request instruction exists, it indicates that the current application does not need to request memory, and monitoring of the application can continue. If a memory request instruction exists, it indicates that the current application needs to request memory. Based on the memory request instruction, the memory space status of the operating system platform can be monitored to determine whether any of the memory spaces are idle. If any memory space is idle, the amount of storage allowed for storage operations in that memory space can be determined, that is, the difference between the attribute value and the attribute threshold can be determined. If the attribute value is lower than the attribute threshold, the duration required for the operating system platform to perform memory reclamation operations needs to be determined. Based on this duration, the application can be used to determine the delay required before requesting memory from the operating system platform based on the memory request instruction. Considering that related technologies measure application health solely from the perspective of overall machine resources, which can lead to misjudgments and low accuracy, embodiments of the present disclosure provide a dedicated latency metric for determining application memory requests, specifically determining the latency duration, to accurately measure the latency of applications requesting memory. This effectively avoids jitter caused by memory allocation delays and achieves the technical effect of effectively monitoring the latency duration of applications requesting memory, resolving the technical issue of being unable to effectively monitor the latency duration of applications requesting memory. Embodiments of the present disclosure provide a computer terminal, which can be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal can be replaced with a terminal device such as a mobile terminal. Optionally, in this embodiment, the computer terminal can be located on at least one of multiple network devices in a computer network. In this embodiment, the computer terminal can execute program code for the following steps in the application data monitoring method: during the application's execution, in response to a memory request instruction generated by the application on the operating system platform, monitor idle memory space on the operating system platform; if an attribute value of the idle memory space is lower than an attribute threshold, control the operating system platform to perform at least one memory reclamation operation, where the attribute value represents the amount of storage allowed for storage operations in the idle memory space; obtain the duration consumed by the operating system platform in performing the memory reclamation operation; and based on the duration, determine the delay duration for the application to request the required memory from the operating system platform. Alternatively, Figure 13 is a block diagram of the structure of a computer terminal according to an embodiment of the present disclosure.As shown in Figure 13 , computer terminal B may include one or more (only one shown) processors 1302, a memory 1304, and a transmission device 1306. The memory may be used to store software programs and modules, such as program instructions / modules corresponding to the application data monitoring method and apparatus described in the embodiments of the present disclosure. The processor executes the software programs and modules stored in the memory to execute various functional applications and data processing, thereby implementing the aforementioned application data monitoring method. The memory may include high-speed random access memory (RAM) or non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, which may be connected to computer terminal B via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. The processor may access information and applications stored in the memory via the transmission device to perform the following steps: if the attribute value of the idle memory space is lower than the attribute threshold, control the operating system platform to call a memory reclamation function to perform a memory reclamation operation. Optionally, the processor may further execute program code for the following steps: tracing the calling process of the memory reclamation function to obtain a first tracing result; and determining, based on the first tracing result, the duration consumed by the operating system platform for executing the memory reclamation operation. Optionally, the processor may further execute program code for the following steps: obtaining the process running state of the application; if the running state is a process blocking state, tracing the first moment when the memory reclamation operation begins and the second moment when the memory reclamation operation ends during the calling process of the memory reclamation function, wherein the first tracing result includes the first moment when the memory reclamation operation begins and the second moment when the memory reclamation operation ends. Optionally, the processor may further execute program code for the following steps: obtaining the interval between the second moment and the first moment; and determining the interval as the duration consumed by the operating system platform for executing the memory reclamation operation. Optionally, the processor may further execute program code for the following steps: obtaining overlapping durations from multiple durations corresponding to multiple memory reclamation operations; filtering out overlapping durations from the multiple durations; and determining the delay duration based on the filtered multiple durations. Optionally, the processor may further execute program code of the following steps: accumulating the multiple filtered durations to obtain an accumulated duration; and determining a delay duration based on the accumulated duration.Optionally, the processor may further execute program code for the following steps: determining, from the accumulated duration, the abnormal duration that the application was in a primary page fault exception state; filtering out the abnormal duration from the accumulated duration to obtain the delay duration. Optionally, the processor may further execute program code for the following steps: determining the storage region where the memory space is located on the operating system platform; determining an attribute threshold that matches the storage region, where the attribute threshold represents the minimum storage capacity allowed for storage operations in the storage region. Optionally, the processor may further execute program code for the following steps: calling a memory allocation function to request memory required by the application from the operating system platform; tracing the calling process of the memory allocation function to obtain a second tracing result; and in response to a failure to obtain the duration consumed by the operating system platform in executing the memory reclaim operation, determining the delay duration based on the second tracing result. Optionally, the processor may further execute program code for the following steps: displaying the delay duration on an operation interface; and / or outputting a prompt message corresponding to the delay duration. The processor can call information and applications stored in the memory through the transmission device to perform the following steps: responding to a data monitoring instruction on the operation interface, determining an application to be monitored; responding to a program execution instruction on the operation interface, controlling the execution of the application; responding to a memory request instruction generated by the application on the operating system platform, displaying on the operation interface the memory space in an idle state on the operating system platform; if an attribute value of the memory space in an idle state is lower than an attribute threshold, controlling the operating system platform to perform at least one memory reclamation operation, wherein the attribute value is used to represent the storage capacity of the memory space in an idle state that is allowed to perform storage operations; and displaying on the operation interface the delay duration of the application requesting the required memory from the operating system platform, wherein the delay duration is determined based on the duration consumed by the operating system platform to execute the memory reclamation operation.The processor can access information and applications stored in the memory through a transmission device to perform the following steps: determining identification information of the application to be monitored by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the identification information; monitoring idle memory space on the operating system platform in response to memory request instructions generated by the application on the operating system platform based on the identification information during the application's execution; controlling the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is lower than an attribute threshold, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space; obtaining the duration consumed by the operating system platform to perform the memory reclamation operation; and determining, based on the duration, the delay duration of the application requesting the required memory from the operating system platform; and outputting the delay duration by calling a second interface, wherein the second interface includes a second parameter whose parameter value is the delay duration. According to embodiments of the present disclosure, a method for monitoring application data is provided. In embodiments of the present disclosure, the execution of an application can be monitored in real time to detect whether memory request instructions are generated on the operating system platform associated with the application. If no memory request instruction exists, it indicates that the current application does not need to request memory, and monitoring of the application can continue. If a memory request instruction exists, it indicates that the current application needs to request memory. Based on the memory request instruction, the memory space status of the operating system platform can be monitored to determine whether any of the memory spaces are idle. If any memory space is idle, the storage capacity allowed for storage operations in that memory space can be determined, that is, the difference between the attribute value and the attribute threshold can be determined. If the attribute value is lower than the attribute threshold, the duration required for the operating system platform to perform memory reclamation operations needs to be determined. Based on this duration, the application can be used to determine the delay required before requesting memory from the operating system platform based on the memory request instruction. Considering that related technologies measure application health solely from the perspective of overall machine resources, which can lead to misjudgments and low accuracy, the embodiments of the present disclosure can design a latency metric specifically for determining the latency of applications requesting memory. Specifically, they can determine the latency duration, thereby accurately measuring the latency of applications requesting memory. This effectively avoids jitter caused by memory allocation delays and achieves the technical effect of effectively monitoring the latency of applications requesting memory, thus resolving the technical problem of being unable to effectively monitor the latency of applications requesting memory.Those skilled in the art will appreciate that the structure shown in FIG13 is merely illustrative. Computer terminal A may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. FIG13 does not limit the structure of the computer terminal A. For example, computer terminal A may include more or fewer components (such as a network interface, a display device, etc.) than those shown in FIG13 , or may have a configuration different from that shown in FIG13 . Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the hardware associated with the terminal device. The program may be stored in a computer-readable storage medium, which may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Embodiments of the present disclosure also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium may be used to store the program code executed by the application data monitoring method provided in the first embodiment. Optionally, in this embodiment, the computer-readable storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: during the execution of an application, in response to a memory request instruction generated by the application on the operating system platform, monitoring idle memory space in the operating system platform; if an attribute value of the idle memory space is lower than an attribute threshold, controlling the operating system platform to execute at least one memory reclamation operation, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space; obtaining the duration consumed by the operating system platform to execute the memory reclamation operation; and based on the duration, determining the duration of the delay caused by the application requesting the required memory from the operating system platform. Optionally, the computer-readable storage medium may also store program code for executing the following steps: if the attribute value of the idle memory space is lower than the attribute threshold, controlling the operating system platform to invoke a memory reclamation function to execute a memory reclamation operation.Optionally, the computer-readable storage medium may further execute program code for the following steps: tracing the calling process of the memory reclamation function to obtain a first tracing result; and determining, based on the first tracing result, the duration consumed by the operating system platform for executing the memory reclamation operation. Optionally, the computer-readable storage medium may further execute program code for the following steps: obtaining the process running state of the application; if the running state is a process blocking state, tracing the first time when the memory reclamation operation begins and the second time when the memory reclamation operation ends during the calling process of the memory reclamation function, wherein the first tracing result includes the first time when the memory reclamation operation begins and the second time when the memory reclamation operation ends. Optionally, the computer-readable storage medium may further execute program code for the following steps: obtaining the interval between the second time and the first time; and determining the interval as the duration consumed by the operating system platform for executing the memory reclamation operation. Optionally, the computer-readable storage medium may further execute program code for the following steps: obtaining overlapping durations from multiple durations corresponding to multiple memory reclamation operations; filtering out overlapping durations from the multiple durations; and determining the delay duration based on the filtered multiple durations. Optionally, the computer-readable storage medium may further execute program code for the following steps: accumulating the filtered multiple durations to obtain an accumulated duration; and determining a delay duration based on the accumulated duration. Optionally, the computer-readable storage medium may further execute program code for the following steps: determining, from the accumulated duration, the abnormal duration during which the application was in a primary page fault abnormal state; filtering out the abnormal duration from the accumulated duration to obtain a delay duration. Optionally, the computer-readable storage medium may further execute program code for the following steps: determining the storage region in which the memory space is located on the operating system platform; determining an attribute threshold that matches the storage region, wherein the attribute threshold is used to represent the minimum storage capacity allowed for storage operations in the storage region. Optionally, the computer-readable storage medium may further execute program code for the following steps: calling a memory allocation function to request memory required by the application from the operating system platform; tracing the calling process of the memory allocation function to obtain a second tracing result; and, in response to a failure to obtain the duration consumed by the operating system platform in performing a memory reclaim operation, determining a delay duration based on the second tracing result. Optionally, the computer-readable storage medium may further include program codes for executing the following steps: displaying the delay duration on an operation interface; and / or outputting prompt information corresponding to the delay duration.As an optional example, a computer-readable storage medium is configured to store program code for executing the following steps: determining an application to be monitored in response to a data monitoring instruction applied on an operation interface; controlling the application to run in response to a program execution instruction applied on the operation interface; displaying, on the operation interface, idle memory space in the operating system platform in response to a memory request instruction generated by the application on the operating system platform; controlling the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is lower than an attribute threshold, wherein the attribute value is used to represent the amount of storage allowed for storage operations in the idle memory space; and displaying, on the operation interface, a delay duration for the application to request required memory from the operating system platform, wherein the delay duration is determined based on the duration consumed by the operating system platform to perform the memory reclamation operation. As an optional example, a computer-readable storage medium is configured to store program code for performing the following steps: determining identification information of an application to be monitored by calling a first interface, wherein the first interface includes a first parameter whose parameter value is the identification information; monitoring idle memory space in the operating system platform in response to a memory request instruction generated by the application on the operating system platform based on the identification information during the application's execution; controlling the operating system platform to perform at least one memory reclamation operation if an attribute value of the idle memory space is lower than an attribute threshold, wherein the attribute value represents the amount of storage allowed for storage operations in the idle memory space; obtaining the duration consumed by the operating system platform in performing the memory reclamation operation; determining, based on the duration, a delay duration for the application to request the required memory from the operating system platform; and outputting the delay duration by calling a second interface, wherein the second interface includes a second parameter whose parameter value is the delay duration. Embodiments of the present disclosure may provide an electronic device that may include a memory and a processor. Figure 14 is a block diagram of an electronic device implementing a method for monitoring application data according to an embodiment of the present disclosure. The term "electronic device" is intended to refer to various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The term "electronic device" may also refer to various forms of mobile devices, such as personal digital assistants (PDAs), cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are provided for example only and are not intended to limit implementations of the present disclosure as described and / or claimed herein.As shown in Figure 14, device 1400 includes a computing component 1401, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 1402 or a computer program loaded from a storage component 1408 into a random access memory (RAM) 1403. RAM 1403 may also store various programs and data required for the operation of device 1400. Computing component 1401, ROM 1402, and RAM 1403 are interconnected via a bus 1404. An input / output (I / O) interface 1405 is also connected to bus 1404. Multiple components in device 1400 are connected to I / O interface 1405, including: input component 1406, such as a keyboard and mouse; output component 1404, such as various types of displays and speakers; storage component 1408, such as a magnetic disk and optical disk; and communication component 1409, such as a network card, modem, or wireless communication transceiver. Communication component 1409 allows device 1400 to exchange information / data with other devices via computer networks such as the Internet and / or various telecommunication networks. Computing component 1401 can be various general-purpose and / or specialized processing components with processing and computing capabilities. Some examples of computing component 1401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing components that run machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. Computing component 1401 performs the various methods and processes described above, such as the application data monitoring method. For example, in some embodiments, the application data monitoring method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage component 1408. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1400 via ROM 1402 and / or communication component 1409. When the computer program is loaded into the RAM 1403 and executed by the computing component 1401 , one or more steps of the data monitoring method of the application program described above may be performed.Alternatively, in other embodiments, computing component 1401 may be configured to execute the application data monitoring method in any other appropriate manner (e.g., via firmware). The method embodiments provided in the above embodiments of the present disclosure may be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 15 is a hardware block diagram of a computer terminal (or mobile device) for implementing the application data monitoring method according to an embodiment of the present disclosure. As shown in Figure 15 , computer terminal 150 (or mobile device) may include one or more processors 1502 (illustrated as 1502a, 1502b, ..., 1502n) (processor 1502 may include, but is not limited to, a microprocessor (MCU) or a field programmable gate array (FPGA)), a memory 1504 for storing data, and a transmission device 1506 for communication functions. In addition, the electronic device may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in FIG15 is merely illustrative and does not limit the structure of the electronic device. For example, the computer terminal 150 may include more or fewer components than shown in FIG15 , or have a configuration different from that shown in FIG15 . The hardware structure block diagram shown in FIG15 can serve not only as an exemplary block diagram of the computer terminal 150 (or mobile device) described above, but also as an exemplary block diagram of the server described above. In an optional embodiment, FIG2 shows a block diagram of an embodiment using the computer terminal 150 (or mobile device) shown in FIG15 as a computing node in the computing environment 201.Various implementations of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard parts (ASSPs), system-on-a-chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpreted on a programmable system including at least one programmable processor, which can be a special-purpose or general-purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device. The program code for implementing the methods of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server. Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-chip systems (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof.These various embodiments may include implementation in one or more computer programs that are executable and / or interpreted on a programmable system comprising at least one programmable processor, which may be a special-purpose or general-purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, at least one input device, and at least one output device. The program code used to implement the methods of the present disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that, when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server. In the context of the present disclosure, a machine-readable medium may be a tangible medium that can contain or store a program for use by, or in conjunction with, an instruction execution system, device, or apparatus. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatuses, or any suitable combination thereof. More specific examples of machine-readable storage media include electrical connections based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. To provide interaction with a user, the systems and techniques described herein may be implemented on a computer having: a display device (e.g., a cathode ray tube (CRT) or a liquid crystal display (LCD)) for displaying information to the user, a monitor; and a keyboard and pointing device (e.g., a mouse or a trackball) through which the user can provide input to the computer.Other types of devices may also be used to provide user interaction; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and user input may be received in any form (including acoustic input, voice input, or tactile input). The systems and techniques described herein may be implemented in a computing system including backend components (e.g., as a data server), or a computing system including middleware components (e.g., an application server), or a computing system including frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or any combination of such backend, middleware, or frontend components. The components of the system may be interconnected via any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet. A computer system may include a client and a server. The client and server are generally remote from each other and typically interact via a communication network. The client-server relationship is established by computer programs running on corresponding computers and establishing a client-server relationship. The server can be a cloud server, a server in a distributed system, or a server integrated with a blockchain. It should be noted that the serial numbers of the embodiments of the present disclosure are for illustrative purposes only and do not represent the superiority or inferiority of the embodiments. In the above embodiments of the present disclosure, the descriptions of each embodiment are given with emphasis. For portions not detailed in a particular embodiment, reference should be made to the relevant descriptions of other embodiments. It should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of components is merely a logical functional division. In actual implementation, other divisions may be employed, such as combining or integrating multiple components or components into another system, or omitting or disabling certain features. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through interfaces, or indirect coupling or communication connection between components or modules, which may be electrical or otherwise. Components described as separate parts may or may not be physically separate, and components displayed as components may or may not be physical components, ie, may be located in one place or distributed across multiple network components.Some or all of the components can be selected based on actual needs to achieve the objectives of the present embodiment. Furthermore, the functional components in the various embodiments of the present disclosure can be integrated into a single processing component, each component can exist physically separately, or two or more components can be integrated into a single component. These integrated components can be implemented in either hardware or software functional components. If these integrated components are implemented as software functional components and sold or used as independent products, they can be stored on a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product, stored on a storage medium, includes instructions for enabling a computer device (such as a personal computer, server, or network device) to execute all or part of the steps of the methods of the various embodiments of the present disclosure. The aforementioned storage media include various media capable of storing program code, such as USB flash drives, read-only memories, random access memories, removable hard drives, magnetic disks, or optical disks. The above are merely preferred embodiments of the present disclosure. It should be noted that those skilled in the art could make various improvements and modifications without departing from the principles of the present disclosure, and such improvements and modifications should be considered within the scope of protection of the present disclosure. Industrial Applicability: The solutions provided by the embodiments of the present disclosure can be applied to application data monitoring. The application's running process can be monitored in real time to detect whether memory request instructions are generated on the operating system platform associated with the application. If no memory request instructions are generated, it indicates that the current application does not need to request memory, and monitoring of the application can continue. If so, it indicates that the current application does need to request memory. Based on the memory request instructions, the memory space status of the operating system platform can be monitored to determine whether any of the memory spaces are idle. If any memory space is idle, the amount of storage allowed for storage operations in that memory space can be determined. This is done by comparing the attribute value with the attribute threshold. If the attribute value is lower than the attribute threshold, the duration required for the operating system platform to perform memory reclamation operations needs to be determined. The delay time required for the application program to request memory from the operating system platform based on the memory request instruction can be determined based on the delay time.Considering that related technologies measure application health solely from the perspective of overall machine resources, which can lead to misjudgments and low accuracy, the embodiments of the present disclosure provide a dedicated latency metric for determining the application's memory request. Specifically, the latency duration is determined to accurately measure the application's memory request latency, thereby effectively avoiding jitter caused by memory allocation delays. Furthermore, this technology effectively monitors the application's memory request latency, resolving the previous issue of being unable to effectively monitor the application's memory request latency.

Claims

Claims 1. A method for monitoring data of an application program, comprising: During the operation of the application, in response to a memory application instruction generated by the application on the operating system platform, monitor the memory space in the idle state in the operating system platform; if the attribute value of the memory space in the idle state is lower than the attribute threshold, control the operating system platform to perform at least one memory recovery operation, where the attribute value is used to represent the storage capacity that the memory space in the idle state allows for storage operations; obtain the duration consumed by the operating system platform to perform the memory recovery operation; based on the duration, determine the delay duration of the application's request for the required memory from the operating system platform.

2. The method according to claim 1, wherein If the attribute value of the memory space in the idle state is lower than the attribute threshold, control the operating system platform to perform at least one memory recovery operation, including: if the attribute value of the memory space in the idle state is lower than the attribute threshold, control the operating system platform to call a memory recovery function to perform the memory recovery operation.

3. The method according to claim 2, wherein Obtain the duration consumed by the operating system platform to perform the memory recovery operation, including: trace the call process of the memory recovery function to obtain a first tracing result; based on the first tracing result, determine the duration consumed by the operating system platform to perform the memory recovery operation.

4. The method according to claim 3, wherein, The first tracing result includes a first moment when the memory recovery operation starts to be executed and a second moment when the memory recovery operation ends. Among them, tracing the call process of the memory recovery function to obtain a first tracing result includes: obtain the process running state of the application; if the running state is a process blocked state, during the call process of the memory recovery function, trace the first moment when the memory recovery operation starts to be executed and the second moment when the memory recovery operation ends.

5. The method according to claim 4, wherein Based on the first tracing result, determine the duration consumed by the operating system platform to perform the memory recovery operation, including: obtain the interval duration between the second moment and the first moment; determine the interval duration as the duration consumed by the operating system platform to perform the memory recovery operation.

6. The method according to claim 1, wherein Based on the duration, determine the delay duration of the application's request for the required memory from the operating system platform, including: 42 Obtain the overlapping duration among multiple durations corresponding to multiple memory recovery operations; filter out the overlapping duration from multiple durations; based on the filtered multiple durations, determine the delay duration.

7. The method according to claim 6, wherein, Based on the filtered multiple durations, determine the delay duration, including: accumulate the filtered multiple durations to obtain an accumulated duration; determine the delay duration based on the accumulated duration.

8. The method according to claim 7, wherein, Determining the delay duration based on the accumulated duration includes: determining, in the accumulated duration, the abnormal duration during which the application is in the major page fault exception state; filtering out the abnormal duration from the accumulated duration to obtain the delay duration.

9. The method according to claim 1, wherein The method further includes: determining the storage area where the memory space is located in the operating system platform; determining the attribute threshold matching the storage area, where the attribute threshold is used to represent the minimum storage amount allowed for storage operations in the storage area.

10. The method according to claim 1, wherein, The method further includes: calling a memory application function to apply for the memory required by the application to the operating system platform; tracking the calling process of the memory application function to obtain a second tracking result; in response to failing to obtain the duration consumed by the operating system platform to execute the memory recycling operation, determining the delay duration based on the second tracking result.

11. The method according to any one of claims 1 to 10, wherein The method further includes: displaying the delay duration on the operation interface; and / or outputting a prompt message corresponding to the delay duration.

12. The method according to any one of claims 1 to 10, wherein, The at least one memory recycling operation includes at least one of the following: an asynchronous memory recycling operation; a memory compaction operation; a direct memory recycling operation.

13. A method for monitoring the latency of an application's memory application, comprising: In response to a data monitoring instruction on the operation interface, determine the application to be monitored; In response to a program running instruction on the operation interface, control the application to run; in response to a memory application instruction generated by the application on the operating system platform, display on the operation interface the memory space in the operating system platform that is in the idle state; if the attribute value of the memory space in the idle state is lower than the attribute threshold, control the operating system platform to execute at least one memory recycling operation, where the attribute value is used to represent the storage amount allowed for storage operations of the memory space in the idle state; display on the operation interface the delay duration of the application's delay in applying for the required memory from the operating system platform, where the delay duration is determined based on the duration consumed by the operating system platform to execute the memory recycling operation. 43 ​ 14. A method for monitoring data of an application program, comprising: Determine the identification information of the application to be monitored by calling a first interface. The first interface includes a first parameter, and the parameter value of the first parameter is the identification information. During the running of the application, based on the identification information, in response to a memory application instruction generated by the application on the operating system platform, monitor the memory space in the idle state in the operating system platform. If the attribute value of the memory space in the idle state is lower than an attribute threshold, control the operating system platform to perform at least one memory recovery operation, where the attribute value is used to represent the storage capacity that the memory space in the idle state allows for storage operations. Obtain the duration consumed by the operating system platform to perform the memory recovery operation. Based on the duration, determine the delay duration of the application's request for the required memory from the operating system platform. Output the delay duration by calling a second interface, where the second interface includes a second parameter, and the parameter value of the second parameter is the delay duration.

15. A data monitoring system for an application program, comprising: A terminal device for uploading the identification information of the application to be monitored. A server for, during the running of the application, in response to a memory application instruction generated by the application on the operating system platform, monitoring the memory space in the idle state in the operating system platform. If the attribute value of the memory space in the idle state is lower than an attribute threshold, controlling the operating system platform to perform at least one memory recovery operation, where the attribute value is used to represent the storage capacity that the memory space in the idle state allows for storage operations. Obtaining the duration consumed by the operating system platform to perform the memory recovery operation. Based on the duration, determining the delay duration of the application's request for the required memory from the operating system platform.

16. An electronic device, comprising: A memory storing an executable program. A processor for running the program, where when the program runs, it executes the method according to any one of claims 1 to 14.

17. A computer program product, comprising: A computer program that, when executed by a processor, implements the method according to any one of claims 1 to 14.

18. A computer program product, comprising: A non-volatile computer-readable storage medium, the non-volatile 44 computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the method according to any one of claims 1 to 14.

19. A computer program, wherein When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 14.

Images