延迟分析方法、电子设备及存储介质与流程

本发明实施例涉及计算机领域，特别涉及一种延迟分析方法、电子设备及存储介质。

背景技术：

在生产环境的操作系统性能优化领域，准确和高效地跟踪和探测进程延迟信息是业界数十年来一直努力的方向。其难点在于，通用的进程延迟的探测，很难绕过进程调度的核心即进程上下文切换。在多线程的适当的负载压力下进程上下文切换的频率可以达到几十到上百万次每秒。因此，最大限度地减少探测引入的开销(overhead)，减少对生产环境的影响是这个领域技术更迭的推动力。

然而，发明人发现现有技术中至少存在如下问题：当前的系统延迟探测分析方法均会带来较大的开销。

技术实现要素：

本发明实施方式的目的在于提供一种延迟分析方法、电子设备及存储介质，减小了延迟探测的开销。

为解决上述技术问题，本发明的实施方式提供了一种延迟分析方法，包括以下步骤：在探测到电子设备的延迟事件后，获取延迟信息，延迟信息至少包括阻塞栈的地址信息和唤醒栈的地址信息；将延迟信息存储至转储文件中；基于转储文件中的延迟信息，对电子设备进行延迟分析。

本发明的实施方式还提供了一种电子设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行如上述实施方式提及的延迟分析方法。

本发明的实施方式还提供了一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时实现上述实施方式提及的延迟分析方法。

本发明实施方式相对于现有技术而言，该实施例中，在探测到延迟事件后，将延迟信息存储至转储文件，无需实时的将阻塞栈的地址信息解析为相对应的函数名，使得日志转储的中央处理器(centralprocessingunit，cpu)开销最小化。由于转储过程中不对地址信息进行解析，节省了地址解析的时间，使得转储输出的时间更小。此外，对阻塞栈的地址信息和唤醒栈的地址信息进行记录，从阻塞和唤醒两方面对延迟进行分析，多层次推导找出延迟的根本原因。

另外，基于转储文件中的延迟信息，对电子设备进行延迟分析，包括：根据选取的时间范围，以及延迟信息的记录时间，从转储文件获取选取的时间范围内的延迟信息；解析选取的时间范围内的延迟信息，得到选取的时间范围内的延迟信息对应的函数名，以便基于函数名分析延迟原因。该实施例中，只需要对转储文件中用户选取的时间范围内的延迟信息进行解析，无需解析所有地址信息，最大程度减少不必要的地址信息的解析过程。

另外，将延迟信息存储至转储文件中，包括：将延迟信息存储至进程描述符中；将进程描述符中的延迟信息存储至转储文件中。该实施例中，通过进程描述符存储延迟信息，减少了内存开销。

另外，在将延迟信息存储至进程描述符中之后，延迟分析方法还包括：比较各进程描述符中的延迟信息，将相同的阻塞栈的原始地址信息或唤醒栈的原始地址信息对应的进程描述符进行合并处理。该实施例中，对相同栈进行合并处理，极大程度减少了对延迟信息的条目的需求，达到有效跟踪同时减少内存开销的目的。

另外，将进程描述符中的延迟信息存储至转储文件中，包括：按设定的频率读取进程描述符中的延迟信息至转储文件中。

另外，阻塞栈的地址信息包括内核态的阻塞栈的地址信息和用户态的阻塞栈的地址信息；唤醒栈的地址信息包括内核态的唤醒栈的地址信息和用户态的唤醒栈的地址信息。该实施例中，记录内核态的阻塞栈的信息、用户态的阻塞栈的信息、内核态的唤醒栈的信息和用户态的唤醒栈的信息，使得分析电子设备延时的时候，不仅可以关注内核态，还可以关注用户态，以便通过层层推导找出延迟的根本原因。

另外，在探测到电子设备的延迟事件之前，延迟分析方法还包括：运行内核源码中的延迟探测代码，以探测延迟事件；其中，延迟探测代码以补丁形式存在，并被编译集成到内核镜像中。该实施例中，将代码直接以补丁的形式加入内核源码，编译集成到内核镜像，减小了代码注入对cpu流水线预测以及cpu指令高速缓存的影响，减小了cpu开销，进而减小了延迟探测过程对生产环境cpu的压力。

另外，在运行内核源码中的延迟探测代码，以探测延迟事件之前，延迟分析方法还包括：配置延迟探测条件；延迟探测条件包括探测目标的进程号或线程号。该实施例中，进行有针对性的条件过滤，减少补丁注入的代码命中的可能，最大化减小引入延迟探测带来的cpu的开销。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是本发明的第一实施方式的延迟分析方法的流程示意图；

图2是本发明的第二实施方式的延迟分析方法的流程示意图；

图3是本发明的第三实施方式的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

本发明的第一实施方式涉及一种延迟分析方法，包括以下步骤：在探测到电子设备的延迟事件后，获取延迟信息，延迟信息至少包括阻塞栈的地址信息；将延迟信息存储至转储文件中；基于转储文件中的延迟信息，对电子设备进行延迟分析。该实施例中，在探测到延迟事件后，将延迟信息存储至转储文件，无需实时的将阻塞栈的地址信息解析为相对应的函数名，使得日志转储的中央处理器(centralprocessingunit，cpu)开销最小化。由于转储过程中不对地址信息进行解析，节省了地址解析的时间，使得转储输出的时间更小。

下面对本实施方式的延迟分析方法的实现细节进行举例说明。以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。

本实施方式中的延迟分析方法应用于电子设备。其中，电子设备可以是终端、服务器、云端服务器等。如图1所示，延迟分析方法具体包括以下步骤：

步骤101：在探测到电子设备的延迟事件后，获取延迟信息。

具体地，延迟信息至少包括阻塞栈的地址信息和唤醒栈的地址信息。延迟事件的探测可以是：检测内核上下文是否切换，当上下文切换的时候，确定发生延迟事件。

值得一提的是，对阻塞栈的地址信息和唤醒栈的地址信息进行记录，从阻塞和唤醒两方面对延迟进行分析，多层次推导找出延迟的根本原因。

在一个实施例中，阻塞栈的地址信息包括内核态的阻塞栈的地址信息和用户态的阻塞栈的地址信息；唤醒栈的地址信息包括内核态的唤醒栈的地址信息和用户态的唤醒栈的地址信息。其中，阻塞栈是指从入口函数(顶层函数)到阻塞函数的函数记录，唤醒栈是指从入口函数到唤醒函数的函数记录。

值得一提的是，延迟事件在用户态一般表现为进程或线程的延时，但用户并不知道导致该进程或线程的延时的根本原因，对内核态的阻塞栈进行监控，也只能分析到当前内核态的某一个函数出现了问题，实际该内核态的阻塞可能并不一定就是导致用户态延时的根本原因，例如内核中某一个线程一直处于睡眠状态，实际可能是该线程的唤醒程序出了问题，而同样的内核接口，用户的程序都可以调用，而且同一个程序也可以在代码的不同位置去调用；所以为了精确定位到延时的根本原因，用户栈信息也是很有必要的。所以，在发生延迟事件时，同时记录内核态的阻塞栈的信息、用户态的阻塞栈的信息、内核态的唤醒栈的信息和用户态的唤醒栈的信息，使得分析电子设备延时的时候，不仅可以关注内核态，还可以关注用户态，以便通过层层推导找出延迟的根本原因。

在一个实施例中，在探测到电子设备的延迟事件之前，电子设备运行内核源码中的延迟探测代码，以探测延迟事件；其中，延迟探测代码以补丁形式存在，并被编译集成到内核镜像中。其中，延迟探测代码包括用于指示电子设备进行延迟探测的指令。

值得一提的是，将代码直接以补丁的形式加入内核源码，编译集成到内核镜像，无需借助其他允许动态加载卸载代码的工具来执行该部分代码，使得实行该代码时，无需执行工具自身代码，避免了执行该类工具自身代码对cpu流水线预测以及cpu指令高速缓存的影响，减小了cpu开销，进而减小了延迟探测过程对生产环境cpu的压力。

在一个实施例中，在运行内核源码中的延迟探测代码，以探测延迟事件之前，电子设备配置延迟探测条件；延迟探测条件包括探测目标的进程号或线程号。例如，运维人员利用虚拟的基于内存的文件系统(sysfs系统)导出的可配置的接口，配置探测目标的进程号或线程号，限定偶发延迟目标时长范围或进程阻塞睡眠状态等，使得电子设备仅对特定的进程或线程的时长，或，特定的进程或线程的睡眠状态进行探测。

值得一提的是，电子设备进行有针对性的条件过滤，对特定类型的延迟事件进行探测，使得延迟探测代码探测到的延迟事件更具针对性，数量更少，最大程度地减小了电子设备引入延迟探测所带来的cpu的开销。

可选择的，在配置延迟探测条件的过程中，可以选择预先保存目标进程的虚拟内存映射地址信息。由于进程提前退出，原本记录的阻塞栈的地址信息或唤醒栈的地址信息可能会分配给其它进程，导致解析失败或解析不准确。在记录阻塞栈的地址信息或唤醒栈的地址信息的时候，就记录下相应的虚拟地址信息，可以避免进程提前退出导致后期进程虚拟地址解析失败或不准确的情况。

步骤102：将延迟信息存储至转储文件中。

具体地，为保存延迟信息，需将延迟信息存储至转储文件中。在记录延迟信息时，可以同时记录时间戳，以便后期查询。

步骤103：基于转储文件中的延迟信息，对电子设备进行延迟分析。

具体地，电子设备解析延迟信息，得到对应的函数名，分析电子设备延迟原因。

在一个实施例中，电子设备根据选取的时间范围，以及延迟信息的记录时间，从转储文件获取选取的时间范围内的延迟信息；解析选取的时间范围内的延迟信息，得到选取的时间范围内的延迟信息对应的函数名，以便基于所述函数名分析延迟原因。例如，发生延迟的时间为上层应用记录的延迟高点时间戳。电子设备根据上层应用记录的延迟高点时间戳，找到转储文件中与该时间段对应的延迟信息(即转储日志)，调用地址解析脚本，解析延迟信息。当延迟信息包括内核态的阻塞栈的地址信息、用户态的阻塞栈的地址信息、内核态的唤醒栈的地址信息和用户态的唤醒栈的地址信息时，地址解析脚本根据内核符号表和用户进程地址空间范围，将延迟信息解析成运维人员可读的内核函数名或者用户程序函数名符号，完成延迟高点根本原因定位。具体地，针对内核态的地址信息(内核态的阻塞栈的地址信息和内核态的唤醒栈的地址信息)，内核符号表中存储有内核态的栈地址和函数名的对应关系。即内核符号表中，某个范围内的栈地址对应某个特定函数。电子设备可以基于内核符号表解析内核态的地址信息。针对用户态的地址信息(用户态的阻塞栈的地址信息和用户态的唤醒栈的地址信息)，电子设备可以基于用户进程地址空间范围，确定用户态的地址信息对应的函数名。由于记录有内核态的阻塞栈的地址信息、用户态的阻塞栈的地址信息、内核态的唤醒栈的地址信息和用户态的唤醒栈的地址信息，电子设备对各类地址信息进行解析，使得可以层层解析延迟原因，提高延迟原因定位的准确性。

值得一提的是，由于电子设备只需要针对转储文件中与发生延迟的时间所对应的信息进行解析，无需解析所有阻塞栈的地址信息，最大程度减少不必要的阻塞栈的地址信息的解析过程。

需要说明的是，以上仅为举例说明，并不对本发明的技术方案构成限定。

与现有技术相比，本实施方式中提供的延迟分析方法，在探测到延迟事件后，将延迟信息存储至转储文件，无需实时的将阻塞栈的地址信息解析为相对应的函数名，使得日志转储的中央处理器(centralprocessingunit，cpu)开销最小化。由于转储过程中不对地址信息进行解析，节省了地址解析的时间，使得转储输出的时间更小。

本发明的第二实施方式涉及一种延迟分析方法。本实施方式是第一实施方式的进一步细化，举例说明了第一实施方式中的步骤102：将延迟信息存储至转储文件中的过程。

具体的说，如图2所示，在本实施方式中，步骤102包含以下子步骤：

步骤1021：将延迟信息存储至进程描述符中。

具体地，延迟信息存放在进程控制块的进程描述符(task_struct)中，以下简称为延迟记录(latency_record)。由于每个task_struct增加内存使用约4千字节(kilobyte，kb)，对于普通的生产环境服务器而言，其内存开销很小。latency_record以数字地址而不是直接函数名的形式存入，使得延迟记录进行比较操作和合并操作时，cpu可以快速进行字长比较。

在一个实施例中，在将延迟信息存储至进程描述符中之后，电子设备比较各进程描述符中的延迟信息，将相同的阻塞栈的地址信息或唤醒栈的地址信息对应的进程描述符进行合并处理。具体地，阻塞栈和/或唤醒栈的地址信息以64位地址的形式存入task_struct中，对相同的栈合并处理。

在一个实施例中，延迟信息还包括最大延迟时间、总延迟时间和延迟次数；在将相同的阻塞栈的地址信息或唤醒栈的地址信息进行合并处理之后，电子设备更新最大延迟时间、总延迟时间和延迟次数。具体地，同样的阻塞栈或唤醒栈可能会出现多次，每次阻塞都有自己的时间长度，电子设备可以将同样的阻塞栈或唤醒栈的信息记录在一个进程描述符中。记录了相同的阻塞栈或唤醒栈的延迟信息的进程描述符中，延迟次数为该阻塞栈或唤醒栈出现的累计次数，总延迟时间为未合并前各进程描述符中的总延迟时间的总和，最大延迟时间为各进程描述符记录的最大延迟时间中的最大值。

值得一提的是，对相同栈进行合并处理，极大程度减少了对latency_record条目的需求，达到有效跟踪延迟的同时，减少内存开销的目的。

步骤1022：将进程描述符中的延迟信息存储至转储文件中。

例如，进程描述符中的延迟信息以地址格式通过每个进程伪文件系统(proc)接口的序列文件(seq_file文件)导出放入内存文件系统中，地址不作函数符号信息转换，让日志转储的cpu开销最小化，同时避免引入io阻塞保证转储输出的时间窗口最小。seq_file文件访问后自动清空，配合转储脚本，及时转储，可以避免转储过程中出现跟踪暂停。

在一个实施例中，按设定的频率读取进程描述符中的延迟信息至转储文件中。

可选择的，该频率可以根据延迟分析结果进行调整。由于latency_record最大保留的条目数有限，如果seq_file文件读取的时间间隔比延迟高点时间过大(即转储的频率低)，并且配置的延迟探测条件针对性不够强，如未指定进程身份标识(identitydocument，id)，未限定目标延迟时间，复杂的应用可能在指定的时间间隔内产生多条不能合并的栈记录，延迟高点栈也可能漏记，从而影响分析。此时，可以细化延迟探测条件，进而运行转储脚本，使高点延迟时间和seq_file文件转储的频率匹配。

在一个实施例中，该电子设备使用linux系统。

发明人发现，目前延迟分析方法有日志分析方法和代码注入实时分析方法。使用日志分析方法典型的代表是性能分析工具(linuxperf)。其基于内核追踪点(tracepoint)打点日志，对于进程切换的tracepoint，它产生的日志量极大，每秒达到数十兆，同时日志记录产生的cpu开销也达到50％-100％以上，不适合全天跟踪。日志分析方法的另一个弊端是在进程上下文切换相关的分析日志量巨大，后期的数据处理也非常耗时，几乎无法在生产环境中使用。相对于日志型分析方法，代码注入实时分析方法的优势是在获取足够有价值的信息同时，通过编程过滤，日志量急剧减少，很大程度减小对生产环境的影响，记录到的信息存放在内存，定时或者跟踪结束时输出。比较典型的有计算机操作系统(solaris)的动态跟踪(dynamictracing，dtrace)，而操作系统(linux)早期与dtrace对标的是内核诊断工具systemtap，它依赖于内核的代码跟踪工具kprobe底层技术，通过脚本编程然后编译成krpobe内核模块的形式注入目标函数。由于linux内核部分调度函数不能被kprobe探测，因此systemtap实现调度跟踪的模块不得不采取一些绕过措施。因此，cpu开销非常可观，进程上下文切换测试中发现该方法可能引入原负载数倍的cpu开销，导致在生产环境完全不可用。而更新的基于内核扩展伯克利包过滤器(extendedberkeleypacketfilter，ebpf)框架实现方案的bpf编译器集合(bcc工具集)，跟踪效率有很大的提高，cpu开销小很多，进程上下文切换测试负载的cpu使用增加10％左右，数据输出时cpu增加20％左右。bcc工具集在生产环境中达到了基本可用的状态。但bcc工具集存在几个问题，10％～20％的cpu固定开销在一些对cpu敏感的生产环境中，长时间的跟踪仍然不能接受，如一些偶发的延迟高点的探测生产环境中，额外引入的开销极有可能引入假的高点，带来额外的干扰。另外，bcc工具集跟踪到的信息需要存放在预分配的内存中，所以bcc工具集启动时需要估算栈的规模来指定一个合适的预分配内存大小，过小可能导致跟踪信息丢失，过大浪费内存，这对使用者的专业知识要求较高。因此，bcc工具集的常规使用模式是跟踪一段时间，导出信息转储，按需调大内存配置如此反复，导出信息到重新启动的时间窗口跟踪出现停顿。另外，bcc工具集作为一个比较新的跟踪框架，依赖于较高的linux内核版本(4.8以上)。综合而言，bcc工具集更适合进程常规的阻塞睡眠瓶颈的性能分析，而不适合生产环境中偶发延迟高点的性能分析。

相对于上述方法，本实施方式提供的延迟分析方法中，延迟分析过程兼具日志型分析方法以及代码注入型分析方法的优点的同时，代码以补丁形式注入，减少了cpu开销。将阻塞栈的地址信息和/或唤醒栈的地址信息作为延迟信息，存储至转储文件，无需将阻塞栈的地址信息和/或唤醒栈的地址信息解析为相对应的函数名，让日志转储的cpu开销最小化，同时避免引入io阻塞，保证转储输出的时间窗口最小。使用进程描述符存储延迟信息，按预设频率将进程描述符中的延迟信息转储至转储文件，无需预分配内存的同时，不会造成跟踪到的延迟信息丢失。在实际测试中，基于该延迟分析方法的延迟分析过程的cpu使用率在3％以下。

需要说明的是，以上仅为举例说明，并不对本发明的技术方案构成限定。

与现有技术相比，本实施方式中提供的延迟分析方法，在探测到延迟事件后，将延迟信息存储至转储文件，无需实时的将阻塞栈的地址信息解析为相对应的函数名，使得日志转储的中央处理器(centralprocessingunit，cpu)开销最小化。由于转储过程中不对地址信息进行解析，节省了地址解析的时间，使得转储输出的时间更小。延迟信息以数字地址而不是直接函数名的形式存入进程描述符，方便延迟信息比较合并时，cpu快速进行字长比较。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明的第三实施方式涉及一种电子设备，如图3所示，包括：至少一个处理器301；以及，与至少一个处理器301通信连接的存储器302；其中，存储器302存储有可被至少一个处理器301执行的指令，指令被至少一个处理器301执行，以使至少一个处理器301能够执行如上述实施方式提及的延迟分析方法。

该电子设备包括：一个或多个处理器301以及存储器302，图3中以一个处理器301为例。处理器301、存储器302可以通过总线或者其他方式连接，图3中以通过总线连接为例。存储器302作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施方式中指令就存储于存储器302中。处理器301通过运行存储在存储器302中的非易失性软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述延迟分析方法。

存储器302可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储选项列表等。此外，存储器302可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施方式中，存储器302可选包括相对于处理器301远程设置的存储器，这些远程存储器可以通过网络连接至外接设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

一个或者多个模块存储在存储器302中，当被一个或者多个处理器301执行时，执行上述任意方法实施方式中的延迟分析方法。

上述产品可执行本申请实施方式所提供的方法，具备执行方法相应的功能模块和有益效果，未在本实施方式中详尽描述的技术细节，可参见本申请实施方式所提供的方法。

本发明的第四实施方式涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。