一、Windows和Linux操作系统计数器查看方法
1. Windows
点击“计算机”-右键选择“管理”-“性能”-“性能监视器”，点击图中的“+”按钮，打开“添加计数器”窗口。
展开需要添加的项，添加需要监控的子项，点击“添加”按钮，在右边“添加的计数器”界面中就能够看到被监控的子项了。
2. Linux
Linux提供了监控CPU使用率的命令行工具，常用的命令有：vmstat、mpstat、top等，后面讲具体性能指标的时候再详细说明。
二、内存分析
内存计数器包括Memory和Physical Disk, 用于判断系统是否遇到瓶颈，是否需要通过增加内存来提高系统性能表现。
1. 查看MemoryAvailable Mbytes指标: 描述系统可用内存的直接指标，如果该指标数值比较小，说明系统可能出现了内存方面的问题，需要根据后面的步骤进一步分析。
Windows查看:
Linux查看(该内容来自http://jsczxy2.iteye.com/blog/1569263，我家里电脑没有装Linux系统)：
[root@linuxzgf ~]# free -m
total used free shared buffers cached
Mem: 7982 6811 1171 0 350 5114
-/+ buffers/cache: 1346 6636
Swap: 16935 11 16924
2. 查看Pages/sec、Pages Read/sec、Page Faults/sec
windows:
Pages/sec: 是否持续高于几百？该值较大可能是运行使用内存映射文件的程序所致，也可能是内存方面存在问题。
Page Faults/sec: 每秒页面失效次数，该值越大，说明系统向内存中读取的次数越多。
Pages Read/sec: 如果该值超过5，则可以判断存在内存方面的问题。
Linux（图片来源：http://www.cnblogs.com/itech/archive/2011/06/08/2075145.html）:
swap-si: 从磁盘交换来的数量
swap-so: 交换到磁盘中区的数量
3. Physical Disk中的%DiskTime和Average Disk Queue Length查看
windows:
结合前面Pages Read/sec进行分析。
如：Pages Read/sec很低， %DiskTime和Average Disk Queue Length很高，则可能存在磁盘瓶颈。
如：Average Disk Queue Length增加，同时Pages Read/sec没有减少，则是内存不足。
Linux(来源：http://blog.chinaunix.net/uid-22570852-id-3451275.html):
示例:
$ iostat -xtc 5 2
extended disk statistics tty cpu
disk r/s w/s Kr/s Kw/s wait actv svc_t %w %b tin tout us sy wt id
sd0 2.6 3.0 20.7 22.7 0.1 0.2 59.2 6 19 0 84 3 85 11 0
sd1 4.2 1.0 33.5 8.0 0.0 0.2 47.2 2 23
sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
sd3 10.2 1.6 51.4 12.8 0.1 0.3 31.2 3 31
指标说明：
r/s: reads per second
w/s: writes per second
wait: average number of transactions waiting for service (Q length)
actv: average number of transactions actively
%b: percent of time the disk is busy (transactions in progress)
三、处理器分析方法
cpu也可能是系统的瓶颈，下面来看看如何针对CPU进行分析。
1. System\%Total Processor Time
windows: 根据系统版本指标名称和位置可能会有区别
该指标表示服务器整体CPU利用率，对于多处理器系统则为CPU的平均利用率，如果持续超过90%，说明CPU面临瓶颈，可通过增加CPU来提高性能。
在某些系统中，该数据本身并不大，但若CPU之间的负载状况极不均衡，也应该视作系统产生了处理器方面的瓶颈。
Linux（来自：http://www.sijitao.net/2016.html）:
使用top命令，命令执行结果第3行可以看到cpu使用情况。
[root@li676-235 ~]# top -bn 1 -i -c
top - 14:19:51 up 138 days, 7:15, 1 user, load average: 0.20, 0.33, 0.39
Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie
Cpu(s): 4.5%us, 3.8%sy, 0.0%ni, 91.0%id, 0.6%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1014660k total, 880512k used, 134148k free, 264904k buffers
Swap: 262140k total, 34788k used, 227352k free, 217144k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12760 root 20 0 15084 1944 1632 R 2.0 0.2 0:00.01 top -bn 1 -i -c
%us：表示用户空间程序的cpu使用率（没有通过nice调度）
%sy：表示系统空间的cpu使用率，主要是内核程序。
%ni：表示用户空间且通过nice调度过的程序的cpu使用率。
%id：空闲cpu
%wa：cpu运行时在等待io的时间
%hi：cpu处理硬中断的数量
%si：cpu处理软中断的数量
%st：被虚拟机偷走的cpu
2. 每个CPU的Processor\%Processor Time和 Processor\%User Time 和Processor\%Privileged Time
Windows:
Processor\%Processor Time: 该值持续超过95%，表明瓶颈是CPU，可以考虑增加或更换CPU。
Processor\%User Time: 指系统非核心操作消耗的CPU时间，如果该值较大可以考虑通过算法优化方法降低该值。如果是数据库服务器，该值大的原因很数据库的排序或是函数操作消耗了过多的CPU时间，可以考虑对数据库系统进行优化。
Processor\%Privileged Time: CPU内核时间，在特权模式下处理线程执行代码所花时间的百分比。
Linux:
%us(%UserTime): 如果系统中使用了大量的算法或复杂计算操作，该值会比较大。
%id(%Idle Time):如果该值持续低于10%， 表明瓶颈是CPU。
3. 研究系统CPU瓶颈
Windows:
SystemProcessor Queue Length: 该值大于CPU数量的总数加1时，说明产生了CPU阻塞。
Processor\%Processor Time的值很高时一般伴随着CPU阻塞，但产生阻塞时，Processor\%Processor Time并不一定很大，必须查找CPU阻塞的原因。
Processor\%DPC Time: CPU消耗在网络处理上的时间，越低越好。如果访值大于50%且Processor\%Processor值非常高，可以考虑加入一个网卡来提高性能。
Linux（来自http://blog.csdn.net/jacky0922/article/details/6675343）:
%User Time越大一般表明服务器处于运行状态；%System Time越大表明服务器处于系统调用或者I/O操作。如果CPU有大量时间处于空闲状态（%idle),那就说明CPU足够。
我们还可以获得每个时间段上内核切换当前进程的次数，如果这个数很高，表示服务器硬件有问题。
[root@linux stone]sar -w
07:50:00 cswch/s
08:00:00 285.49
08:10:00 259.64
平均负载：系统平均负载被定义为在特定时间间隔内运行队列中的平均进程数，一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题.
[root@linux stone]uptime
18:07:22 up 10days, 8:05, 1user, load average: 0.49, 0.31,1.18
表示在过去的1、5、15分钟内运行队列中的平均进程数量.
[root@linux stone]sar -q
07:50:00 runq-sz plist-sz ldavg-1 ldavg-5
08:00:00 0 214 0.01 0.08
08:10:00 0 222 0.37 0.21
runq-sz:等待运行的进程数
plist-sz：总的进程数（在process list).
ldavg-1 : 系统最后一分钟的平均负载
ldavg-5: 系统最后5分钟的平均负载
每个进程的CPU消耗量：通过了解具体的某个进程对CPU消耗的统计，我们可以确定某一进程是否存在问题，并进行改善（改善该进程？改善硬件？....)
可以用ps -aux或者top来观察某一进程对CPU的消耗情况。另外，vmstat工具也可以报告一些cpu的情况.
[root@linux stone]vmstat
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy idwa
0 0 92456141164 102032 2346524 0 0 7 5 9 5 1 1 6 8
四、磁盘IO分析
1. 计算每磁盘的IO数
对于具体的计算方式我还没有理清楚^_^， RAID? IOPS? 随机IOPS? IO Size？Throughput(MB/s)?Disk Response Time? 有知道欢迎分享出来，谢谢。
这里贴一下RAID5的IO计算方法 = (Reads+4xWrites)/Number of Disks。
2. 与ProcessorPrivileged Time合并进行分析
如果只有Physical\%Disk Time值较大，其他值都适中，则硬盘可能是瓶颈。
若几个值都比较大，且数值持续超过80%，则可能是内存泄漏。
3. 根据Disk sec/Transfer进行分析
一般来说，Transfer数值<15ms为优秀，介于15~30ms之间为良好， 30~60ms之间为可以接受，超过60ms需要考虑更换硬盘或硬盘的RAID方式。
贴一下我自己电脑上监控的情况，等搞清楚再专门写一篇关于磁盘分析的。
五、进程分析方法
windows: Process\%processor time, 如下图所示可以看出哪个进程消耗了最多的处理器时间，双击图中显示的线条，就可以查看进程名称, 然后针对应用进行优化。
2. 查看每个进程产生的页面失效数
windows: processPage Faults/sec, 判断哪个进程产生了最多的失效，该进程要么是需要大量内存的进程，要么是非常活跃的进程，可以对其进行重点分析。
3. 分析进程的ProcessPrivate Bytes
windows: 判断进程中在性能测试过程中有无内存泄漏， 如IIS上的web应用可以重点监控inetinfo进程的Private Bytes.
如果在性能测试过程中，该进程 的Private Bytes计算值不断增加，或是性能测试停止后一段时间，该进程的Private Bytes仍然持续在高水平，则说明应用存在内存泄漏。
六、网络分析
网络分析是一项技术含量很高的工作，一般由专门的网络管理人员来进行，测试工程师如果怀疑是网络引起的性能瓶颈，可请网络人员协助解决。
NetWork InterfaceBytes Total/sec : 发送和接收字节的速率， 可用该计数器的值与目前网络的带宽进行比较，以此判断网络连接是否是瓶颈。
