宋宝华：LEP ( Linux 易用剖析器) 是什么,为什么以及怎么办 ( 2 )

LEP(LINUX EASY PROFILING) 是Linuxer之LEP项目组（Barry Song，Mac Xu，陈松等以及陈莉君教授/西邮Linux 3+1实验室）正在致力于打造的一个开源项目，LEP项目组欢迎开源爱好者加入和参与。这是LEP文档《 LEP是什么,为什么,怎么办 》的第二部分。第一部分的链接为：

宋宝华：LEP( Linux 易用剖析器) 是什么,为什么以及怎么办(1)

LEP的下一步工作

6.1 架构改造

6.1.1 LEPV前后台分离

目前的体系架构是由浏览器触发LEPV与LEPD通信然后开始采集数据的，下一步我们要改造为，通过web的后台设置监控目标，我们通过web后台设置一个或者数个被监控的电路板/Linux服务器IP地址，即开始采集，而后浏览器只负责观看监控数据，如下图。

[1509348575675_9282_1509348625335.png]

LEPV web服务器端，读取采集到的数据并分析与保存到数据库。而浏览器端，基于已经存在的数据，进行各种分析。

6.1.2 数据保存和恢复支持

在架构中的另外一个考虑是，增加数据库的支持，将采集到的数据，进行保存和恢复。以方便进行时空比对。

我们可以把某一时段的数据采样出来，通过浏览器打开了分析。这样，可以回顾场景或者对比各次场景。

6.1.3 自定义被监控的数据

目前，一旦LEP开启，进入浏览器就可以获得所有的数据。未来，我们应该提供勾选关注事件的能力，以便于LEP只监控它感兴趣的数据。比如，用户选择了只关注内存，那么别的界面就不要显示了。

6.2 功能增强

6.2.1 高平均负载预警

以不同的颜色，标识系统里面平均负载的高低。比如某段长期时间段里面CPU load average明显过高，我们标识一段红线区域。类似不同颜色的台风或暴雨预警。

点击预警的时间点时，可同步刷新当时的CPU利用率，IDLE，IRQ,SOFTIRQ等曲线。

6.2.2 负载不均衡预警

一旦检测到多核下，负载不均衡，以算法分析后，进行提示。负载的不均衡主要体现为2个方面：

1. 进程+中断+软中断
2. 中断+软中断

在出现中断与软中断负载不均衡的时候，提示进行中断affinity的设置，以及提示采用RPS（Receive Packet Steering）调控SoftIRQ。

6.2.3 内存大户提示与内存泄漏预警

分析高峰期的内存场景，比如在某个场景下，哪些进程在耗内存。对于内存大户，可以给出某个进程的内存使用历史曲线。

我们如果监控到某个进程的内存持续震荡向上，应提示内存泄漏预警。

[1509348625381_2132_1509348674648.png]

可点选某一进程，显示它的pmap，类似：

b7453000     44K r-x-- libnss_files-2.19.so
b745e000      4K r---- libnss_files-2.19.so
b745f000      4K rw--- libnss_files-2.19.so
b7460000     40K r-x-- libnss_nis-2.19.so
b746a000      4K r---- libnss_nis-2.19.so
b746b000      4K rw--- libnss_nis-2.19.so
b746c000     84K r-x-- libnsl-2.19.so
b7481000      4K r---- libnsl-2.19.so
b7482000      4K rw--- libnsl-2.19.so

此处我们能否画一个柱状体：

[1509348736878_9444_1509348786142.png]

同时，我们要增加剖析slab和vmalloc的能力，并提醒用户slab和vmalloc的泄漏。我们也可以显示slabtop的内容：

[1509348773843_3103_1509348823134.jpg]

6.2.4 基于CGroup和用户自定义分群的分析

可视图显示Linux的不同的CGroups，显示每个group的CPU占用，内存占用。也可以对某个group的资源进行调配。

[1509348793546_3956_1509348842796.png]

此外，也支持用户通过浏览器拖曳手段，依据应用场景建立自己的分群，把关注的进程，拖到自定义的分群中。最后显示这些自定义分群的CPU、内存和I/O占用情况。

6.2.5 I/O排队预警和调度策略控制

能够给出I/O排队情况的不同颜色的预警，提示硬盘的I/O访问的剧烈程度与排队等候情况。

增加各个磁盘I/O调度策略的显示和设置。读取此类节点

/sys/block/sda/queue$cat scheduler

通过选择框设置noop deadline cfq

[1509348858150_1811_1509348907515.jpg]

在CFQ的情况下，点击一个进程，可选择设置它的prio和调度策略。

6.2.6 Perf集成

Perf的功能有很多，目前我们需要集成一些紧迫的功能。

可以平滑的绘制系统的CPU,I/O分布图

类似执行perf sched record sleep 10

perf timechart

[1509348915791_7387_1509348965207.jpg]

在进程列表上面，加一个run窗口，这样可以自己手动启动一个进程；后面有一个单选框，决定是否进行cpu cycle和cache miss的perf跟踪。

[1509348944621_9106_1509348993923.png]

[1509348983947_3958_1509349033254.png]

此部分类似perf top里面进一步annotate一个函数的功能：

6.2.7 杂项：查缺补漏和交互控制

可以给出系统里面谁在耗电，历史上CPU、外设处在各种状态的时间比例。

[1509349010136_6522_1509349059427.jpg]

每秒中断、每秒软中断、每秒上下文切换、swapin、swapout等残缺数据的采集和显示。频繁swap的场景提示匿名页交换过于频繁的不同颜色的预警。

Linux运行起来后，有很多的sysctl是通过/proc/来控制，很多sysctl的含义，用户根本不懂。我们可以在浏览器上，直接展开目标的sysctl，然后把一些关键的设置的含义，告诉用户。让用户知道自己的目标是什么情况。

比如：

overcommit_memory = 1, 暗示你的Linux总是假装系统有足够多的内存 [点击阅读文档…]
…

在进程的CPU利用率图上，我们可以点击右键，展开它的线程，甚或进一步控制线程的调度策略、优先级或者NICE值。

凡此种种，可以想到很多，不再一一列举。在LEP的开发过程中，小点逐步完善。

6.3 CI和测试

在git提交后，催生自动编译和测试。测试环节要求可以覆盖到ARM32位、ARM64位、X86 32位和X86 64位的目标机。覆盖到的内核版本包括

• Linux 2.6.38
• Linux 3.18
• Linux 4.13

编写测试案例，以覆盖到LEPD的每个JSONRPC，并自动覆盖到LEPV的RESTful API，保证高强度下，LEPD和LEPV的稳定。

6.4 文档

每个模块在设计和开发过程中，书写详细的文档；

文档在Linuxer、Linux内核之旅、CSDN投放；

书写文档，投放到lwn.net;

上传教学使用视频到youku、Youtube(英文版)；

更新和完善www.linuxep.com网站

LEP人员与分工

7.1总体参与人员

研发与测试由陈莉君教授组和LEP co-founder组共同负责，张国强负责总后勤与联络。

7.2 LEPV架构改为前后台以及监控数据可配置

7.3 数据存储与读取、比对

7.4 基于CGroup和用户自定义分群的分析

7.5 LEP持续集成

一旦有人提交代码，即激活自动编译和测试。

7.6 LEP自动测试与案例

增加必要的测试case，保证LEP在各平台，各内核版本的持续稳定。

7.7 残缺功能添加和预警分析功能

中断、软中断、上下文切换、swapin、swapout、slab、vmalloc、Power等残缺的数据采集，负载预警，负载不均衡，内存泄漏预警，I/O过载预警等。

7.8 perf集成

目前LEPD端依赖于perf工具的安装，我们希望能将perf的核心功能从perf工具移植出来，直接集成到LEPD，这样避免对平台的依赖。

来自微信公众号 Linuxer (ID:linuxdev)