Linux 服务器性能出问题，排查下这些参数指标

11 top

12 vmstat

r 表示可运行进程数目，数据大致相符；而b表示的是 uninterruptible 睡眠的进程数目；swpd 表示使用到的虚拟内存数量，跟 top-Swap-used 的数值是一个含义，而如手册所说，通常情况下 buffers 数目要比 cached Mem 小的多，buffers 一般20M这么个数量级；io 域的 bi、bo 表明每秒钟向磁盘接收和发送的块数目(blocks/s)；system 域的 in 表明每秒钟的系统中断数(包括时钟中断)，cs表明因为进程切换导致上下文切换的数目。

说到这里，想到以前很多人纠结编译 linux kernel 的时候 -j 参数究竟是 CPU Core 还是 CPU Core+1？通过上面修改 -j 参数值编译 boost 和 linux kernel 的同时开启 vmstat 监控，发现两种情况下 context switch 基本没有变化，且也只有显著增加 -j 值后 context switch 才会有显著的增加，看来不必过于纠结这个参数了，虽然具体编译时间长度我还没有测试。资料说如果不是在系统启动或者 benchmark 的状态，参数 context switch>100000 程序肯定有问题。

13 pidstat

如果想对某个进程进行全面具体的追踪，没有什么比 pidstat 更合适的了——栈空间、缺页情况、主被动切换等信息尽收眼底。这个命令最有用的参数是-t，可以将进程中各个线程的详细信息罗列出来。

-r： 显示缺页错误和内存使用状况，缺页错误是程序需要访问映射在虚拟内存空间中但是还尚未被加载到物理内存中的一个分页，缺页错误两个主要类型是

-s：栈使用状况，包括 StkSize 为线程保留的栈空间，以及 StkRef 实际使用的栈空间。使用ulimit -s发现CentOS 6x上面默认栈空间是10240K，而 CentOS 7x、Ubuntu系列默认栈空间大小为8196K

14 其他

while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'; sleep 1; done

21 iostat

31 netstat

➜ ~ netstat -antp #列出所有TCP的连接

➜ ~ netstat -nltp #列出本地所有TCP侦听套接字，不要加-a参数

32 sar

33 tcpdump

一、硬盘类型。服务器中的固态硬盘(SSD)比SATA硬盘驱动器提供更高的磁盘读/写速度，也称为输入/输出(I/O)性能。具有SSD读取和写入磁盘的服务器速度更快，但定价显著高于同等存储容量的SATA硬盘。

二、硬盘存储空间。服务器的硬盘存储是本地数据库大小和文件(如图像)的本地存储的限制因素。配置RAID磁盘阵列可有效增加数据可靠性，增加读取/写入(I/O)性能，RAID需要两个以上单独的存储卷。存储还可以采取网络存储的形式，如NAS(网络连接存储)或SAN(存储区域网络)。

三、CPU。独立服务器的CPU执行诸如服务网页、运行数据库查询或处理计算命令等指令。CPU和内核的数量会影响可执行多少个并发指令。CPU架构和功能也影响执行指令的速度，特别是在围绕这些功能设计程序的网站或应用。

四、带宽。带宽数据传输限制，指的是可以并发到您的服务器的数据量。服务器带宽价格较高，通常提供5Mbps、10Mbps国际带宽。像并发视频流、游戏和大数据处理等工作任务都需要高带宽。

五、网络延迟。网络延迟是服务器和用户之间发送信息的延迟的毫秒。网络延迟的高低由服务器提供商决定，但受到服务器和用户之间的距离和网络质量的影响。为降低延迟，服务器供应商部署中国大陆连通香港地区的CN2专线，是目前中国大陆访问最快的线路，可提供最低的延迟和最好的网络体验。

负载(load)是linux机器的一个重要指标，直观了反应了机器当前的状态。
来看下负载的定义是怎样的：
In UNIX computing, the system load is a measure of the amount of computational work that a computer system performs The load average represents the average system load over a period of time It conventionally appears in the form of three numbers which represent the system load during the last one-, five-, and fifteen-minute periods（wikipedia）
Unix refers to this as the run-queue length: the sum of the number of processes that are currently running plus the number that are waiting (queued) to run

Free memory is the amount of memory which is currently not used for anything This number should be small, because memory which is not used is simply wasted
Available memory is the amount of memory which is available for allocation to a new process or to existing processes。

df
查看磁盘使用情况，通常看磁盘大小和inode使用率：
磁盘性能分析
r/s 和 w/s：每秒磁盘读写的次数。这两个值相加就是 tps。
rkB/s 和 wkB/s：每秒磁盘读写的数据量。
avgrq-sz：平均每次读写磁盘扇区的大小。
avgqu-sze：平均 IO 队列长度。队列长度越短越好。
await：平均每次磁盘读写的等待时间（ms）。
svctm：平均每次磁盘读写的服务时间（ms）。
%util：一秒钟有百分之多少的时间用于磁盘读写 *** 作。

1）%util：衡量 IO 的繁忙程度
这个值越大，说明产生的 IO 请求较多，IO 压力较大，
我们可以结合 %idle 参数来看，如果 %idle < 70% 就说明 IO 比较繁忙了。
2）await：衡量 IO 的响应速度
通俗理解，await 就像我们去医院看病排队等待的时间，
这个值和医生的服务速度（svctm）和你前面排队的人数（avgqu-size）有关。
如果 svctm 和 await 接近，说明磁盘 IO 响应时间较快，排队较少，
如果 await 远大于 svctm，说明此时队列太长，响应较慢，
这时可以考虑换性能更好的磁盘。

带宽：表示链路的最大传输速率，单位通常为 b/s （比特 / 秒）
延时：表示从网络请求发出后，一直到收到远端响应，所需要的时间延迟
在不同场景中，这一指标可能会有不同含义
比如，它可以表示，建立连接需要的时间（比如 TCP握手延时）
或一个数据包往返所需的时间（比如 RTT）
PPS：是 Packet Per Second（包 / 秒）的缩写，表示以网络包为单位的传输速率�丢包率：丢包百分比
重传率：重新传输的网络包比例
连接数状态：TCP 各状态连接数量
TIME_WAIT状态存在有两个原因。
第一个是防止来自一个连接的延迟段被误解为后续连接的一部分。
连接处于2MSL等待状态时到达的所有流量都将被丢弃。
该TIME_WAIT状态的第二个原因是
可靠地实现TCP的全双工连接终止。
如果最后的ACK被丢弃，那么端点2将重新发送最后的FIN

单机最大连接数理论限制

系统用一个4四元组来唯一标识一个TCP连接： �{local ip, local port, remote ip, remote port}。 �
因此本地端口个数最大只有65536，端口0有特殊含义，不能使用，
这样可用端口最多只有65535，

所以在全部作为client端的情况下，
最大tcp连接数为65535，这些连接可以连到不同的server ip

1、系统最大打开文件数
sysfsfilesmax //系统最大文件句柄数
/proc/sys/fs/file-max

2、单进程最大文件描述符
echo 2000000 > /proc/sys/fs/nr_open
sysctl -w fsnr_open=100000000

3、某个用户下的某个进程的文件打开数
ulimit –n [num]
ulimit -n unlimited

/etc/security/limitsconf
worker soft nofile 102400
worker hard nofile 409600

linux内核通过进程标识值(process identification value)-PID来标示进程，
PID是一个数，类型位pid_t, 实际上就是int类型

查看
可以使用cat /proc/sys/kernel/pid_max来查看系统中可创建的进程数实际值
修改
1、ulimit -u 65535
2、我们在Linux还需要设置内核参数kernelpid_maxsysctl -w kernelpid_max=65535

Windows服务器中自带的性能监控工具叫做Performance Monitor；

在开始-运行中输入‘perfmon’，然后回车即可运行。

Monitor本身也是一个进程，运行起来也要占用一定的系统资源。所以你看到的资源的使用量应该比实际的要稍微高一点。这个工具在帮助管理员判断系统性能瓶颈时非常有用；

举个列子来说，今天有个用户抱怨说他们项目组的服务器（这是一台虚拟机）运行起来非常慢，但也不知道具体问题出在什么地方。任务管理器里显示CPU和内存的使用量都不算高，但服务器的相应就是非常慢；

Monitor，让其运行一段时间后（因为参考平均值会比较准确），发现average disk queue的值比较高，这就说明物理服务器的硬盘负荷太重，I/O *** 作的速度跟不上系统的要求。关掉虚拟机，将其转移到另一台硬盘负载比较小的主机上，再打开虚拟机。

分析性能情况

1、内存泄露判断

虚拟内存字节数（VirtualBytes）应该远大于工作集字节数（Workingset），如果两者变化规律相反，比如说工作集增长较快，虚拟内存增长较少，则可能说明出现了内存泄露的情况。

对于Workingset、Private Bytes、Available bytes这些计数器，如果在测试期间内数值持续增长，而且测试停止后位置在高水平，则也说明存在内存泄露。

Windows资源监控中，如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Available

bytes计数器的值持续降低，则很可能存在内存泄漏。

2、CPU使用情况

一般平均不要超过70%，最大不要超过90%（好：70% 、坏：85%、 很差：90%）。

3、tps（每秒处理事务的数量，在SOAPUI中进行统计）

一般在10-100，不同应用程序具体值不同。

，仅完成安装系统、应用程序并上架后便拍拍屁股离开，远不能发挥服务器性能。服务器需要通过周期性的监控来确保硬件投资得到了预期回报--并对潜在问题提出告警，比如资源不足或硬件故障。性能监控工具可以提供大量的可用信息，但需要确保工具被正确安装与运行。本文将介绍可以帮助管理员们从系统性能监控中获得最大利益的技巧。
实现精确的性能监控
如果采集的信息存在错误，监控便毫无用处，所以确保数据的准确性是你得采取的第一步。准确性包括许多方面，如互通性、采样窗口、工具架构、虚拟化感知与校准。
互通性。在此讨论中，互通性是性能监控工具的基本功能，能够从数据中心内各种硬件与部件中访问与读取数据源。在部署了同一厂商产品线设备的同质环境内，利用集成在硬件中的内置挂钩，监控工具可以发挥极大优势。通过这些挂钩，工具可以抓取设备的详细运行信息。
在异质环境下，监控则成为了另外一种挑战，因为工具与硬件可能无法很好匹配。产商提供的工具可能可以提供一些硬件部件的特殊信息，而其他工具可能无法保障一致性。第三方性能监控工具可能无法检测每个监控器或硬件的细微差别，它们更依赖于 *** 作系统级的数据，而这些数据通常缺乏足够的颗粒度。在某些情况下，监控数据可能丢失或失真，从而降低系统性能监控的可用性。
工具与硬件之前的数据差异需要全面测试。例如，在购买工具之前，先测试并验证兼容性，在经过较长时间的可用性验证项目后，再开始将工具由测试环境部署至生产环境中。但问题同样从开始购买延伸至未来产品升级或技术刷新周期。当你更换硬件或升级工具，你需要测试监控工具的互通性来确保性能监控工具依旧可以正常工作并提供准确数据。
采样。准确性同样依赖于收集数据用的采样窗口。当负载与运行参数可能一直处于波动状态时，数据准确性将十分重要。理想情况下，性能监控工具可以捕捉整台服务器的运行周期。技巧在于决定运行周期是怎样的。这依赖于每个负载与宿主主机是如何被使用的。例如，每台服务器的内存性能可能需要极快的采样率，而采样窗口需要跨越好几分钟。与此相反，观察某个合作HR系统的CPU使用情况可能需要已较低的频率捕捉数值，但采样窗口周期需要长达30天甚至更长。如何正确采样并没有标准答案，不同属性的 *** 作系统同样需要通过不同的比率与窗口灵活定义。
工具架构。性能监控工具通常需要在受监控系统上安装代理或额外驱动(即使是虚拟机)。代理具有优势也有不足。首先，它们十分有用，因为代理可以收集并传输许多重要信息，比无代理的监控工具提供更多监控参数。尽管如此，代理通常被作为软件客户端，将所有数据报告给中央服务器，中央服务器将收集与处理这些数据。所以每个代理都需要占用一定的计算资源，这可能在一定程度上影响整台服务器的负载性能。
我所在环境下所有计算机拥有两个代理， Chris Steffen，Kroll Factual Data的首席技术架构师说。一个应用程序代理监控我们所有应用程序的健康状况，而且我们还有System Center [Virtual Machine Manager]代理安装在所有虚拟机宿主上。
这些年来，关于代理的负面影响一直在降低，但它们所产生的影响一直在被评估，尤其在执行关键任务或对性能要求十分苛刻的负载上。不仅如此，Steffen同样表示，新兴的监控工具可以提供更多功能，包括自动化安装，重装或维护运行环境中的代理。
虚拟化感知。
虚拟化软件把应用负载从硬件中抽象化。当传统性能监控工具试图在虚拟化环境中报告，抽象层常常发生错误结果，因为老工具是同直接监控硬件，而不是通过控制计算资源的hypervisor。考虑到虚拟化技术的人气和重要性，管理员应该选择能监控虚拟化的监控工具。这样能让性能监控同时管到物理目标和虚拟目标，管理员可以才可以收集到精确的数据。
管理员们有时候还需要采集虚拟机与承载虚拟机的宿主服务器指标，Kleyman说。这种情况下，需要在虚拟化与物理层级别进行性能监控以确保最佳负载性能并保障用户体验。
传感器校准。需要忽视传感器本身的重要性。来自网络交换机或服务器的数字信信号常都是十分准确的。但是某些传感器，例如温度，湿度，空气流或其他环境类型的传感器通常是通过模拟信号传输，可能需要经常校对并定期更换电池来保证其长期稳定的工作。
最大化性能监控工具价值
如果没有正确使用，工具是无法产生价值的。在许许多多的案例中，性能监控工具已经被部署，但是没有清晰的规划来使用与分析所收集到的海量数据。工具则变成了管理员们用来抽查或不定期故障处理的简单工具;这是一种投资浪费。
性能监控工具报告同样可以作为能力规划的基础参考，或协助完成技术刷新项目。性能指标可以帮助展示RIO[投资回报率],Kleyman说。通过了解旧系统性能，并比对新款服务器性能，我们可以决定是否将钱投资在新设备上已提升计算性能并获得更长远的利益。
但Steffen同样建议用户多留个心眼，秉着信任，但要核查的态度来对待性能监控工具，有可能某些服务器监控工具已经被验证，与其他工具相比可以获得十分准确的数值，但如果用来监控网络设备则可能出现一些异常。好的业务决策需要有优质的数据进行支撑，而且若工具无法提供准确、可验证的结果，那样将很难给业务决策提供有力支持。
lg=t

Windows服务器中自带的性能监控工具叫做Performance Monitor；

在开始-运行中输入‘perfmon’，然后回车即可运行。

Monitor本身也是一个进程，运行起来也要占用一定的系统资源。所以你看到的资源的使用量应该比实际的要稍微高一点。这个工具在帮助管理员判断系统性能瓶颈时非常有用；

举个列子来说，今天有个用户抱怨说他们项目组的服务器（这是一台虚拟机）运行起来非常慢，但也不知道具体问题出在什么地方。任务管理器里显示CPU和内存的使用量都不算高，但服务器的相应就是非常慢；

Monitor，让其运行一段时间后（因为参考平均值会比较准确），发现average disk queue的值比较高，这就说明物理服务器的硬盘负荷太重，I/O *** 作的速度跟不上系统的要求。关掉虚拟机，将其转移到另一台硬盘负载比较小的主机上，再打开虚拟机。

分析性能情况

1、内存泄露判断

虚拟内存字节数（VirtualBytes）应该远大于工作集字节数（Workingset），如果两者变化规律相反，比如说工作集增长较快，虚拟内存增长较少，则可能说明出现了内存泄露的情况。

对于Workingset、Private Bytes、Available bytes这些计数器，如果在测试期间内数值持续增长，而且测试停止后位置在高水平，则也说明存在内存泄露。

Windows资源监控中，如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Available

bytes计数器的值持续降低，则很可能存在内存泄漏。

2、CPU使用情况

一般平均不要超过70%，最大不要超过90%（好：70% 、坏：85%、 很差：90%）。

3、tps（每秒处理事务的数量，在SOAPUI中进行统计）

一般在10-100，不同应用程序具体值不同。

1 处理器对象(Processor Object)

一条经验规则是不要使你所监控的每个处理器的C P U使用率高于9 0％。峰值超过9 0％是可以接受的，但平均使用率超过9 0％则是应该避免的。

• 处理器时间百分比(％Processor Time) 处理器执行一个非空闲线程的时间百分比。用％1 0 0减去处理器空闲的总时间得出这个值。这是整个系统的C P U使用的一个好的指示器。

• 特权时间百分比(％Privileged Time) 处理器用于在特权模式下(即，执行 *** 作系统功能和运行驱动器，如I / O )工作时间的百分比。这个时间包括C P U (或C P U )用于维护中断和延迟过程调用( D P C )的时间。

• 用户时间百分比(％User Time) 处理器用于在用户模式工作的时间百分比。这种类型的工作是由应用产生的。通常，希望极大化用户时间百分比的值，极小化特权时间百分比的值。

• 中断时间百分比(％Interrupt Time) CPU忙于维护硬件中断的时间百分比。系统中的许多硬件部件，如鼠标、网络接口卡或磁盘控制器，都可以发出处理器中断。你可以将中断看作为Windows NT正常 *** 作的一部分发生。

• 中断数/秒(Interrupts/sec) 处理器每秒接收并处理的硬件中断的数量。它不包括系统

D P C，系统D P C单独计数。

2 系统对象(System Object)

系统对象与它的相关计数器衡量处理器上运行的线程的总计数据。虽然使用这些计数器不能观察一个特定处理器的工作负载或一个特定线程的行为，但它们提供了有关整个系统性能有价值的内部信息。系统计数器如下所示：

• 处理器队列长度(Processor Queue Length) 处理器队列中的线程的数量。换句话说，它

是等待运行的线程数。即使你的系统具有多个处理器，但只有一个队列用于处理器时间。计数器只记录那些准备执行但仍处于等待的线程，不是那些正在运行的线程。

• 环境切换/秒(Context Switches/sec) 系统上的所有处理器从一个线程切换到另一个线程的组合比率。当一个正在运行的线程自动地放弃处理器，处理器由一个高优先级的待命线程抢占时发生环境切换，或在用户模式和特权(核心)模式之间切换，以使用一个执行或子系统的服务。这是线程的总和：计算机上运行在所有处理器上的所有线程的环境切换数/秒。

3 SQL Server：缓冲区管理器对象( B u ffer Manager Object)

缓冲区管理器计数器提供了SQL Server使用的内存缓冲区的有关信息。这些计数器如下所示：

• 高速缓存命中率( B u ffer Cache Hit Ratio) 引用当前位于高速缓存中页的需求的百分率。预先在内存中拥有页，允许SQL Server避免请求从磁盘子系统执行一次物理I / O。因为访问内存相对于访问物理I / O，代价更小，一个高的缓冲区高速缓存命中率增强了系统的性能与吞吐量。如果你的系统很好地调整过，这个命中率应该是8 0％或更高。如果具有一个低的缓冲区高速缓存命中率，你应该为SQL Server分配更多的内存。如果你已将现有的所有内存都分配给了SQL Server，那么需要增加系统中物理内存的数量。

• 高速缓存大小(页)(Cache Size) 在SQL Server缓冲区高速缓存中的页的数量。这个数量乘以8 K B，即可得到正在使用的以千字节为单位的缓存数。

• 空闲缓冲区(Free Buffer) 空闲SQL Server内存缓冲区的数量。

• 读的页/秒(Page Reads/sec) 每秒请求的物理数据页I / O的数量。

• 偷取的页计数(Stolen Page Count) SQL Server用于缓冲区高速缓存的页数，这些内存被给予系统中的另外一个进程。Windows NT回收这个内存以满足其他系统部件的需要。

• 写的页/秒(Page Writes/sec) 由SQL Server执行的每秒写的物理数据页的数量。

4 SQL Server：数据库对象(Database Object)

数据库对象计数器提供了有关SQL Server数据库的信息，包括可用的空闲日志空间量和数据库中活动事务的数量。对于系统中的每个数据库的每个计数器有一个实例。这些计数器包括如下：

• 日志刷新等待/秒(Log Flush Wait/sec) 在能够继续执行前，必须等待日志刷新的数据库提交数量。

• 日志使用的百分比(Percent Log Used) SQL Server实际使用的当前定义的日志空间的百分比。

5 SQL Server：常规统计对象(General Statistics Object)

常规统计对象含有常规服务器范围活动的有关信息，它有一个计数器：

• 用户连接数(User Connections) 系统中用户连接的当前数量。

6 SQL Server：闩对象(Latches Object)

这个对象计数器提供了在内部SQL Server资源中有效的闩的信息。计数器如下：

• 平均闩等待时间(毫秒) ( Average Latch Wait Time) 闩请求在得到服务之前必须等待的平均时间，以毫秒为单位。

• 闩等待数/秒(Latch Waits/sec) 不能立即服务，被迫等待其他资源释放的闩请求的数量。

7 SQL Server：锁对象(Locks Object)

锁对象提供了由SQL Server提出的各个锁请求的有关数据，例如锁生命周期和死锁。可以在系统上具有多个这些计数器的实例。计数器如下所示：

• 平均等待时间(毫秒) ( Average Wait Time) 每个锁请求被迫等待的平均时间量，以毫秒为单位。

• 锁到期数/秒(Lock Timeouts/sec) 在系统中过期的锁请求的数量。

• 锁等待数/秒(Lock Wa i t s / s e c )不能立即满足，需要调用线程在给予锁之前处于等待状态的锁请求的数量。

• 死锁数/秒(Number of Deadlocks/sec) 导致产生死锁的锁请求的数量。

8 SQL Server：内存管理器对象(Memory Manager Object)

内存管理器对象含有有关SQL Server内存使用的信息，包括SQL Server正在使用的高速缓

存内存的数量。这个对象下的计数器如下所示：

• 内存授权挂起(Memory Grants Pending) 等待授予工作空间内存的进程的当前数量。

• S Q L高速缓存内存(KB)(SQL Cache Memory) SQL Server用于动态SQL 高速缓存的动态

内存数量。

• 目标服务器内存( K B ) ( Ta rget Server Memory) SQL Server将会消耗的动态内存的总额。

• 总的服务器内存( K B ) ( Total Server Memory) SQL Server当前消耗的动态内存的总额。

9 SQL Server：S Q L统计对象(SQL Statistics Object)

这个对象提供了系统上正在执行的S Q L查询的有关信息，包括查询编译和重新编译的数量的数据。它有如下计数器：

• 批请求/秒(Batch Requests/sec) 服务器接收到的S Q L批请求的数量。

• SQL 编译/秒(SQL Compilations/sec) SQL Server每秒执行的S Q L语句编译的数量。

• S Q L重新编译/秒(SQL Re-Compilations/sec) SQL Server每秒执行的S Q L语句重新编译的数量。

10 逻辑磁盘对象(Logical Disk Object)

逻辑磁盘对象提供了有关逻辑磁盘I / O性能的信息。逻辑磁盘计数器与Windows NT磁盘

系统管理员分配给逻辑磁盘驱动器的字母相关。这个对象含有如下计数器：

• 磁盘读时间百分比(％Disk Read Time) 选中的逻辑磁盘忙于服务读请求总共用去时间的

百分比。

• 磁盘写时间百分比(％Disk Write Time) 选中的逻辑磁盘忙于服务写请求总共用去时间

的百分比。

• 磁盘时间百分比(％Disk Time) 选中的逻辑磁盘忙于服务读请求或写请求总共用的时间

的百分比，是磁盘写时间百分比与磁盘读时间百分比的和。

• 空闲时间百分比(％Idle Time) 逻辑磁盘在采样时间间隔中处于空闲状态的时间百分比。

• 平均磁盘队列长度( Avg Disk Queue Length) 在采样的时间间隔中，选中的逻辑磁盘读请求和写请求排队的平均数量。

• 平均磁盘读队列长度( Avg Disk Read Queue Length) 在采样的时间间隔中，对选中的逻辑磁盘读请求排队的平均数量。

• 平均磁盘写队列长度( Avg Disk Write Queue Length) 在采样的时间间隔中，对选中的逻辑磁盘写请求排队的平均数量。

• 平均磁盘秒数/读( Avg Disk sec/Read) 从逻辑磁盘读数据的平均时间，以秒为单位。

• 平均磁盘秒数/写( Avg Disk sec/Write) 向逻辑磁盘写数据的平均时间，以秒为单位。

• 平均磁盘秒数/传输( ( Avg Disk sec/Transfer) 从逻辑磁盘进行传输的平均时间，以秒为单位。

• 磁盘读/秒(Disk Reads Bytes/sec) 逻辑磁盘上每秒读字节。

• 磁盘读/秒(Disk Writes Bytes/sec) 逻辑磁盘上每秒写字节。

• 磁盘读/秒(Disk Reads/sec) 逻辑磁盘上的读 *** 作比率。

• 磁盘写/秒(Disk Writes/sec) 逻辑磁盘上的写 *** 作比率。

• 磁盘传输/秒(Disk Transfers/sec) 逻辑磁盘上的读和写 *** 作的比率。

11 物理磁盘对象(PhysicalDisk Object)

物理磁盘对象提供了有关物理磁盘I / O性能的信息。它的磁盘计数器与系统中的物理驱动器有关，并且只有当运行了D i s k P e r f服务时，它才被激活。这个对象下的计数器如下所示：

• 磁盘读时间百分比(％Disk Read Time) 选中的物理磁盘忙于服务读请求总共用的时间的百分比。

• 磁盘写时间百分比(％Disk Write Time) 选中的物理磁盘忙于服务写请求总共用的时间的百分比。

• 磁盘时间百分比(％Disk Time) 选中的物理磁盘忙于服务读请求或写请求总共用的时间的百分比，是磁盘写时间百分比与磁盘读时间百分比的和。

• 空闲时间百分比(％Idle Time) 物理磁盘在采样时间间隔中处于空闲状态的时间百分比。

• 平均磁盘队列长度( Avg Disk Queue Length) 在采样的时间间隔中，选中的物理磁盘读请求和写请求排队的平均数量。

• 平均磁盘读队列长度( Avg Disk Read Queue Length) 在采样的时间间隔中，选中的物理磁盘读请求排队的平均数量。

• 平均磁盘写队列长度( Avg Disk Write Queue Length) 在采样的时间间隔中，选中的物理磁盘写请求排队的平均数量。

• 平均磁盘秒数/读( Avg Disk sec/Read) 从物理磁盘读数据的平均时间，以秒为单位。

• 平均磁盘秒数/写( Avg Disk sec/Write) 向物理磁盘写数据的平均时间，以秒为单位。

• 平均磁盘秒数/传输( Avg Disk sec/Transfer) 从物理磁盘进行传输的平均时间，以秒为单位。

• 磁盘读/秒(Disk Reads Bytes/sec) 物理磁盘上每秒读字节。

• 磁盘读/秒(Disk Writes Bytes/sec) 物理磁盘上每秒写字节。

• 磁盘读/秒(Disk Reads/sec) 物理磁盘上的读 *** 作比率。

• 磁盘写/秒(Disk Writes/sec) 物理磁盘上的写 *** 作比率。

• 磁盘传输/秒(Disk Transfers/sec) 物理磁盘上的读和写 *** 作的比率。

12 内存

内存在任何系统中都是一个非常有价值的资源。Windows NT不只允许过量使用内存，而且鼓励你过量使用内存。Windows NT提供了一种透明机制，允许应用“相信”它们具有比系统中可用的物理内存更多的内存。当Windows NT处理应用时，它将不使用的内存页调出(交换出)到磁盘上的页文件中。在大多数系统中，页调度是正常的，但过量的页调度会削弱整个系统的性能。下面的计数器允许你监控系统的页调度。

• 失效的页/秒(Page Faults/sec) 每秒由处理器处理的失效页的全部数量。当一个进程需

要的代码或数据不在它的工作区(它的空间在物理内存中)中时，发生失效页。这个计数

器包括硬的页失效(那些需要磁盘访问的)和软的页失效(在物理内存的其他地方发现了失

效页)。

• 读的页/秒(Page Reads/sec) 读取磁盘以解决硬的页失效所需要的时间数(当一个进程需要的代码或数据不在其工作区或内存中的其他地方，必须从磁盘提取这些代码和数据时，发生硬的页失效)。这个计数器包括为满足在文件系统高速缓存(通常是应用请求的)以及在非高速缓存映像内存文件中的失效而进行的读。

• 写的页/秒(Page Writes/sec) 将页写向磁盘以释放物理内存空间的时间数。只有当页在物理内存中被改变的时候，将页写入磁盘，这样，它们更有可能含有数据，而不是代码。

• 页/秒(Pages/sec) 为解决硬的页失效，所需要读或写磁盘的时间数。它是读的页/秒与写的页/秒的计数器的和。

当前业界常见的服务器性能指标有:
TPC-C
TPC-E
TPC-H
SPECjbb2005
SPECjEnterprise2010
SPECint2006 及 SPECint_rate_2006
SPECfp2006 及 SPECfp_rate_2006
SAP SD 2-Tier
LINPACK
RPE2
一、TPC (Transaction Processing Performance Council) 即联机交易处理性能协会, 成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标: 为业界提供可信的数据库及交易处理基准测试结果,当前发 布主要基准测试为:
TPC-C : 数据库在线查询(OLTP)交易性能
TPC-E : 数据库在线查询(OLTP)交易性能
TPC-H : 商业智能 / 数据仓库 / 在线分析(OLAP)交易性能
1TPC-C测试内容：数据库事务处理测试, 模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现 正规 TPC-C 测试结果发布必须提供 tpmC值, 即每分钟完成多少笔 TPC-C 数据库交易 (TPC-C Transaction Per Minute), 同时要提供性价比$/tpmC。如果把 TPC-C 测试结果写成为 tpm, TPM, TPMC, TPCC 均不属正规。
2TPC-E测试内容：数据库事务处理测试，模拟一个证券交易系统。与TPC-C一样，实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现。正规TPC-E测试结果必须提供tpsE值，即每秒钟完成多少笔TPC-E数据库交易（transaction per second），同时提供$/tpsE。测试结果写成其他形式均不属正规。
对比：TPC-E测试较TPC-C测试，在测试模型搭建上增加了应用服务器层，同时增加了数据库结构的复杂性,测试成本相对降低。截止目前，TPC-E的测试结果仅公布有50种左右，且测试环境均为PC服务器和windows *** 作系统，并无power服务器的测试结果。除此之外，TPC官方组织并未声明TPC-E取代TPC-C，所以，说TPC-E取代TPC-C并没有根据。

---