来自：Java性能权威指南
操作系统的工具和分析-
性能分析的启动是一组操作系统自带的基本监控工具。
无论何时运行性能测试，都应该收集操作系统的数据，至少需要收集CPU、内存和磁盘使用率，使用网络的话，还要收集网络使用率。
cpu使用率
CPU使用率分为两类：用户态时间和系统态时间。用户态时间是CPU执行应用代码所占时间的百分比，而系统太时间则是CPU执行内核代码所占时间的百分比。
系统态时间与应用相关，比如应用执行I/O操作，系统就会执行内核代码从磁盘读取文件，或者将缓存数据发送到网络，等等。任何使用底层系统资源的操作，都会导致应用占用更多的系统态时间。
性能调优的目的是：在尽可能短的时间内让CPU使用率尽可能的高。
检查CPU使用率是弄清楚用应用性能的第一步，但它的用途不仅如此：它可以查看代码的CPU使用是否与预期的一样，或者可以指出一些同步或资源问题。
示例：命令：vmstat 1（每秒输出一行）
每秒内，CPU被占用450毫秒（1秒钟42%的时间执行用户代码，3%的时间执行系统代码）。相应的，CPU空闲550毫秒。CPU空闲有可能有一下原因。
- 应用被同步原语阻塞，直至锁释放才能继续执行。
- 应用在等待某些东西，例如数据库调用所返回的响应。
- 应用的确是无所事事
CPU运行队列
前面vmstat的输出：Unix系统的运行队列长度（vmstat输出示例中的1或2）是所有正在运行或待运行（即一旦有可用CPU就可以运行）线程数。示例中至少有一个线程试图运行：即以单线程执行应用。因此，运行队列长度至少是1.记住，运行队列反应的是机器上所有东西的运行情况，所以示例输出中有时会看到运行队列长度为2，因为此时有其他线程（来自其他完全隔离的进程）试图运行
如果试图运行的线程数超过了可用的CPU,性能就会下降.一般来说,Windows的处理器队列长度最好为0，Unix系统小于或等于CPU的数目。如果在相当长时间内运行队列很长，说明系统已经过载，这时你应该检查系统，减少机器正在处理的工作量（将工作转移到其他机器或者优化代码）
快速小结：1. 检查应用性能时，首先应该审查CPU时间
2. 优化代码的目的是提升而不是降低（更短时间段内的）CPU使用率
3. 在试图摄入优化应用前，应该先弄清楚为何CPU使用率低
磁盘使用率
监控磁盘使用率有两个目的：**第一个目的：**与应用本身有关：如果应用正在做大量的磁盘I/O操作，那I/O就容易成为瓶颈
rrqm/s: 每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并
wrqm/s: 每秒对该设备的写请求被合并次数
r/s: 每秒完成的读次数
w/s: 每秒完成的写次数
rkB/s: 每秒读数据量(kB为单位)
wkB/s: 每秒写数据量(kB为单位)
avgrq-sz:平均每次IO操作的数据量(扇区数为单位)
avgqu-sz: 平均等待处理的IO请求队列长度
await: 平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)
svctm: 平均每次IO请求的处理时间(毫秒为单位)
%util: 采用周期内用于IO操作的时间比率，即IO队列非空的时间比率
重点关注参数
1、iowait% 表示CPU等待IO时间占整个CPU周期的百分比，如果iowait值超过50%，或者明显大于%system、%user以及%idle，表示IO可能存在问题。
2、avgqu-sz 表示磁盘IO队列长度，即IO等待个数。
3、await 表示每次IO请求等待时间，包括等待时间和处理时间
4、svctm 表示每次IO请求处理的时间
5、%util 表示磁盘忙碌情况，一般该值超过80%表示该磁盘可能处于繁忙状态。
应用正在往sda写数据。w_await——每次I/O写的时间——相当滴，磁盘使用率只有1.04%。（5200RPM的磁盘可以很好的支持15毫秒）这里有条线索可以看出点问题：系统在内核花费了37.89%的时间。一种可能是系统正在进行其他I/O（其他程序中）。如果这个系统时间都来自被测的应用，说明某些低效率的事正在发生。
另一条线索是，系统每秒写为24.2：当每秒写入只有0.14MB时，这算很大的数字。这说明I/O已经是瓶颈，接下来应该检查应用是如何写的。
如果磁盘速度赶不上I/O请求，问题的另外一面就出现了：
Linux好处在于可以立即高速我们磁盘的使用率为100%。它也能告诉我们进城的47.89%的事件在iowait（表示正在等待磁盘）。
第二目的即便预计应用不会有很高的I/O——有助于监控系统是否在进行内存交换。
快速小结：1. 对于所有应用来说，监控磁盘使用率非常重要。即便不直接写磁盘的引用，系统交换仍然会影响他们的性能。
2. 写入磁盘的应用遇到瓶颈，是因为写入数据的效率不高（吞吐量太低），或者是因为写入太多数据（吞吐量太高）。