性能测试中的服务器数据监控

1.推荐用nmon写报告

在服务器装好nmon之后，只要用nmon -f -t -s 30 -c 120 这种命令就可以监控服务器的数据，在执行命令的目录下生成一个.nmon的文件。然后从服务器把文件取下来（推荐使用FTP客户端去服务器上取文件），再用nmon analyser打开nmon文件生成一个Excel文件，可以很直观的看数据，直接写进报告，这个是比较方便写测试报告的。

2.测试过程中实时监控服务器数据找性能瓶颈

top，之后大写的P可对当前的消耗进行排序，找出最消耗资源的进程

按1后可显示每个CPU核的情况

图一

    1.数据库瓶颈

可看到当前消耗最大的是mysql

那就去mysql下找当前消耗最大的SQL

mysql -u root -p回车输入密码，进入mysql

show processlist  回车 输入;回车

查高消耗的SQL show FULL processlist 回车 输入;回车

找到高消耗SQL，对SQL进行优化

      2.Java进程瓶颈

如果高消耗不是数据库，而是Java进程，那就从进程找高消耗线程再由线程找堆栈，查代码找高消耗的原因

• top命令看到高消耗的进程，找到进程PID
• 再通过ps -mp PID -o THREAD,tid,time或top -H-p PID查看进程下线程的占用资源情况
• 
• 在用jstack PID |grep TID查看线程堆栈信息，然后通过查看代码定位瓶颈（PID进程ID，TID线程ID）---一般要有权限才可看，要将线程id转换成16进制的话，用printf  "%x\n" TID
• jstack  101 >test.txt将线程dump保存下来方便分析，将其从服务器上拉下来之后用TDA工具打开可以方便快捷的分析（我使用的是visual VM工具，装入了插件TDA，TDA也可以单独使用），通过查看线程dump主要是为了查看性能消耗较大的线程都调用了哪些方法，再查看代码分析为何占用过高，看能否优化

• heapdump（eg：jmap -histo:live pid|less、jmap -dump:format=b,file=xxx.hprof PID）

将堆dump弄下来之后用visual VM或者是jprofiler工具打开可以看到哪些是大对象，如果内存消耗过多，FULL GC频率过高的话，需要考虑从这些大对象身上去做优化。如果在本地将java服务起起来的话，这两个工具可以监控到本地java进程的消耗情况。

   3.Java的内存泄漏

• jps可以查看目前有哪些Java进程
• jstat -gc PID查看是否有内存泄漏（jstat -gc PID 1s >test_gc.txt）

(关于新生代 & 老年代的笔记：

1.堆内存分为新生代、老年代、永久代
2.长期存活的对象会进入老年代，当minor GC之后，年龄增加一岁，加到配置的参数值时，他还活着就进入老年代
3.因为minor GC之后，新生代可能会进入老年代，所以在minor GC之前，最好确保老年代的可用内存大于新生代已占用空间
4.FULL GC一般要比minor GC耗时长10倍，而且FULL GC的时候JAVA进程不干活，所以FULL GC不能耗时太长
5.JAVA对象：伊甸园--》幸存区--》老年代
6.JVM无法为新建对象分配内存空间时，伊甸园满了，就会Minor GC，所以新生代占用率太对，那么Minor GC就会多
7.minor GC处理的是新生代，FULL GC是处理新生代跟老年代）

jstat怎么看有没有问题：

FGC不能太大，应该占整个GC（YGC+FGC）的1%到5%才正常

OC和OU关系，OU（老年代使用大小）与OC（老年代大小）很接近，JVM是存在内存泄漏的

 

3.监控指标

图一top命令中，Linux的负载均值（load average）需要小于核数，当大于核数就说明有性能瓶颈需要优化。

top命令，进程列表中的%CPU也不能超过核数，如图一所示31933进程%CPU是14，而我的服务器是8核的，也就是小于800，所以完全无压力，当某进程大于800时说明把所有的CPU都跑满了，说明有瓶颈，存在风险。

top命令中的%id空闲率不能小于20%

关于内存的监控，测试报告中我一直使用(memtotal-memfree)/memtotal，这个数写进报告是ok的，但其实是不准的，准确的查看应该用free -m（看available）

用其中的mem available/memtotal

PS：nmon监控会对服务器产生一定的消耗，但是top等命令一样会有资源消耗的，so~~~whatever