这几天进入了一个项目组做性能测试、性能调优分析相关的工作。
今天在压力起来之后，几个命令就看到了一个问题。分享一下。
系统架构就不说了，典型的java应用。脚本是用jmeter写的java request。压力发起来之后，并发线程的增加并没有看到TPS明显的提升。
于是看了一下top中的状态：
从上图可以看到CPU总体使用率并不高。但是有一个地方需要格外注意。第一个CPU的IO wait非常高。达到72.2%。
很明显，看到这样的IO wait，就想iostat一下，然后再iotop看是哪个进程。可惜的是系统中没有装iostat命令。于是直接iotop：
看到IO消耗这么高的进程是一个叫jbd2的，全称是journaling block driver 。这个进程实现的是文件系统的日志功能，磁盘使用日志功能来保证数据的完整性。这个需要评估一下安全和性能哪个更重要，对于一个应用服务器来说，并不保存重要的用户数据，只是实现业务逻辑。如果是数据库的话，就需要考虑启动磁盘写入的完整性检查。但是现在大部分系统在业务和架构层面已经考虑了业务完整性。所以为性能计，这里并不是非常有必须启动日志功能。
另外，说到这里不得不说一下挂载磁盘时的barries参数默认这个值是1，启动状态。这个参数从语义上来解释就是一个栅栏，一个分界线。当启动时，在这个分界线之前要全部写数据到存储介质上，从而保证了数据的完整性。
当然这是以牺牲性能来保证的日志完整性。
之前还有因为系统级的bug导致jbd2很高的。还没有去查过官方的Bug list，不清楚这个版本中还有没有这样的bug。在理解了原理之后，就有了调优的方向。
- 查系统级的bug list，如果有的话就修复掉；
- 是要性能还要磁盘写日志的完整性，估计这样的问题在汇报给领导的时候，都是说要，但是从技术上来说，一个应用服务器要这个功能的意义并不大。
顺手把perf 打出来的结果也show出来看看：
可以看到磁盘的IO队列是消耗CPU时间片最多的。
很多的性能分析都是这样，当明确知道一个数据的含义和原理之后，就可以明确地做出判断。
