另一份Java应用调优指南之

每一次成功的调优，都会诞生又一份的调优指南。

一些必须写在前面的军规，虽然与Java应用的调优没直接关联，但是测试同学经常不留神的地方。

包括跑JMeter的那些机器。

"top"或者"pidstat -l 2 10" 看一下，其他的路人甲乙丙丁的应用都关干净了没。

如果是云主机，确保百分百占有宿主机的资源，或者深夜大家下班了你在家连VPN回来跑。

必须完完全全的了解你的机器，才知道有没卡在某个瓶颈，或者与线上环境、其他测试结果的比较。

还是那句， 包括跑JMeter的那些机器。

"cat /proc/cpuinfo", 看最后一条就好，比如

所有数字都从零开始，physical id:1即两颗cpu， cpu core: 6即6核，processor : 23即24个处理器。

不过也有很多同事喜欢说24核，也懒得纠正了。

"free -h" 没什么好说的。

普通硬盘的写速度大概100M/s，RAID级别的查看不方便，SSD的速度也不定，所以用dd测一下最靠谱:

上面命令测试了分别以每次8k和1g的大小，写入1g文件的速度。

硬盘读速度的测试同理，不过要先清理缓存，否则直接从Page Cache读了。

先用ifconfig看看有多少块网卡和bonding。bonding是个很棒的东西，可以把多块网卡绑起来，突破单块网卡的带宽限制。

然后检查每块网卡的速度，比如"ethtool eth0"。

再检查bonding，比如"cat /proc/net/bonding/bond0", 留意其Bonding Mode是负载均衡的，再留意其捆佳节又重阳绑的网卡的速度。

最后检查测试客户机与服务机之间的带宽，先简单ping或traceroute 一下得到RTT时间，iperf之类的可稍后。

Linux的内核版本，是否64位： "uname -a"
Redhat/CentOS版本 : "cat /etc/redhat-release"

讲究点，要用来出报告的，用Zabbix之类。

实时观察的，我喜欢dstat，比vmstat，iostat, sar们都好用，起码对得够齐，单位能自动转换。不过dstat需要安装(yum install dstat，如果装不上，就要将就着用vmstat，sar了)

要看IO细节，还是要用"iostat -dxm 5"

JMeter的版本越新越好。

它默认连个垃圾收集算法都没有配，对延时要求高的，必须配上CMS或G1，内存也整大点降低GC的频率。其他的，给Server配的啥参数，给JMeter也来上一份，最好把-XX:+AggressiveOpts也加上。

什么if 语句，以及所有其实用动态语言来实现的都挺慢的。
xPath抽取结果集里的字段之类看着就慢的也别写了。
别加任何监瑞脑消金兽听器和图形。
再配置输出日志的格式，能不要的列都别要了，最极端的其实就延时这列有用。

在Linux上用命令行跑，别偷懒用Window开着界面跑。
别开超过200条线程。
可以在不同机器上起多个JMeter，用集群汇总的模式。

初始连接，Server端热身，JVM编译热点方法等都需要时间，所以建议统计前删掉前面的一些日志。

要配置一下才能看到99.9%, 99.99% 分位数的延时，另外因为之前输出日志时省略了很多列，导入日志的时候配置也要如此。

但如果不能XWindows Forward，还要把日志下载回来再导入本地的JMeter，那还不如自己动动手，用sed, awk, sort配合一下自己写个分析延时的脚本。

唠叨完这些写给测试同学的话，下篇，就可以正式开始调优了。

更重要的是，唯品会广州的基础架构部还在继续招人啊，简历请砸 calvin.xiao@vipshop.com

另一份Java应用调优指南之前菜 by 江南白衣 转载请保持链接。

来自： http://calvin1978.blogcn.com/articles/perf-tunning-1.html