S.l.e!ep.¢%

像打了激速一样,以四倍的速度运转,开心的工作
简单、开放、平等的公司文化;尊重个性、自由与个人价值;
posts - 1098, comments - 335, trackbacks - 0, articles - 1
  C++博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

 最近测试一项目,性能非常不理想。老版本逻辑和功能都简单时,性能是相当的好!接口点击率是万级的。谁知修改后上不了百。

    架设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的源码:

http://code.google.com/p/tester-higkoo/source/browse/trunk/Tools/iostat/iostat.c


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理