一款比较强悍的存储性能分析工具（未完待续）

开发目的

我这边zip解压缩和io跑分类问题经常会涉及到不同存储芯片间的存储性能对比。
众所周知，存储性能问题，跟存储芯片自身性能，块设备层和文件系统层的性能都有关系的。所以说搞出一款工具，能够直观地看出
某性能问题对应的在存储bsp层，块设备层和文件系统层的耗时信息，是有助于解决存储性能问题的。

适用场合

该工具目前比较适合用来分析单线程存储性能问题。
比如zip解压缩，androbench顺序读写和sqlite跑分都是属于单线程性能问题分析范畴的。因为这些测试项目在实际进行时，只有一个线程在做性能测试工作，最后输出的性能指标只跟该线程的性能有关。

使用介绍

1 搭建bcc环境

参考之前的博文：bcc工具上手指南，搭建好测试手机的bcc开发环境。

2 获取存储性能分析工具

从http://gerrit.pt.mioffice.cn/#/c/XXX上 把工具：ioworkload_analysis.py 和 ioworkload_analysis_not_included_blk​.py下载到本地，然后adb push 到手机的/data/androdeb/debian目录里面，并对它们chmod 777一下。

3 开启性能trace

执行 下面命令，开启存储性能trace。
adeb shell
./ioworkload_analysis.py 0 > /data/io.log

4 开始性能测试

开始跑性能测试（比如上面的zip解压缩和IO跑分），
 跑完性能测试后，把上面生成的手机里面的/data/io.log文件adb pull到电脑端, 产生的文件系统层，块设备层和bsp层的存储性能耗时信息都在上面的io.log文件里面。

5 分析存储各层面的性能耗时

拿androbench跑分性能分析举例，来说明怎么得到在bsp层，块设备层和文件系统层的耗时信息。（androbench跑分性能跟Thread-xxx这个线程的工作性能挂钩的）

1> 文件系统层

cat io.log | grep Thread- | grep VFS | awk '{sum += $8};END {print sum}'

可以得到文件系统层面的总耗时信息

cat io.log | grep Thread- | {grep " N "，grep " W "，grep " R "} | wc -l

可以得到文件系统层总共发送了多少fsync or write or read系统调用数目。

2> 存储bsp层

 cat io.log | grep Thread- | grep REQ | awk '{sum += $8};END {print sum}'
可以得到跑分时发出的块设备层所有请求完成（req issue到req complete）总耗时信息。

cat io.log | grep Thread- | grep REQ | wc -l
可以得到跑分时发出的请求总数目。

请求完成的平均耗时 = 所有请求的总耗时 / 上面的总数目.
请求完成的最大耗时和耗时分布可由sort -nr命令得出。

上面信息便代表了存储bsp层的耗时信息。

3> 块设备层

cat io.log | grep Thread- | grep REQ | awk '{sum += $6};END {print sum}'
得到了IO跑分时的块设备层的请求排队耗时（req insert到req issue）信息。

cat io.log | grep Thread- | grep BLK | awk '{sum += $8};END {print sum}'
可以得到IO跑分时的块设备层submit bio的总耗时。

cat io.log | grep Thread- | grep BLK | wc -l
得到跑分时的submit_bio调用次数。

上面信息便代表了块设备层的耗时信息。

因为块设备层的耗时有两方面的耗时组成，一个是submit_bio的耗时，一个是请求排队耗时。

目前应用成果

目前正在应用该工具解决IO跑分和zip解压缩中不同存储芯片对比的性能问题。
已经能够成功看出jira：MIUI-1826523里面的q版本sliqte性能衰退问题是由于文件系统层fsync性能不如p版本造成的，
存储bsp层和块设备层q版本的性能还好于p版本的。（该jira还在进一步地分析定位中）