基于System Tap的Linux服务器性能分析系统的设计与实现

裴欧亚，康慕宁，张 磊

（西北工业大学 计算机学院，陕西 西安 710072）

随着Linux操作系统在大型服务器上的广泛应用，对系统的性能提出了更高的要求。因此Linux系统开发人员希望通过对Linux系统进行性能测试，定位系统瓶颈，分析引起性能问题的原因。系统的性能不能通过单一指标来判定，必须通过系统的整体性（综合指标）来判定。Linux作为全球最广泛使用的开源操作系统，其超高的性价比，决定了对此内核的可视化性能分析研究具有重要的学术意义及深远的教育意义。

可视化其实质是利用计算机的图形图像技术，把各种数据信息转换成合适的图形图像在屏幕上表示出来。这一过程涉及到图形学、和人机交互等领域知识。基于SystemTap的Linux服务器性能分析系统通过SystemTap，在Linux内核的合适位置添加探针，当启动检测时，以事件追踪机制实时进行数据的收集、解析，最终以可视化的界面呈现给用户。用户可以通过可视化界面直观的对系统的资源利用率及运行状况进行性能分析和优化。

1 性能分析系统设计分析

针对为满足Linux服务器性能分析的需求，结合SystemTap及 “事件追踪机制”等技术方式，经过分析得到Linux性能数据共分为以下3个部分：进程/线程的实时运行状态；进程间的通信状况；以及对系统资源的占用状况。

要想完成以上性能数据的收集、分析及可视化等功能，需要做好以下几个方面。首先服务器端应能实时收集性能数据，并且能确保将收集到的性能数据传回客户端；其次客户端能正确解析服务器段传回的性能数据，即将数据转换成可视化数据；最后可视化模块能将最终结果呈现给用户。

本系统在软件架构上基于C/S结构，server端负责接收命令、收集数据及发送数据，client端负责控制、解析数据及显示数据，很好的满足了用户提出的“尽量减小对服务器性能影响”的需求。

C/S（Client/Server）模式即客户端服务器端架构，它可以采用任何通信协议，客户端包含一个或多个在用户的电脑上运行的程序，客户端向服务器端发送请求命令，由服务器处理响应并将信息返还给客户端，再由客户端处理服务器的返回信息并将处理结果显示给用户。虽然B/S架构是对C/S架构的改进，但是C/S相较于B/S，其具有的响应速度快，对服务器性能影响较轻的特性，决定了本系统必须使用C/S架构。

2 总体设计

该性能分析系统的系统结构图如图1所示，在对目标服务器进行测量时，首先目标服务器必须开启Server端服务；接着Client端向Server端发送开始监测命令，Serevr端收到开始命令、启动监测并记录数据；然后Client端向Server端发送终了监测命令，Server端收到终了命令、停止监测并将数据传回Client端；最后Client端先调用解析模块将Server端传回的数据解析，然后调用可视化模块将解析的结果以图形化方式显示给用户。

图1 系统结构图Fig.1 Structure diagram of performance analysis system

3 性能分析系统软件设计

该性能分析系统软件采用C/S架构，客户端功能：向服务器端发送控制命令、接受服务器端数据、数据解析及数据可视化功能，服务器端功能：接受客户端命令后回传性能数据和收集性能数据。为了日后的更新、维护和拓展，在设计过程中采用模块化的思想，因此将客户端划分为通信模块，数据解析模块，数据显示模块。服务器端划分为通信模块，数据收集模块。系统软件设计的结构图如图2所示。

图2 系统软件设计结构图Fig.2 diagram of the software analysis system

在软件设计中，数据收集模块主要用来实现对Linux服务器性能数据的收集；服务器端的通信模块主要用来接受客户端发送来的命令，通过该模块可以控制数据收集模块的启用开关，并且能将收集到的性能数据传回客户端；客户端的通信模块主要用来向服务器端发送命令以及接受服务器端传回的性能数据；数据解析模块主要用来将性能数据解析成可视化的数据；数据显示模块主要用来将可视化的结果以图形化界面方式呈现给用户。

4 性能分析系统重要模块的设计与实现

4.1 数据收集模块

为了收集linux实时的运行数据，必须借助于System Tap[1-6]，在Linux kernel源代码的关键之处加上探针，并为所加探针新规处理函数（保存获取的内核数据）。一旦探针被触发，被触发探针的处理函数立即保存获取的内核数据。

例如：创建进程（sched_process_fork）处添加探针及探针处理函数如下：

实现数据收集模块的难点有以下3点：

第一点：确定探针添加的位置。探针添加的位置决定能获取何种类型的linux内核数据。此外SystemTap的探针处理是以中断方式处理的，而linux内核在某些代码处不允许产生中断（中断会导致系统宕机等问题），再加上SystemTap理论上可以在linux内核任意位置添加探针，所以添加探针的操作必须小心谨慎。因此需要开发人员必须熟悉linux内核某个功能或全部功能的源代码及处理逻辑流程。

第二点：探针处理函数的高并发导致的“写竞争”。每一个探针都关联一个写内存的处理函数。在负载很重的服务器上，同一个探针不间断被触发，或多个探针同时被触发，都会导致多个处理函数竞争同一个内存块。因此必须为内存块填加写互斥锁，实现内存块的互斥访问。本系统为实现写内存互斥，定义了一个全局的静态变量（变更静态变量值的操作是原子操作）。每一个处理函数写内存之前都要先判断静态变量的值。如果为TRUE则可继续进行后续操作；否则，将阻塞。

第三点：长时间测量。经过实验：单台小型服务器在高负荷工作时，少量探针（hooks）每秒产生的需要保存的数据就高达40M，因此只能将收集的数据写入磁盘保存。为了避免频繁写磁盘对服务器正常I/O操作产生影响，同时加快写磁盘的速率，尽可能避免因磁盘写速率低造成的数据丢失。本系统采用如下设计：

在内存中申请3块大小为64M （可由用户手动设置，默认最小 64M）的内存空间，编号为 BufferNo0，BufferNo1，BufferNo2。这3块内存按编号从小到大循环使用。只有当当前的内存空间为空并且前一块内存空间写满的情况下，才能向当前的内存空间写数据。每一块内存都有互斥锁，保证同时只有一个探针的处理函数向可写内存块写数据。每当一块空间写满，立刻将该写满的内存块中的数据转移至磁盘，同时清空该内存块，为接下来需要保存的数据准备空间。

4.2 数据解析模块

从服务器端传回的性能数据是以二进制的形式保存的，用户几乎不可能快速通过查阅二进制信息来分析服务器的状况。因此必须将二进制形式的数据解析成方便用户查阅及可视化模块使用的数据格式。

长时间的收集使得最终收集的数据量高达数G（目前最大支持4G），因此解析大数据的性能成了本性能分析系统的瓶颈。

为了提升解析数据的效率，最终选取了Windows操作系统提供的内存文件映射技术。内存映射文件技术是由一个内存映射文件是由一个文件到一块内存的映射，使进程虚拟地址空间的某个区域与磁盘上某个文件的部分或全部内容建立映射。建立映射后，通过该映射区域可以直接对被映射的磁盘文件进行访问，而不必执行文件的I/O操作，也无需对文件内容进行缓冲处理，就好像整个被映射的文件都加载到了内存一样。

运行内存映射主要有以下几个步骤：

1）用函数CreateFile（），以适当的方式创建或打开一个文件核心对象；2）将函数CreateFile（）返回的文件句柄作为参数，调用函数CreateFileMapping（），创建一个内存文件映射对象；3）调用函数MapViewOfFile（）将整个文件的部分区域或者全部映射到内存；4）用函数MapViewOfFile（）返回的指针来读写文件；5）调用函数UnMapViewOfFile（）来解除文件映射；6）调用函数 CloseHandle（）来关闭内存映射文件；7）调用函数CloseHandle（）来关闭文件核心对象[7]。

4.3 数据显示模块

数据显示模块主要是将数据解析模块生成的可视化数据以图形界面的方式呈现给用户。为了消除重绘过程中产生的闪屏问题，采用了双缓冲机制来绘制图像[8]。

可视化界面沿着水平时间轴 （单位/s）真实地还原了linux服务器运行时，进程调度、磁盘调度、系统资源（cpu、disk等）的占用率。

可视化界面[9]截图如图3所示。

图3 可视化界面截图Fig.3 The screenshot of visualization interface

图3的左侧是Linux运行时所有进程的列表，包括进程名、进程ID及线程ID。右侧就是进程动作状况表示区域，显示所有进程/线程实时运行状况。进程/线程对Cpu和磁盘的使用状况只分为两种状态：执行中和等待即空闲状态，分别标记不同的颜色进行区分。当不同进程进行通信时，以不同的颜色进行区分通信的方式，如信号、PIPE（管道）、NPIPE（无名管道）、MESSAGE等方式。

图3中显示了进程号和线程号均是4389的进程Xorg与进程号和线程号均是4727的进程gnome-terminal之间通信的动作。

5 性能分析系统应用

某一产品软件，客户端和服务器端通信开销突然从0.5 s增加至4 s。由于逻辑复杂，开发人员短时间内无法分析出问题原因，通过使用本系统，使内核状况可视化，只用一个小时就将问题点明确，快速解决了该问题。

通过可视化测量结果，进行详细分析，发现一个问题见图4中第一幅图虚线框列出的问题：1。

图4 可视化性能分析实例Fig.4 The example of Visualization performance analysis

问题：CPU等待/空闲区间过多

根据问题应采取以下措施进行改善：

1）CPU等待/空闲区间的原因检讨；

2）减少进程间的通信次数；

通过以上两点对代码进行改善，再次运行后，对比发现：改善前需要9.75 s的处理时间，改善后只需要1.95 s（约1/5）。

注：上下两幅图倍率，区间相同 （时间间隔6 s）

6 结 论

本软件系统采用模块化设计，提高了系统的可扩展性和可维护性，便于二次开发。该软件系统采用了友好的界面设计，目前已交付某大型跨国IT企业使用，主要用于分析该企业大中型服务器的性能。实际应用情况表明，该系统显著地缩短了解决服务器性能问题所需的时间，同时该系统还具有操作简单，稳定可靠、人机交互良好等特点，达到了要求。

但是本系统还有以下不足：

1）在Linux操作系统中添加的‘探针’数量较少，导致获取的性能数据不足。

2）Linux服务器将内存数据转移至磁盘过程中，由于探针产生的数据量过大，会导致部分需要收集的数据丢失。

3）可视化界面对性能数据的显示粒度略显粗糙。

因此，后期将对以上不足进行仔细分析并逐一解决，进一步完善本文所描述的性能分析系统。

[1]李云华.Linux内核调试新秀System Tap[R].程序员，2010，（3）:127-127.

[2]Frank Ch.Eigler.Systemtap tutorial[EB/OL].（2013）[2013-08-20].http://www.sourceware.org/systemtap/tutorial.pdf

[3]SystemTap Language Reference[EB/OL].（2013）[2013-08-20].http://www.sourceware.org/systemtap/langref.pdf

[4]薛伟伟.软件性能测试和分析方法的研究与应用 [D].西安:西北工业大学，2013.

[5]谢雨辰.基于SystemTap的Kprobes与Relayfs的开发[D].吉林:吉林大学，2007.

[6]Prasad V，Cohen W，Eigler F，etal.Locating system problems using dynamic instrumentation[C]//Linux Symposium，2005:49-64.

[7]马礼，李敬喆，葛根焰，等.一种基于多核环境的海量数据快速读取方法[J].计算机研究与发展，2011（48）:63-67.MA Li，LI Jing-zhe，GE Gen-yan，et al.Quick-Read means ofmass data based on multi-core environment[J].Journal of Computer Research and Development，2011（48）:63-67.

[8]明日科技，孙秀梅，王雪，等.Visaul C++典型模块与项目实战大全[M].北京：电子工业出版社，2012.

[9]王卉，赵政文，齐万华.基于Windows运行过程可视化的软件性能分析[J].微处理机，2013（1）:45-48.WANG Hui，ZHAO Zheng-wen，QI Wan-hua.Software performance analysis of visualized software based on windows operating[J].Microprocessors，2013（1）:45-48.