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

LEP(LINUX EASY PROFILING) 是Linuxer之LEP项目组（Barry Song，Mac Xu，陈松等以及陈莉君老师）正在致力于打造的一个开源项目，这是LEP文档《LEP是什么,为什么,怎么办》的第一部分。本部分目录如下：

1.LEP是什么？ 

  1.1 LEP的架构 

  1.2 LEP的特点 

2.LEP的License

  3.为什么要做LEP？

    3.1 三类Linux开发者与LEP对他们各自的作用

    3.2 第一类Linux开发者调试方法

    3.3 第三类Linux开发者调试方法

4.LEP类似项目以及LEP的优势

  4.1 netdata

  4.2 zabbix

  4.3 munin

4.4 带插件的Eclipse

5.LEP的当前状态

  5.1 代码托管

  5.2 支持平台

  5.3 目前功能

    5.3.1 概况视角

    5.3.2 CPU视角

    5.3.3 内存视角

    5.3.4 I/O视角

    5.3.5 perf视角

  5.4 目前缺陷

LEP项目组欢迎开源爱好者加入和参与。关于项目的最新演讲：

【终南山.内核问道】Linux性能剖析的可视化

点击“二维码”关注 Linuxer LEP是什么？ LEP的全称是Linux Easy Profiling（Linux易用剖析器），核心特点在于Easy（简单），主要功能在乎Profiling（剖析）。LEP的网址是http://www.linuxep.com，网站基于Docker部署，代码仓库位于：https://github.com/linuxep/linuxep LEP的设计目标是：便利Linux的程序员，以最快最直接的方式，定位到系统里面一些bug的源头，以及一些性能瓶颈的原因。 Linux有很多现成的调试和剖析工具，比如top、vmstat、iotop、perf、valgrind、powertop、free、pmap、slabtop等，这些工具通过读取/proc、/sys，分析硬件的PMU（Performance Monitor Unit）数据、监控内存的申请释放以及读写等手段，获知单一进程或者系统的运行状态，以及进行故障分析。LEP除了在功能上是这些工具的超集以外，在可视、交互、深度分析、数据比对、场景贴合等角度对这些工具进行进一步的增强。 1.1 LEP的架构 LEP实际上是一个all-in-one的调试工具，它的软件架构如图1。LEP与Linux现有工具重大不同的地方是：被监控的服务器或者开发板只需要部署LEPD(LEP Daemon)，该程序完全用C语言，只需要完成基本的数据采集功能，因此它能最小化对被监控系统本身的影响。数据的分析和处理，都移动到了WEB服务LEPV（LEP Viewer）和浏览器一端。LEPD采集被监控目标的运行数据，这些数据被WEB服务端LEPV通过JSONRPC请求获得，LEPV以Python对从LEPD获得的原始数据进行有针对性的加工，再发送给浏览器，浏览器用Javascript等形式，把LEPV加工过的数据，以各种丰富的图形进行显示。 这种架构的主要好处是：LEPD和LEPV分离，这样使得LEPD易于部署在资源贫乏的嵌入式电脑板上（当然更加可以运行在服务器上），而LEPV一般则运行在比较强壮的X86 PC上。当然，LEPD和LEPV虽然分离，在实际部署的时候，也可以部署于同一个X86 PC。因此，LEP也可以用于非网络环境下的单机自身监控。 值得一提的是，LEPV目前基于Docker进行部署，这对LEPV的安装和使用提供了很大的帮助，避免了不同环境下、不同用户要安装各种依赖的底层工具的繁琐动作。LEPV可运行于直接支持Docker的Linux平台以及间接支持Docker的MAC OS和Windows平台。 图2演示了LEP的一个典型的数据流程。运行于被监控系统的LEPD读取/proc/loadavg数据，这些数据没有格式，是原始的，类似“2.58 2.25 2.31…”，而LEPV收到这些数据后，将其进行语义加工为last1、last5、last15这种过去1分钟、5分钟、15分钟系统平均负载，浏览器获取这些数据后，绘制为3条生动活泼的动感曲线。 图2 LEP的数据流程 1.2 LEP的特点 LEP在功能角度上，全面集成了Linux的多数常用工具，但是在调试和剖析能力上，更加“给力”，它进行了进一步的高强度增强，这些增强主要表现在6个方面： 1.     LEP是all-in-one的。意味着有了LEP后，用户不用再满世界去寻找和集成众多的工具。由于LEP本身的绝大多数工作并不集成在被监控的目标，被监控的目标仅仅需安装一个最简单的daemon LEPD做后台数据采集，因此，这种all-in-one的集成本身也不会增加被监控者文件系统的footprint。 2.     LEP是可视化的。当我们用top命令去观察CPU利用率、平均负载等的时候，top进行周期性的刷新，它显示的只是此一时刻的数据，因为没有图形，所以它无法显示变化，而LEP则可以以时间为X轴，数据为Y轴，显示系统一段时间的状态变迁，如图3。 图3 LEP可显示变化 3.     LEP是可交互的。由于界面丰富，因此，用户可在浏览器网页上面，对监控本身的频率、数据类型等进行设置，以及进行方便的数据过滤，譬如在Linux的众多进程中，设置只关心某些进程。以图4为例，在进程CPU利用率的监控窗口，我们可以通过简单的输入进程名load，过滤掉我们不关心的进程。 4.     LEP带预警和分析能力。目前的Linux命令，更多的只是显示数据，本身分析和预警能力不足。比如free命令，它显示系统的内存，但是当系统出现内存泄漏时，它彻底缺乏提示和预警能力。与之不同的是，LEP可持续跟踪系统，因此，发现内存泄漏等异常状况后，可给用户预警，并进一步给出更深的提示，比如提示内存泄漏的源头是slab、vmalloc还是用户态应用程序。 5.     LEP具备数据存储能力。LEP可以将采集的历史数据进行保存，并在保存后进行档案调取。程序员经常会修改代码，并进行修改代码前和修改代码后的运行性能比对。历史数据与当前数据的比对，可便利程序员获知代码变更对系统真实的影响。我们姑且称呼上述比对为时间比对，那么，另外一种可能的比对就是空间比对，比如程序员会比对同样的软件，运行于不同的硬件平台时性能差异的不同。LEP的此一能力，可帮助程序员折叠时空。 6.     LEP可深度贴合用户场景。使用LEP工具，除了可以依据Linux CGroup（ ControlGroups ）进行监控外，用户可依据应用场景，进行进程的人工干涉分群，比如，对于多媒体播放场景，把播放相关的service和app归于一个进程群，并观察此一群的运行状态和资源占用。 LEP的license LEP是基于GPL v2发布的，这意味着任何人都可以获得其开源的源代码，并部署使用之，但是对其本身的修复和提高，也必须再次开源。LEP也欢迎与厂商合作，并可能以功能插件的形式，对厂商的部分源代码，使用商业license，从而对这部分代码进行闭源。 为什么要做LEP 3.1 三类Linux开发者与LEP对他们各自的作用 主要的目标还是解决现实的问题，加快问题的调试和定位过程，减轻程序员的痛苦，从而提高生产力。 我们大体认为在Linux上从事开发的程序员，依据其与Linux平台本身的亲密度可分为3类： 1.     Linux专家，类似游泳健将。 2.     熟悉Linux的开发者，类似会游泳的人。 3.     不熟悉Linux平台本身知识的开发者，类似不会游泳或者只会狗爬式游泳的人。 LEP项目坚决反对程序员的鄙视链，提倡以平常心以公平心看待不同的技术领域。游泳健将不能鄙视狗爬式，虽然别人游泳不行，在体育界不好混，但是说不定人家戏演地好，在演艺圈成功了。技术上倡导百万齐放，行行出状元。 根据著名的二八定律，我们认为有20%的程序员，掌握了80%的Linux知识；而有80%的程序员，只掌握了20%的Linux知识。第二、三类Linux用户数量远大于第一类Linux用户。 LEP的主要目的是给第二、三类Linux开发者扔一个救生圈防止他们淹死，同时这个救生圈，也可以给第一类Linux用户节省体力，可以缩短他们的调试周期。所以，它对第二类和第三类，达到了救命或者续命的效果，对第一类，更多的是达到锦上添花的作用。 如图5，一旦系统出现问题，Linux专家级开发者，由于心中有丘壑，他的需求很可能只是，敲一些命令，然后看看命令的结果，寻找调试方向，所以，他更多的需求是“我看看”；熟悉Linux的用户，通过冰冷的命令输出，可能很难窥探到系统的运行秘密，但是如果能以图形显示，他大概能够知道个七七八八，所以他的诉求，更多的是“帮帮我”；而对于第三类Linux开发者而言，你可能就必须直接给他指出问题出在哪里，他的诉求是“救救我”。 图5 三类Linux用户以及他们的诉求 下面我们以一个内存泄漏为例，看看第一类工程师和第三类工程师的区别。故事的背景是，某使用Linux做产品的公司A，从开发板的制造商买了一批开发板，而后在其提供的Linux之上，增加了一个Qt的应用程序。但是，不幸的是，此开发板的某内核驱动有极其缓慢的slab区域（以kmalloc进行申请）内存泄漏。下面第一类工程师和第三类工程师同时开始调试这个bug。 3.2 第一类Linux开发者调试方法 第一类开发者，理解进程内存消耗的VSS、RSS、PSS、USS概念，并理解内核空间的slab、vmalloc以及用户空间的malloc都可能是堆内存的泄漏源头。他的调试过程如下： 1.     以free命令跟踪系统，发现系统free内存随着时间迁移而持续减小，他确立内存泄漏存在； 2.     怀疑自己写的Qt应用程序有内存泄漏，于是以类似smem工具，持续跟踪自己写的Qt应用的USS，经过一段时间的观察，它发现Qt应用本身耗费的内存没有变大，排除自身问题； 3.     持续观察/proc/meminfo，跟踪slab和vmalloc区域的变化，发现slab区域随着时间迁移增大，确立内核空间kmalloc类似行为有泄漏； 4.     查看/proc/slabinfo，并使能内核kmemleak类似选项，最终定位到泄漏的那一行源代码。   结果上述4个步骤，第一类开发者比较轻松地修复了这个内核空间内存泄漏的bug。 3.3 第三类Linux开发者调试方法 第三类开发者没有这么幸运。他的调试步骤是：   1.     以free命令跟踪系统，发现系统free内存睡着时间迁移而持续减小，他确立内存泄漏存在； 2.     怀疑自己写的Qt应用程序有内存泄漏，怀疑Qt本身有内存泄漏；升级Qt的版本，反复查看自己的代码； 3.     怀疑自己写的Qt应用程序有内存泄漏，怀疑Qt本身有内存泄漏；再次升级Qt的版本，反复查看自己的代码； 4.     怀疑自己写的Qt应用程序有内存泄漏，怀疑Qt本身有内存泄漏；降级Qt的版本，反复查看自己的代码； 5.     怀疑自己写的Qt应用程序有内存泄漏，怀疑Qt本身有内存泄漏；再次降级Qt的版本，反复查看自己的代码； 6.     怀疑自己写的Qt应用程序有内存泄漏，怀疑Qt本身有内存泄漏；升级Qt的版本，反复查看自己的代码； 7.     …   光阴似箭日月如梭，第三类程序员，在不断地重复试错中“鬼打墙”，耗尽了青春，也辜负了年华，一晃就过去了大半年。   第一类程序员这个时候就会鄙视第三类程序员，但是，殊不知，第三类程序员，也有鄙视第一类程序员的理由，因为“术业有专攻，闻道有先后”，彼此关注的领域并不一定一样。 对于第三类程序员，如果他在调试的第一步就有了LEP，那么，LEP的数据采集和深度分析能力，将可以直接提示它问题出在内核的slab，直接提示其进一步的调试方向。 LEP类似项目以及LEP的优势 4.1 netdata netdata（如图6）是一款 Linux 性能实时监测工具，提供web界面的界面视角，是github上的2016年度星标项目，项目网址：http://netdata.firehol.org/ 图6 netdata的用户界面 netdata以5分钟为单位，持续刷新系统的运行情况。netdata的web端部署于被监控的平台。它目前的局限性有三： 1.    不具备历史数据分析能力（只有5分钟） 2.    不适合部署于嵌入式系统，web服务本身的开销大 3.    更大地是面向运维，缺乏对开发人员的支持 LEP在具备比netdata更强大功能的前提下，也要解决netdata上述的3个问题，LEP也可更多的面向程序员。 4.2 zabbix zabbix（如图7）是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。项目网址：https://www.zabbix.com 图7 zabbix的用户界面 Zabbix仍然是面向运维的，缺乏调试和分析能力。但是，其“灵活的通知机制以让系统管理员快速定位/解决存在的各种问题”特征这部分值得LEP学习。 4.3 munin munin（如图8）是用于Linux系统的监控软件，munin可以监控系统的各项数值之外，最大的好处是可以自己编写插件自定义监控需要的数值。munin除了可以监控结果，也可以设置报警。项目网址为：http://munin-monitoring.org/ 图8 munin的用户界面 munin具备性能分析能力，”设置报警”和“自定义监控”数据等特征都值得我们学习，但是它仍然缺乏面向程序员的深度分析能力，也不适合嵌入式系统。 4.4 带插件的Eclipse Eclipse IDE（IntegratedDevelopment Environment，集成开发环境）提供了一个类似Visual Studio的集成开发环境。它可以集成一些插件，类似： 此方法的主要问题在于实施难度较大，Eclipse本身过于庞大，对嵌入式的支持也不太完善。安装了插件的Eclipse更像是一个工具大熔炉，它仍然需要用户知道每个工具以及每个工具的具体用法，另外IDE也缺乏持续监控和直接的预警能力。 就易用性角度，LEP直面狗爬式游泳人员，可以进一步降低开发者对Linux本身知识的了解程度的要求。  LEP的当前状态 5.1 代码托管 目前LEP的代码托管于github上面，地址：https://github.com/linuxep，代码仓库中LEPD和LEPV是分离的。分别位于： https://github.com/linuxep/lepd https://github.com/linuxep/lepv 下面演示在64位Ubuntu机器上，同时运行LEPD和LEPV，最后用浏览器监控本机或者ARM板的操作流程： 1.下载、编译和运行LEPD git clone https://github.com/linuxep/lepd.git baohua@ubuntu:~/lep/lepd$ make baohua@ubuntu:~/lep/lepd$ sudo ./lepd–debug [sudo] password for baohua: 注意，如果要编译LEPD的ARM版本，命令为： baohua@ubuntu:~/lep/lepd$ make ARCH=arm 编译后将LEPD拷贝入ARM电路板或者Android手机即可。   2.下载、编译和运行LEPV git clone https://github.com/linuxep/lepv.git baohua@ubuntu:~/lep/lepv$ ./buildDockerImage.sh baohua@ubuntu:~/lep/lepv$./runDockerContainer.sh 3. 开启浏览器 访问127.0.0.1:8889 在弹出的对话框设置监控本机： 如果是监控ARM电路板或Android手机，填写它们的IP地址。   Enjoy： 5.2 支持平台 我们已经在ARM 32电脑板、ARM 64位Android手机和双核、四核X86上部署过LEPD，并以LEPV进行数据跟踪和采集。 目前LEPV仅支持运行于X86 64位机器上，32位机器暂时不支持。 5.3 目前功能 目前LEP具备概况、处理器、内存、磁盘（I/O）和Perf五个视角。 5.3.1 概况视角 概况视角显示CPU、内存、I/O总体的状态： 5.3.2 CPU视角 CPU视角显示各个进程的CPU利用率，多核下负载均衡，IDLE，每个核的CPU占用情况，IRQ+SoftIRQ的比例等：   上述IRQ+SoftIRQ视角，对指导中断负载均衡、SoftIRQ负载均衡（网络下RPS——ReceivePacket Steering等），有很强的指导意义。 5.3.3 内存视角 内存视角显示系统的内存消耗（used、free、page cache等），以及每个进程的内存占用比例，进程的VSS、RSS、PSS和USS等信息： 5.3.4 I/O视角 目前可显示I/O队列情况以及每个进程的I/O访问流量： 5.3.5 perf视角 目前可显示系统运行时，基于symbol的时间分布，类似perf top命令的功能： 5.4 目前缺陷 目前的缺陷及改造方向： 1.    监控是浏览器触发的，如果浏览器不点击开始，不会开始。改造目标：自动监控，无论浏览器连接不连接。所以LEPV需要后台，后台设置后就连续从LEPD采集数据。 2.    没有数据库，没有历史数据。未来考虑除了显示最近五分钟视图以外，增加类似股市的日线图、周线图、月线图。另外，需要增加采集数据和分析后数据的保存与读取能力。 3.    功能性缺失，比如中断、软中断、上下文切换次数，基于cgroups的CPU、内存、I/O分析。改造方向：增加中断、软中断、上下文切换、swapin、swapout、slab、vmalloc等的视角，增加cgroups的分析视角。 4.    没有系统的测试以及剖析LEPD本身对监控目标的消耗。改造方向：增加测试案例，执行Q/A，执行LEPD本身对监控目标性能影响的报告。 5.    深度分析能力仍然不够。比如，我们只是单纯的显示负载，没有办法提示用户目前负载重，没有办法监控到内存泄漏后进行提示。界面上也缺乏对用户适当的提示，对于初级用户来说，还是看不懂。 6.    缺乏中文英文的自动切换，目前暂时只有中文版。改造方向：默认根据浏览器语言，选择英文、中文，提供用户设置的能力。 7.    以监控为主，控制能力不足。理想上面，我们可以对目标监控系统进行一定的配置，比如设置某个进程的nice，可以在top里面点右键来设置；比如，我只想监控某个进程，某个进程的所有线程等。 本文未完待续 >>>  iphone用户打赏 Android用户打赏