Delay analysis method, electronic device and storage medium

Abstract

The embodiment of the present invention relates to the field of computers, and discloses a delay analysis method, an electronic device, and a storage medium. In the embodiment of the present invention, the delay analysis method includes the following steps: after detecting a delay event of an electronic device, obtaining delay information, the delay information at least including address information of a blocking stack and address information of a wake-up stack; storing the delay information in a dump file; and performing delay analysis on the electronic device based on the delay information in the dump file. This embodiment reduces the CPU overhead of delay detection.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computers, and in particular to a delay analysis method, an electronic device, and a storage medium. Background Art

[0002] In the field of operating system performance optimization in production environments, the industry has been working hard to accurately and efficiently track and detect process delay information for decades. The difficulty lies in the fact that it is difficult to bypass the core of process scheduling, namely process context switching, for general process delay detection. Under appropriate load pressure of multi-threading, the frequency of process context switching can reach tens to millions of times per second. Therefore, minimizing the overhead introduced by detection and reducing the impact on the production environment is the driving force for technological changes in this field.

[0003] However, the inventors have discovered that there are at least the following problems in the prior art: the current system delay detection and analysis methods all bring about relatively large overhead. Summary of the invention

[0004] The purpose of the embodiments of the present invention is to provide a delay analysis method, an electronic device and a storage medium, which reduce the overhead of delay detection.

[0005] To solve the above technical problems, an embodiment of the present invention provides a delay analysis method, comprising the following steps: after detecting a delay event of an electronic device, obtaining delay information, the delay information at least including address information of a blocking stack and address information of a wake-up stack; storing the delay information in a dump file; and performing delay analysis on the electronic device based on the delay information in the dump file.

[0006] An embodiment of the present invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the delay analysis method mentioned in the above embodiment.

[0007] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the delay analysis method mentioned in the above embodiment is implemented.

[0008] Compared with the prior art, the embodiment of the present invention stores the delay information in a dump file after a delay event is detected, and there is no need to parse the address information of the blocking stack into the corresponding function name in real time, thereby minimizing the CPU overhead of the log dump. Since the address information is not parsed during the dump process, the time for address parsing is saved, making the dump output time shorter. In addition, the address information of the blocking stack and the address information of the wake-up stack are recorded, and the delay is analyzed from both the blocking and wake-up aspects, and the root cause of the delay is found through multi-level deduction.

[0009] In addition, based on the delay information in the dump file, the delay analysis of the electronic device includes: obtaining the delay information within the selected time range from the dump file according to the selected time range and the recording time of the delay information; parsing the delay information within the selected time range to obtain the function name corresponding to the delay information within the selected time range, so as to analyze the delay cause based on the function name. In this embodiment, only the delay information within the time range selected by the user in the dump file needs to be parsed, and all address information does not need to be parsed, thereby minimizing the unnecessary address information parsing process.

[0010] In addition, storing the delay information in the dump file includes: storing the delay information in the process descriptor; storing the delay information in the process descriptor in the dump file. In this embodiment, the delay information is stored in the process descriptor, which reduces memory overhead.

[0011] In addition, after storing the delay information in the process descriptor, the delay analysis method further includes: comparing the delay information in each process descriptor, and merging the process descriptors corresponding to the same original address information of the blocking stack or the original address information of the wake-up stack. In this embodiment, merging the same stack greatly reduces the demand for entries of the delay information, achieving the purpose of effective tracking while reducing memory overhead.

[0012] In addition, storing the delay information in the process descriptor into the dump file includes: reading the delay information in the process descriptor into the dump file at a set frequency.

[0013] In addition, the address information of the blocking stack includes the address information of the blocking stack in the kernel state and the address information of the blocking stack in the user state; the address information of the wake-up stack includes the address information of the wake-up stack in the kernel state and the address information of the wake-up stack in the user state. In this embodiment, the information of the blocking stack in the kernel state, the information of the blocking stack in the user state, the information of the wake-up stack in the kernel state and the information of the wake-up stack in the user state are recorded, so that when analyzing the delay of the electronic device, not only the kernel state but also the user state can be paid attention to, so as to find the root cause of the delay through layer-by-layer deduction.

[0014] In addition, before detecting a delay event of the electronic device, the delay analysis method further includes: running a delay detection code in the kernel source code to detect the delay event; wherein the delay detection code exists in the form of a patch and is compiled and integrated into the kernel image. In this embodiment, the code is directly added to the kernel source code in the form of a patch and compiled and integrated into the kernel image, which reduces the impact of code injection on CPU pipeline prediction and CPU instruction cache, reduces CPU overhead, and thus reduces the pressure of the delay detection process on the CPU of the production environment.

[0015] In addition, before running the delay detection code in the kernel source code to detect the delay event, the delay analysis method further includes: configuring the delay detection condition; the delay detection condition includes the process number or thread number of the detection target. In this embodiment, targeted condition filtering is performed to reduce the possibility of code hits injected by the patch, and minimize the CPU overhead caused by the introduction of delay detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0017] Figure 1 is a schematic flow chart of a delay analysis method according to a first embodiment of the present invention;

[0018] Figure 2 is a schematic flow chart of a delay analysis method according to a second embodiment of the present invention;

[0019] Figure 3 It is a schematic structural diagram of an electronic device according to a third embodiment of the present invention. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the following will be described in detail with reference to the accompanying drawings. However, it will be appreciated by those skilled in the art that in the various embodiments of the present invention, many technical details are provided in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented.

[0021] The first embodiment of the present invention relates to a delay analysis method, comprising the following steps: after detecting a delay event of an electronic device, obtaining delay information, the delay information at least including address information of a blocking stack; storing the delay information in a dump file; and performing delay analysis on the electronic device based on the delay information in the dump file. In this embodiment, after detecting a delay event, the delay information is stored in a dump file, and there is no need to parse the address information of the blocking stack into a corresponding function name in real time, thereby minimizing the central processing unit (CPU) overhead of the log dump. Since the address information is not parsed during the dump process, the time for address parsing is saved, making the dump output time shorter.

[0022] The following is an example of the implementation details of the delay analysis method of this embodiment. The following content is only provided for the convenience of understanding and is not necessary for the implementation of this solution.

[0023] The delay analysis method in this embodiment is applied to an electronic device. The electronic device may be a terminal, a server, a cloud server, etc. Figure 1 As shown, the delay analysis method specifically includes the following steps:

[0024] Step 101: After detecting a delay event of an electronic device, obtain delay information.

[0025] Specifically, the delay information includes at least the address information of the blocking stack and the address information of the wake-up stack. The detection of the delay event may be: detecting whether the kernel context is switched, and determining that the delay event occurs when the context is switched.

[0026] It is worth mentioning that the address information of the blocking stack and the address information of the wake-up stack are recorded, the delay is analyzed from both blocking and wake-up aspects, and the root cause of the delay is found out through multi-level deduction.

[0027] In one embodiment, the address information of the blocking stack includes the address information of the blocking stack in kernel state and the address information of the blocking stack in user state; the address information of the wake-up stack includes the address information of the wake-up stack in kernel state and the address information of the wake-up stack in user state. The blocking stack refers to the function record from the entry function (top function) to the blocking function, and the wake-up stack refers to the function record from the entry function to the wake-up function.

[0028] It is worth mentioning that delay events generally manifest as process or thread delays in user mode, but users do not know the root cause of the delay of the process or thread. Monitoring the blocking stack in kernel mode can only analyze that a certain function in the current kernel mode has a problem. In fact, the blocking of the kernel mode may not necessarily be the root cause of the delay in user mode. For example, if a thread in the kernel is always in a sleeping state, it may be that there is a problem with the wake-up program of the thread. The same kernel interface can be called by user programs, and the same program can also be called at different locations in the code; so in order to accurately locate the root cause of the delay, user stack information is also necessary. Therefore, when a delay event occurs, the information of the kernel state blocking stack, the user state blocking stack, the kernel state wake-up stack, and the user state wake-up stack are recorded at the same time, so that when analyzing the delay of electronic equipment, not only the kernel state but also the user state can be paid attention to, so as to find the root cause of the delay through layer-by-layer deduction.

[0029] In one embodiment, before detecting a delay event of the electronic device, the electronic device runs a delay detection code in a kernel source code to detect the delay event; wherein the delay detection code exists in a patch form and is compiled and integrated into the kernel image. wherein the delay detection code includes instructions for instructing the electronic device to perform delay detection.

[0030] It is worth mentioning that the code is directly added to the kernel source code in the form of a patch and compiled and integrated into the kernel image. There is no need to use other tools that allow dynamic loading and unloading of code to execute this part of the code. When the code is implemented, there is no need to execute the tool's own code, avoiding the impact of executing the tool's own code on CPU pipeline prediction and CPU instruction cache, reducing CPU overhead, and thus reducing the pressure of the delay detection process on the CPU of the production environment.

[0031] In one embodiment, before running the delay detection code in the kernel source code to detect the delay event, the electronic device configures the delay detection condition; the delay detection condition includes the process number or thread number of the detection target. For example, the operation and maintenance personnel use the configurable interface exported by the virtual memory-based file system (sysfs system) to configure the process number or thread number of the detection target, limit the occasional delay target duration range or process blocking sleep state, etc., so that the electronic device only detects the duration of a specific process or thread, or the sleep state of a specific process or thread.

[0032] It is worth mentioning that the electronic device performs targeted conditional filtering to detect specific types of delay events, so that the delay events detected by the delay detection code are more targeted and fewer in number, thereby minimizing the CPU overhead caused by the introduction of delay detection by the electronic device.

[0033] Optionally, when configuring the delay detection conditions, you can choose to save the virtual memory mapping address information of the target process in advance. Due to the early exit of the process, the address information of the blocking stack or the address information of the wakeup stack originally recorded may be allocated to other processes, resulting in parsing failure or inaccurate parsing. When recording the address information of the blocking stack or the address information of the wakeup stack, the corresponding virtual address information is recorded, which can avoid the situation where the virtual address parsing of the later process fails or is inaccurate due to the early exit of the process.

[0034] Step 102: Store the delay information in a dump file.

[0035] Specifically, in order to save the delay information, the delay information needs to be stored in a dump file. When recording the delay information, a timestamp can be recorded at the same time for later query.

[0036] Step 103: Perform delay analysis on the electronic device based on the delay information in the dump file.

[0037] Specifically, the electronic device parses the delay information, obtains the corresponding function name, and analyzes the cause of the delay of the electronic device.

[0038] In one embodiment, the electronic device obtains the delay information within the selected time range from the dump file according to the selected time range and the recording time of the delay information; parses the delay information within the selected time range to obtain the function name corresponding to the delay information within the selected time range, so as to analyze the delay cause based on the function name. For example, the time when the delay occurs is the delay high point timestamp recorded by the upper layer application. The electronic device finds the delay information corresponding to the time period in the dump file (i.e., the dump log) according to the delay high point timestamp recorded by the upper layer application, calls the address resolution script, and resolves the delay information. When the delay information includes the address information of the blocking stack in the kernel state, the address information of the blocking stack in the user state, the address information of the wake-up stack in the kernel state, and the address information of the wake-up stack in the user state, the address resolution script parses the delay information into a kernel function name or a user program function name symbol readable by the operation and maintenance personnel according to the kernel symbol table and the user process address space range, and completes the positioning of the root cause of the delay high point. Specifically, for the address information in the kernel state (the address information of the blocking stack in the kernel state and the address information of the wake-up stack in the kernel state), the kernel symbol table stores the corresponding relationship between the stack address and the function name in the kernel state. That is, in the kernel symbol table, a stack address within a certain range corresponds to a specific function. The electronic device can parse the kernel state address information based on the kernel symbol table. For the user state address information (the address information of the user state blocking stack and the address information of the user state wake-up stack), the electronic device can determine the function name corresponding to the user state address information based on the user process address space range. Since the address information of the kernel state blocking stack, the address information of the user state blocking stack, the address information of the kernel state wake-up stack, and the address information of the user state wake-up stack are recorded, the electronic device parses various types of address information, so that the cause of the delay can be analyzed layer by layer, thereby improving the accuracy of locating the cause of the delay.

[0039] It is worth mentioning that since the electronic device only needs to parse the information corresponding to the time when the delay occurred in the dump file, there is no need to parse the address information of all blocking stacks, thereby minimizing the unnecessary parsing process of the address information of the blocking stack.

[0040] It should be noted that the above is only an example and does not limit the technical solution of the present invention.

[0041] Compared with the prior art, the delay analysis method provided in this embodiment stores the delay information in a dump file after detecting a delay event, without the need to parse the address information of the blocking stack into the corresponding function name in real time, thereby minimizing the CPU overhead of the log dump. Since the address information is not parsed during the dump process, the time for address parsing is saved, making the dump output time shorter.

[0042] The second embodiment of the present invention relates to a delay analysis method. This embodiment is a further refinement of the first embodiment, and illustrates the process of step 102 in the first embodiment: storing delay information in a dump file.

[0043] Specifically, Figure 2 As shown, in this embodiment, step 102 includes the following sub-steps:

[0044] Step 1021: Store the delay information in the process descriptor.

[0045] Specifically, latency information is stored in the process descriptor (task_struct) of the process control block, hereinafter referred to as latency record (latency_record). Since each task_struct increases memory usage by about 4 kilobytes (KB), its memory overhead is very small for ordinary production environment servers. The latency_record is stored in the form of a digital address rather than a direct function name, so that the CPU can quickly perform word length comparison when performing comparison and merging operations on latency records.

[0046] In one embodiment, after storing the delay information in the process descriptor, the electronic device compares the delay information in each process descriptor and merges the process descriptors corresponding to the same blocking stack address information or wake-up stack address information. Specifically, the address information of the blocking stack and / or wake-up stack is stored in the task_struct in the form of a 64-bit address, and the same stacks are merged.

[0047] In one embodiment, the delay information also includes the maximum delay time, the total delay time, and the number of delays; after the address information of the same blocking stack or the address information of the wake-up stack is merged, the electronic device updates the maximum delay time, the total delay time, and the number of delays. Specifically, the same blocking stack or wake-up stack may appear multiple times, and each blocking has its own time length. The electronic device can record the information of the same blocking stack or wake-up stack in a process descriptor. In the process descriptor that records the delay information of the same blocking stack or wake-up stack, the number of delays is the cumulative number of times the blocking stack or wake-up stack appears, the total delay time is the sum of the total delay times in each process descriptor before merging, and the maximum delay time is the maximum value of the maximum delay times recorded in each process descriptor.

[0048] It is worth mentioning that merging the same stacks greatly reduces the need for latency_record entries, achieving the goal of effectively tracking latency while reducing memory overhead.

[0049] Step 1022: Store the delay information in the process descriptor into a dump file.

[0050] For example, the delay information in the process descriptor is exported in address format through the sequence file (seq_file file) of each process pseudo file system (proc) interface and placed in the memory file system. The address is not converted into function symbol information, which minimizes the CPU overhead of log dumping and avoids introducing IO blocking to ensure the minimum time window for dump output. The seq_file file is automatically cleared after access, and dumping is carried out in time with the dump script, which can avoid tracking pauses during the dump process.

[0051] In one embodiment, the delay information in the process descriptor is read into a dump file at a set frequency.

[0052] Optionally, the frequency can be adjusted based on the latency analysis results. Since the maximum number of entries retained by latency_record is limited, if the time interval for reading the seq_file file is too large compared to the latency peak time (i.e., the dump frequency is low), and the configured latency detection conditions are not targeted enough, such as not specifying the process identity (Identity document, ID) and not limiting the target latency time, complex applications may generate multiple stack records that cannot be merged within the specified time interval, and latency peak stacks may also be missed, thus affecting the analysis. At this point, the latency detection conditions can be refined, and then the dump script can be run to match the latency peak time with the frequency of seq_file file dumps.

[0053] In one embodiment, the electronic device uses a Linux system.

[0054] The inventor found that the current delay analysis methods include log analysis methods and code injection real-time analysis methods. The typical representative of the log analysis method is the performance analysis tool (Linux perf). It is based on the kernel tracepoint (tracepoint) to dot logs. For the trace point of process switching, the amount of logs it generates is extremely large, reaching tens of megabytes per second, and the CPU overhead generated by log records also reaches more than 50%-100%, which is not suitable for all-day tracking. Another disadvantage of the log analysis method is that the amount of analysis logs related to process context switching is huge, and the later data processing is also very time-consuming, which is almost impossible to use in a production environment. Compared with the log-type analysis method, the advantage of the code injection real-time analysis method is that while obtaining enough valuable information, the amount of logs is sharply reduced through programming filtering, which greatly reduces the impact on the production environment. The recorded information is stored in the memory and output at the end of timing or tracking. A more typical example is the dynamic tracing (Dynamic Tracing, Dtrace) of the computer operating system (Solaris), and the operating system (Linux) early benchmarked against Dtrace is the kernel diagnostic tool system tap, which relies on the kernel code tracing tool kprobe underlying technology, and injects the target function in the form of script programming and then compiled into the krpobe kernel module. Since some scheduling functions in the Linux kernel cannot be detected by kprobe, the module that implements scheduling tracking by system tap has to take some bypass measures. Therefore, the CPU overhead is very considerable. In the process context switch test, it was found that this method may introduce CPU overhead several times the original load, making it completely unusable in the production environment. The updated BPF compiler set (bcc toolset) based on the kernel extended Berkeley Packet Filter (eBPF) framework implementation scheme has greatly improved the tracking efficiency and much less CPU overhead. The CPU usage of the process context switch test load increased by about 10%, and the CPU increased by about 20% during data output. The Bcc toolset has reached a basically usable state in the production environment. However, there are several problems with the bcc toolset. The 10% to 20% CPU fixed overhead is still unacceptable for long-term tracking in some production environments that are sensitive to the CPU. For example, in the production environment where some occasional delay high points are detected, the additional overhead is very likely to introduce false high points, bringing additional interference. In addition, the information tracked by the bcc toolset needs to be stored in pre-allocated memory, so when the bcc toolset is started, it is necessary to estimate the size of the stack to specify an appropriate pre-allocated memory size. Too small a size may result in loss of tracking information, and too large a size wastes memory, which requires a high level of professional knowledge from the user.Therefore, the general usage pattern of the bcc toolset is to trace for a period of time, export information dumps, increase memory configuration as needed, and repeat this process. The information is exported until the restart time window when the trace pauses. In addition, as a relatively new tracing framework, the bcc toolset relies on a higher Linux kernel version (4.8 or above). In general, the bcc toolset is more suitable for performance analysis of regular blocking and sleeping bottlenecks of processes, but not for performance analysis of occasional high latency points in production environments.

[0055] Compared with the above method, in the delay analysis method provided by the present embodiment, the delay analysis process has the advantages of both the log-type analysis method and the code injection-type analysis method, while the code is injected in the form of a patch, which reduces the CPU overhead. The address information of the blocking stack and / or the address information of the wake-up stack is used as delay information and stored in the dump file. There is no need to parse the address information of the blocking stack and / or the address information of the wake-up stack into the corresponding function name, so that the CPU overhead of the log dump is minimized, while avoiding the introduction of IO blocking, ensuring that the time window of the dump output is minimized. The delay information is stored using a process descriptor, and the delay information in the process descriptor is dumped to the dump file at a preset frequency. There is no need to pre-allocate memory, and the tracked delay information will not be lost. In actual tests, the CPU usage rate of the delay analysis process based on the delay analysis method is below 3%.

[0056] It should be noted that the above is only an example and does not limit the technical solution of the present invention.

[0057] Compared with the prior art, the delay analysis method provided in this embodiment stores the delay information in a dump file after detecting a delay event, without the need to parse the address information of the blocking stack into the corresponding function name in real time, thereby minimizing the central processing unit (CPU) overhead of the log dump. Since the address information is not parsed during the dump process, the time for address parsing is saved, making the dump output time shorter. The delay information is stored in the process descriptor in the form of a digital address rather than a direct function name, which facilitates the CPU to quickly compare the word length when comparing and merging the delay information.

[0058] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0059] A third embodiment of the present invention relates to an electronic device, such as Figure 3As shown, it includes: at least one processor 301; and a memory 302 that is communicatively connected to the at least one processor 301; wherein the memory 302 stores instructions that can be executed by the at least one processor 301, and the instructions are executed by the at least one processor 301 so that the at least one processor 301 can execute the delay analysis method mentioned in the above embodiment.

[0060] The electronic device includes: one or more processors 301 and a memory 302, Figure 3 A processor 301 is taken as an example. The processor 301 and the memory 302 may be connected via a bus or other means. Figure 3 The example of a bus connection is taken as an example. The memory 302, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules. For example, the instructions in the implementation of the present application are stored in the memory 302. The processor 301 executes various functional applications and data processing of the device by running the non-volatile software programs, instructions and modules stored in the memory 302, that is, realizing the above-mentioned delay analysis method.

[0061] The memory 302 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store a list of options, etc. In addition, the memory 302 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 302 may optionally include a memory remotely arranged relative to the processor 301, and these remote memories may be connected to an external device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0062] One or more modules are stored in the memory 302, and when executed by one or more processors 301, the delay analysis method in any of the above method implementations is executed.

[0063] The above-mentioned product can execute the method provided in the implementation mode of this application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this implementation mode, please refer to the method provided in the implementation mode of this application.

[0064] A fourth embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0065] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0066] Those skilled in the art will appreciate that the above-mentioned embodiments are specific examples for implementing the present invention, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A delay analysis method, characterized in that: include: After detecting a delay event of a process and / or thread of the electronic device, acquiring delay information, the delay information at least including virtual memory mapping address information corresponding to address information of a blocking stack and address information of a wake-up stack; Storing the delay information in a dump file; Based on the delay information in the dump file, performing process and / or thread delay analysis on the electronic device; The step of storing the delay information in a dump file includes: Storing the delay information in a process descriptor; storing the delay information in the process descriptor into the dump file; After storing the delay information in the process descriptor, the delay analysis method further includes: Comparing the delay information in each of the process descriptors, merging the process descriptors corresponding to the same original address information of the blocking stack or the original address information of the wake-up stack; The delay information also includes the maximum delay time, the total delay time and the number of delays; After merging the process descriptors corresponding to the same original address information of the blocking stack or the original address information of the wake-up stack, the method further includes: Update the maximum delay time, the total delay time and the number of delays; In the process descriptor that records the delay information of the same blocking stack or wake-up stack, the number of delays is the cumulative number of times the corresponding blocking stack or wake-up stack appears, the total delay time is the sum of the total delay times in each of the process descriptors before merging, and the maximum delay time is the maximum value of the maximum delay times recorded in each of the process descriptors.

2. The delay analysis method according to claim 1, characterized in that: The performing delay analysis on the electronic device based on the delay information in the dump file includes: According to the selected time range and the recording time of the delay information, acquiring the delay information within the selected time range from the dump file; Parse the delay information within the selected time range to obtain a function name corresponding to the delay information within the selected time range, so as to analyze the delay cause based on the function name.

3. The delay analysis method according to claim 1, characterized in that: The storing the delay information in the process descriptor into the dump file comprises: The delay information in the process descriptor is read into the dump file at a set frequency.

4. The delay analysis method according to claim 1, characterized in that: The address information of the blocking stack includes the address information of the blocking stack in the kernel state and the address information of the blocking stack in the user state; the address information of the wake-up stack includes the address information of the wake-up stack in the kernel state and the address information of the wake-up stack in the user state.

5. The delay analysis method according to any one of claims 1 to 4, characterized in that: Before detecting a delay event of the electronic device, the delay analysis method further includes: The delay detection code in the kernel source code is run to detect delay events; wherein the delay detection code exists in the form of a patch and is compiled and integrated into the kernel image.

6. The delay analysis method according to claim 5, characterized in that: Before the delay detection code in the running kernel source code is executed to detect the delay event, the delay analysis method further includes: Configure delay detection conditions; the delay detection conditions include the process number or thread number of the detection target.

7. An electronic device, characterized in that: include: at least one processor; as well as, A memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor so as to enable the at least one processor to execute the delay analysis method as described in any one of claims 1 to 6.

8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the delay analysis method according to any one of claims 1 to 6 is implemented.

Images