lttng部署和测试ceph 性能RT尖刺（黑神话悟空性能测试工具）

为了分析ceph的RT尖刺使用lttng进行分析ceph中函数的使用时间，确定占用时间较多的函数，分析尖刺原因。

本文主要介绍三部分，lttng的安装，ceph中的埋点，测试和结果分析。

一、lttng的安装：

lttng说明地址：http://lttng.org/docs/v2.9/#doc-tracing-your-own-user-application

lttng主要需要安装3个工具，kernel、usr、tools。

这三个工具可以直接安装、也可以源码安装，但是必须要安装。

源码安装前，需要安装依赖库

• libuuid
• popt
• Userspace RCU
• libxml2

源码安装：

跟踪内核态程序的工具。

LTTng-modules 2.9：

cd $(mktemp -d) &&

wget http://lttng.org/files/lttng-modules/lttng-modules-latest-2.9.tar.bz2 &&

tar -xf lttng-modules-latest-2.9.tar.bz2 &&

cd lttng-modules-2.9.* &&

make &&

sudo make modules_install &&

sudo depmod -a

跟踪用户态程序工具

LTTng-UST 2.9：

cd $(mktemp -d) &&

wget http://lttng.org/files/lttng-ust/lttng-ust-latest-2.9.tar.bz2 &&

tar -xf lttng-ust-latest-2.9.tar.bz2 &&

cd lttng-ust-2.9.* &&

./configure &&

make &&

sudo make install &&

sudo ldconfig

lttng的命令行工具

LTTng-tools 2.9：

cd $(mktemp -d) &&

wget http://lttng.org/files/lttng-tools/lttng-tools-latest-2.9.tar.bz2 &&

tar -xf lttng-tools-latest-2.9.tar.bz2 &&

cd lttng-tools-2.9.* &&

./configure &&

make &&

sudo make install &&

sudo ldconfig

安装完成后 测试lttng 命令是否成功

二、ceph 中的埋点：

在c++代码中如何添加点，已经在lttng的使用文档（http://lttng.org/docs/v2.9/#doc-tracing-your-own-user-application）中说明。

埋点：定义事件名称ali_ReplicatedPG_do_request_enter。tracepoint添加埋点

lttng在埋点后的抓取效果如下：

[15:30:49.922266027] (+0.000001282) db101163131.et2sqa osd:ali_ReplicatedPG_do_request_enter: { cpu_id = 10 }, { pthread_id = 47840275465984, procname = "tp_osd_tp" }, { desc = "begin" }

可以分析出主机的名字，事件名称（埋点时候起的名字），cpu所在的核心，线程id，线程名称，等等数据，可以自己添加。

基本的效果就是上面这样，但是我们想基于lttng抓取的事件分析出函数的调用栈和函数占用时间关系。那就要在每个函数埋2个点，一个在函数入口处enter事件，一个在函数的结束exit事件。

根据成对的enter和exit事件，可以分析出函数的调用栈，还有函数的调用时间。

目前有一个开源的工具可以直接打点，但是基于个人的ceph版本，所以还需要合并到10.2.5的代码中，有一些变动。

开源埋点方法，不需要定义很多事件，添加事件埋点方便，代码比较：

https://github.com/yehudasa/ceph/commit/b7b14ad138683a9f98a199d55fa736abea836d5c

新增一个EventTrace的类，利用该类的构造和析构过程添加事件，可以减少在源码中打点的工作量。

在构造函数中tracepoint（enter）事件，在析构函数中tracepoint（exit）事件。所以只需要在func函数进入时声明一个EventTrace对象，自动调用构造函数，在func函数结束时自动调用EventTrace对象的析构函数。

目前基于该埋点方法，有对应的在代码文件中自动添加埋点的脚本。

埋点脚本在https://github.com/rchagam/tracetool的中有说明。

自动埋点后源码编译可能存在问题，需要自己修改解决。

三、测试和结果分析：

测试步骤：

1. 启动lttng服务线程：sudo lttng-sessiond --daemonize。
2. 启动ceph的进程，这里由于测试环境，直接使用vstart.sh脚本启动。在启动脚本前要找到一个liblttng-ust-fork.so库，该库一般是安装在/usr/local/lib/liblttng-ust-fork.so中，使用命令sudo LD_PRELOAD=/usr/local/lib/liblttng-ust-fork.so MON=1 MDS=0 OSD=3 ./vstart.sh -d -x -n。可以把LD_PRELOAD=/usr/local/lib/liblttng-ust-fork.so直接添加到环境变量中，如：
   

这样不需要每次运行命令前都添加LD_PRELOAD

3.然后创建lttng的 tracing session。

a.创建session。 sudo lttng create big-channel

b.创建buffer。sudo lttng enable-channel --userspace --num-subbuf 16 --ssubbuf-size 16M big-channel

c.捕获事件的参数。sudo lttng add-context -u --channel=big-channel -t pthread_id -t vpid -t procname

d.捕获事件过滤。sudo lttng enable-event --userspace --channel=big-channel eventtrace:* e.开始捕捉。sudo lttng start

f. 由于现在已经启动的线程中，不一定初始化了EventTrace对象，所以这里使用sudo lttng list -u 看不到事件,由于我进行的打点在ceph-osd进程中会使用到，所以能看到lttng事件。但这不影响事件的捕捉。

4. 上面ceph运行成功，lttng session设置成功，就可以开始捕捉事件。

测试的时候采用rados bench命令：rados -p rbd bench 100 write.

测试的结果：Max latency 出现在3.55296s。

5.lttng 数据导出

这时可以使用sudo lttng list -u 查看是否存在lttng事件，如果此时返回的是

说明没有捕捉到任何事件。所以是不成功的（原因 可能是ceph 编译时没有打开lttng和eventtrace选项，或者ceph配置中没有打开event_tracing配置）。

如果使用sudo lttng list -u可以正常看到事件。

停止 事件捕捉 sudo lttng stop

导出捕捉的事件，并且保存到一个文件中 sudo lttng view big-channel > ~/foo.traces

使用工具分析foo.traces。工具的使用方法参考链接：https://github.com/rchagam/tracetool

该工具主要从 日志中分析函数调用栈，从traces中分析函数的调用时间和跟踪object。

下面是一个函数调用时间结果：

分析函数的调用栈，可以看出耗时最长的函数

ENTRY:reserve_throttle_and_backoff:os/filestore/FileJournal.cc:2142。

消耗的时间 是3.265754s和rados bench 测试的RT尖刺 3.55296s很接近。

所以该函数是主要RT尖刺的原因。

注：

lttng 部署不成功的原因有以下几个：

1. lttng-sessiond --daemonize启动。
2. ceph 的源码编译，添加lttng babeltrace eventtrace 编译选项，默认都是关闭的。
3. ceph的配置文件，在配置文件中打开对应的tracing 配置。
4. ceph的启动，PRE_LOAD 环境变量的添加。
5. EventTrace 工具会和Lttng的session存在冲突，导致ceph的进程启动卡住。每次lttng stop之后记得要lttng destroy 对应的session，才不会影响ceph进程的下次启动。
6. 权限问题，运行命令前，都添加sudo。