系统性能指标查看方法-概述

1、CPU使用率

一、大多数的操做系统的CPU使用率分为用户态CPU使用率和系统态CPU使用率。

用户态CPU使用率是指执行应用程序代码的时间占总CPU时间的百分比。

系统态CPU使用率是指应用执行操做系统调用的时间占总CPU时间的百分比。系统态CPU使用率高意味着共享资源有竞争或者I/O设备之间有大量的交互。

既然本来用于执行操做系统内核调用的CPU周期也能够用来执行应用代码，因此理想状况下，应用达到最高性能和扩展性时，它的系统态CPU使用率为0%，因此提升应用性能和扩展性的一个目标是尽量下降系统态CPU使用率。

二、对于计算密集型应用来讲，不只要监控用户态和系统态CPU使用率，还要进一步监控每时钟指令数（Instructions Per Clock，IPC）或每指令时钟周期（Cycles Per Instruction，CPI）等指标。这两个指标对于计算密集型应用来讲很重要，由于现代操做系统自带的CPU使用率监控工具只能报告CPU使用率，而没有CPU执行指令占用CPU时钟周期的百分比，这意味着，即使CPU在等待着内存中的数据，操做系统工具仍然会报告CPU繁忙。这种状况一般被称为停滞。当CPU执行指令所用的操做数据不在寄存器或者缓存中时，就会发生停滞，因为指令执行前必须等待数据从内存中装入CPU寄存器，因此一旦发生停滞，就会浪费时钟周期。CPU停滞一般会等待好几百个时钟周期，所以提升计算密集型应用性能的策略就是减小停滞或者改善CPU高速缓存使用率，从而减小CPU在等待内存数据时浪费的时钟周期

2、CPU调度程序运行队列

一、监控CPU调度程序运行队列对于分辨系统是否满负荷也有重要意义。运行队列中就是那些已准备好运行、正等待可用CPU的轻量级进程。若是准备运行的轻量级进程数超过系统所能处理的上限，运行队列就会很长。运行队列长代表系统负载可能饱和。系统运行队列长度等于虚拟机处理器的个数时，用户不会明显感受到性能降低。此处虚拟处理器的个数就是系统硬件线程的个数，也是Java API Runtime.availableProcessors()的返回值。当运行队列长度达到虚拟处理的4倍或者更多时，系统的响应就很是迟缓了。

二、通常性的指导原则是：若是在很长一段时间里，运行队列的长度一直都超过虚拟处理器个数的1倍，就须要关注了，只是暂时还不须要马上采起行动。若是在很长一段时间里，运行队列长度达到虚拟处理器个数的3~4倍或更高，则须要马上引发注意和采起行动。

三、解决运行队列长有两种方法：一种是增长CPU以分担负载或减小处理器的负载量；另外一种方法是分析系统中运行的应用，改进CPU使用率。研究能够减小应用运行所需CPU周期的方法。Java程序员能够经过更有效的算法和数据结构来实现更好的性能。经过性能分析能够找出哪些算法和数据结构值得关注。

3、内存使用率

一、除了CPU使用率，还须要监控系统内存相关的属性，例如页面调度或页面交换、加锁、线程迁移中德让步式和抢占式上下文切换。

二、系统在进行页面交换或者使用虚拟内存时，Java应用或JVM会表现出明显的性能问题。当应用运行所需的内存超过可用物理内存时，就会发生页面交换。为了应对这种可能出现的状况，一般要为系统配置swap空间。swap空间通常会在一个独立的磁盘分区上。当应用耗尽内存时，操做系统会将应用的一部分置换到磁盘上的swap空间。一般是应用中最少运行的部分，以避免影响整个应用或者应用最忙的那部分。当访问应用中被置换出去的部分时，就必须将它从磁盘置换进内存，而这种置换活动会对应用的响应性和吞吐量形成很大影响。

三、JVM垃圾收集器在系统页面交换时的性能也不好，这是因为垃圾收集器为了回收不可达对象所占用的空间，须要访问大量的内存。若是Java堆得一部分被置换出去，就必须先置换进内存以便垃圾收集器扫描存活对象，这会增长垃圾收集的持续时间。垃圾收集是一种Stop-The-World（时空停滞）操做，即中止全部正在运行的应用线程，若是此时系统正在进行页面交换，则会引发JVM长时间的停顿。

四、若是发现垃圾收集时间变长，系统有可能正在进行也没交换，为了验证这一点，你必须监控系统的页面交换。

4、网络I/O使用率

一、分布式Java应用的性能和扩展性受限于网络带宽或网络I/O的性能。若是发送到系统网络接口硬件的消息量超过了它的处理能力。，消息就会进入操做系统的缓冲区，这会致使应用延迟。此外网络上发生的其余情况也会致使延迟。

二、应用性能改进的考虑，单次读写数据量小而网络读写量大的应用会消耗大量的系统态CPU，产生大量的系统调用。对于这类应用，减小系统态CPU的策略是减小网络读写的系统调用。此外，使用非阻塞的java Nio而不是阻塞的java.net.Socket，减小处理请求和发送响应的线程数，也能够改善应用性能。从非阻塞socket中读取数据的策略是，应用在每次读请求时尽量多的读取数据，一样，当往socket中写数据时，每一个写调用应该尽量多的写。

5、磁盘I/O使用率

一、对于有磁盘操做的应用来讲，查找性能问题，就应该监控磁盘I/O。一些应用的核心功能须要大量使用磁盘，例如数据库，几乎全部的应用都会用日志记录重要的状态信息或者事件发生时的应用行为，磁盘I/O使用率是理解应用磁盘使用状况最有用的监控数据。

二、从应用的角度看，任何减小磁盘活动的策略都有帮助，例如使用带缓存的输入输出流以减小度、写操做次数，或在应用中集成缓存的数据结构以减小或消除磁盘交互。缓冲流减小了调用操做系统调用的次数从而下降系统态CPU使用率，虽然这不会改善磁盘I/O性能，但可使更多CPU周期用于应用的其余部分或者其余运行的应用。JDK提供了缓冲数据结构，也容易使用，如java.io.BufferedInputStream和java.io.BufferedOutputStream。

三、关于磁盘性能，有一个常常被忽略的方法，就是检查磁盘缓存是否开启，有一些系统将磁盘缓存设置为禁用。开启磁盘缓存能够改善严重依赖磁盘I/O的应用的性能。然而，若是发现系统默认设置为禁用磁盘缓存，你应该加以注意，由于一旦开启磁盘缓存，意外的电源故障可能会形成数据损坏。

6、查看指标的方法：

一、Windows：http://www.javashuo.com/article/p-kulxogbv-cq.html

二、Linux：http://www.javashuo.com/article/p-endddgio-bo.html