最近测试一项目，性能非常不理想。老版本逻辑和功能都简单时，性能是相当的好！接口点击率是万级的。谁知修改后上不了百。
架设Jboss服务器，业务逻辑用Java处理，核心模块使用C++处理，使用JNI衔接。
本应用对CPU和硬盘第三非常敏感，因为有压缩解压和大量数据交互。起初作压力测试时，发现服务器各资源使用都有剩余，而点击率曲线波动却非常大，简单看似乎是应用程序有问题。
使用top查看Cpu各核的使用情况，发现一个非常诡异的现象：
1. 经常只有部分核是满载的，另外一部分基本空闲；
2. 在CPU满载时，%wa 的波动比较大，有时会占到较大比例。
所以，监控整个CPU时会发现CPU使用率不高，实际上任务总是分派到某个核上且导致对应核满载。无法有效使用CPU，其它资源自然也难以有效调度。
废话不多说，%wa指CPU等待磁盘写入完成的时间。莫非是磁盘忙，怎样证明是磁盘在忙？
首先看下%wa的解释：Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.
起初用`lsof | less`查看文件的读写情况，发现/tmp目录下有大量文件读写。经查证，是Jboss处理上传文件会默认写入到/tmp文件夹，然后再执行了一次拷贝到程序读取的目录。修改Jboss配置直接写入到程序读写目录，性能没有本质上的改变。
关于CPU使用波动大，我们也在程序内部加了很多计时器，发现某些模块在处理并发时会有响应时间很长的情况，这点证实了为什么点击率波动很大。
但此模块进行单进程串行测试时，每秒完成事务数是相当可观的。一个进程每秒完成的事务数都比当前测试点击率要高很多！使用多进程来测试此模块时，发现“进程数=核数”时效果最佳。于是在Java层控制同时进入此模块的数量，毕竟Java是调用JNI来使用此模块，使用全局锁来控制并发，最终结果没有想象的那么理想，但明显可以看出：通过控制并发数，能有效提高CPU的使用率，点击率也上升了一些。
另外一个问题就是，CPU会出现一会满载，一会空闲的情况，导致点击率曲线仍然波动大的问题。商讨后决定在C++代码中加入“释放CPU控制权”的逻辑，这样就在代码层来作了一个负载均衡。点击率波动的问题得到了好转，但点击率仍然不理想，预期瓶颈是网络而实际变成了CPU。
优化了压缩解决的处理后，性能没有明显提升。这时我才想起%wa，我还没有进一步证明是磁盘的闲忙程度。使用了一些监控工具，诸如：vmstat、sar、dstat、sysstat 没有发现对磁盘作非常详细的监控。最后试了下iostat，搞定！
iostat的编译非常简单，就一个c文件，MakeFile里作者写了一句话“Cann't be simpler”。直接make install就在目录下生成了iostat的可执行文件，看一下帮助，执行 `iostat -cdDx 10` 。其中有一列“%b”描述了磁盘的闲忙程序，简单直接。另外还有详细的磁盘IO读写数据，帮助里也解释得非常清楚。
再进行一次压力测试，拿着这份数据，已经绝对性的说明问题了。此时那些大牛把代码改了一下，性能立马就上去了，千兆网络直接成为系统瓶颈。并于Java的控制问题，改用Apache直接编译程序模块调用，完成变为可控，问题瞬间解决！
附上iostat的源码：
