系统监控主要分三块:
1.performance monitoring 生产环境,查看性能
2.performance profiling 非生产环境,收集数据
3.performance tunning
CPU 利用率
对于计算密集型程序,还可以看一个cpu周期执行的指令数(IPC instructions per clock),因为在cpu利用率高的情况下,这种高占用可能包括了cpu等待内存数据的时间,这种等待在指令在寄存器或者cache准备好前的任何时候都会发生,这时候cpu只能浪费掉时钟周期等待数据
vmstat
cpu
CPU 计划运行队列
cpu计划运行队列保存就绪等待cpu执行的进程,这个队列的深度可以体现cpu的繁忙程度,如果队列深度达到了虚拟处理器数的4倍或更多,那么意味着系统相应会明显迟钝。
一般在1倍的时候就需要注意了,到了3-4倍就需要尽快处理了。一般处理这种情况有两种方法。一是增加cpu,另一方面是降低对cpu的占用,比如降低gc频率,优化数据结构算法,更高端的还有缩短java 代码路径,选择更合适的指令,用JIT编译器修改jvm
vmstat
r
内存利用
paging 内存换页,将进程中部分做io
swapping 对整个进程做in、out swap发生在内存快要耗尽,与swap区进行swap out到磁盘或swap in进内存
若在
vmstat
memory -- swap -- io
锁竞争
在java 5 hotspot VM 及以后版本把锁的逻辑从依赖操作系统转变成集成到jvm中,如同步方法和同步块的实现由依赖操作系统的锁变成了在用户代码中实现。因此java5之前查看系统锁的方法在之后的版本中不再适用。
由于锁竞争机制是在一个循环中尝试获得锁,若无法获得则停止(parking)线程等待通知,这种等待和唤醒会造成系统的自主上下文切换csw(voluntary context switch),那么如果存在激烈的锁竞争表现出来的是大量的上下文切换,这种上下文切换代价为80000个时钟周期,是代价高昂的操作。
一般来说java程序如果达到了3%-5%的时钟周期消耗在csw那么就算是有很激烈的锁竞争了。如何判断是否达到这个值可以按如下例子简单估算一下:
以3.0GHz的cpu为例,若当前数据
$ pidstat -w -I -p 9391 5
Linux 2.6.24-server (payton) 07/10/2008
08:57:19 AM PID cswch/s nvcswch/s Command
08:57:26 AM 9391 3645 322 java
08:57:31 AM 9391 3512 292 java
08:57:36 AM 9391 3499 310 java
取cswch/s 为3500 双核cpu 每个核为1750cswch/s 1750x80000=140,000,000。
140 000 000/3 000 000 000 = 4.7%
抢占式上下文切换(involuntary context switch)
involuntary context switch 发生在线程耗尽时间片或者被更高优先级线程抢占
pidstat -w
networkI/O的监控
用netstat只能看见包的个数,对于网络传输的数据量是否达到带宽吞吐的极限完全不可知,并且对传输速率也无法看出来。书中推荐使用开源包命令nicstat,solaris已经自带该命令。
大量对小数据的读写调用会消耗大量系统或内核的cpu资源,造成大量的系统调用。在这样的程序中可以减少读写请求,减少网络系统调用。还可以用非阻塞的NIO代替阻塞的socket,这样通过减少对输入请求和输出应答的处理来提升性能。
jdk 中的 NIO 仅是提供了一种赤裸的实验,在用其api时仍然会出现各种使用不当造成的低效率,因此用个nio框架是个不错的选择。
磁盘I/O的利用
iostat -xm 5
提高io利用率:
1.用快速存储
2.磁盘阵列
3.调大cache
在程序层面用buffered input/output降低系统调用,操作系统可以启用磁盘缓存
其他命令行工具
sar
本文介绍了系统监控的主要方面,包括性能监控、性能剖析和性能调整。详细解释了CPU利用率、内存使用情况、锁竞争以及上下文切换等概念,并提供了具体的监控工具和技术建议。
1335

被折叠的 条评论
为什么被折叠?



