www.hj8828.com 1

【www.hj8828.com】windows性能监视器(转)

有没有可能在短短几秒内回答这个问题?也许你试图查看性能监视器PerfMon里面的性能计数器。里面有大约1000个名称各异的不同计数器。你可能会问:“Skipped
Ghosted Records/sec”每秒跳过的幻影记录数)=
10,这个数值好还是坏?正确的回答是,这个数值可能并不重要。不过,有些计数器确实很重要。本文将帮助你找出这类计数器,还会教你如何为最常见的性能问题排除故障。

Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁,说明内存不足。“页交换”是使用称为“页面”的单位,将固定大小的代码和数据块从 RAM
移动到磁盘的过程,其目的是为了释放内存空间。尽管某些页交换使
Windows
2000 能够使用比实际更多的内存,也是可以接受的,但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况,请从以下的对象计数器开始:

   
最近公司为客户新上线了一个系统,主要做为日常办公之用。试用两天后,客户反映系统速度很慢,主要表现为首页面加载速度慢。下图为首页概况:

想开始入手,先从下列网址安装SQL Heartbeat工具:

连接到你的服务器后,你会看到服务器树结构中的两个类别:

Available Mbytes:可用物理内存数.
如果Available
Mbytes的值很小(4 MB
或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。

www.hj8828.com 1
 

www.hj8828.com 2

pages/sec: 表明由于硬件页面错误而从磁盘取出的页面数,或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百,那么您应该进一步研究页交换活动。有可能需要增加内存,以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。Pages/sec 的值很大不一定表明内存有问题,而可能是运行使用内存映射文件的程序所致。

     
这是一个老日常办公系统的增强版,所以页面虽然是新的,但页面与数据大部份都是旧的。首页只是个大框架,然后把原系统的各个部份做成单独的页面放入进来。其中菜单部份用iframe套了老系统的菜单,任务列表通过访问原系统的web
services获取数据,工作区是个tab页,第一个tab页是一些信息公告,用了近十个iframe来套老系统的页面。

点击“Online Activity/SQL
Heartbeat”节点,你会立即看到五个不同的图表。但是最好点击“Historical
Data”历史数据),等待一两天,等到累积了更准确的衡量指标为止。之后,你该查看图表上的哪些内容呢?首先,你应该关注一下Waits图表:

page read/sec:页的硬故障,page/sec的子集,为了解析对内存的引用,必须读取页文件的次数。阈值为>5.
越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间,因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此,在研究内存不足不太明显的页交换的原因时,您必须跟踪如下的磁盘使用情况计数器和内存计数器:

     
我们系统大量采用了ajax,在页面还没有加载出来的时候,其空白处就显示:”加载中…”
。客户反映,主要是ie6用户,有时候首页上满页面都是加载中…要等近10秒才能显示出来。

www.hj8828.com 3

Physical Disk” % Disk Time
Physical Disk” Avg.Disk Queue Length
例如,包括
Page
Reads/sec 和
% Disk
Time 及 Avg.Disk
Queue Length。如果页面读取操作速率很低,同时 % Disk
Time 和 Avg.Disk
Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。

     
我的第一个返映就是:是不是因为ie6的js引擎效率低导致的,通过用httpwatch观查,发现其更重要的原因是http请求比较多,且系统返回数据时间较长,造成了很严重的排队现象。这就要从两个方面来解决了:服务端与客户端。

顺便说一下,你有没有注意到这张图上的周期性模式?比如说,周末期间活动比较少,到了晚上活动增加。为了更全面地了解数据库在正常工作时间段的运行状况,你在分析时可以将这些时段排除在外特别是由于这些时段可能是进行完全备份的时候)。我们可以排除这类数据,让我们的图表更流畅:

要确定过多的页交换对磁盘活动的影响,请将
Physical Disk” Avg.Disk sec/Transfer 和 MemoryPages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1,那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况,那么您可能需要更多的内存。

     
首先是客户端。ie6不仅js引擎效率低,且对于同一服务器只能有两个并发解求,当http请求较多的时候,页面加载速度慢的问题就特别明显。解决方法是下载MS的一个ie补丁,它可以将ie6/ie7的最大连接数由2个改为10个。

www.hj8828.com 4

Page Faults/sec:每秒软性页面失效的数目(包括有些可以直接在内存中满足而有些需要从硬盘读取)较page/sec只表明数据不能在内存的指定工作集中立即使用。

     
服务端分为web服务器与数据库服务器。我首先查看了Web服务器:一个16核11G内存万转硬盘的怪物。
发现基本没有负载!!!CPU的使用率在1%以下!NB啊。然后去查看了数据库服务器,果真,问题出在这里!

下一步是查看哪个类别最糟糕。如果主色是蓝色或黄色代表读取或写入),那么你的服务器是磁盘输入/输出密集型的。下面是个示例:

Cache Bytes:文件系统缓存(File System
Cache),默认情况下为50%的可用物理内存。如IIS5.0
运行内存不够时,它会自动整理缓存。需要关注该计数器的趋势变化

      由于是生产环境,sql server
是不能用D版滴。客户为了节约预算,将这个新系统的数据库与别的一些系统的数据库放到了一台机器上。结果我今天去看的时候,发现虽然内存与硬盘负载曲线都比较低且稳定,但CPU的负载却长期70%以上,有时达到100%的时间长达几秒钟!CUP成了整个系统最大的瓶颈!解决的方法很简单,我们找了另外一台现有的且负载较低的数据库服务器,将数据库移过去就行了!

www.hj8828.com 5

如果您怀疑有内存泄露,请监视 MemoryAvailable Bytes 和 MemoryCommitted Bytes,以观察内存行为,并监视您认为可能在泄露内存的进程的
Process”Private Bytes、Process”Working Set 和Process”Handle Count。如果您怀疑是内核模式进程导致了泄露,则还应该监视
Memory”Pool Nonpaged Bytes、Memory” Pool
Nonpaged Allocs 和 Process(process_name)” Pool Nonpaged Bytes。

     
问题到这里并没有结束。为什么CUP的负载这么大?据我所知除了这个新系统的数据库,机子上就只有另外一个系统的数据库。且即使把这个新系统移走后,CPU的负载仍没有明显的改观,长期60%到80%,且这是下午了,根本不是系统最繁忙的时候。我在网上找了找资料,然后打开windows的性能监视器,并加入指定计数器进行观查,发现最大的问题在于数据库的整表扫描过多!网上说这个监控数最好不要超过2,但是这个系统长期100+到200+,且动不动就死锁一下,难怪CPU的负载高,都去做这事了~~~

为什么是输入/输出密集型的?点击Physical
R/W图表。问题可能出在工作负载上,比如说输入/输出操作次数太多: 

Pages per second :每秒钟检索的页数。该数字应少于每秒一页。

      

www.hj8828.com 6

Process:
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql
server,可接受的最大上限是80-85%
Page Faults/sec:将进程产生的页故障与系统产生的相比较,以判断这个进程对系统页故障产生的影响。

      以下是我总结的常见的sqlserver 性能计数器

非常频繁的输入/输出活动可能是糟糕的高速缓存命中率引起的。你可以点击Cache
Hits高速缓存命中)按钮来证实:

Work set: 处理线程最近使用的内存页,反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存,页就会被留在工作集中,当自由内存少于一个特定的阈值时,页就会被清除出工作集。

      

www.hj8828.com 7

Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低,则此计数器可以是内存泄漏的最佳指示器。

 

注意:不要使用性能监视器PerfMon所报告的“Cache Hits
Ratio”高速缓存命中率)。PerfMon报告的只是“医院里的平均温度”而已——它是对周末和繁忙时段、夜间索引碎片整理和白天操作求平均值,用的是不同的使用模式。

Processor:监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息,帮助您决定是否存在瓶颈。

指标描述

有时候,“高速缓存命中率”足够好,但是延迟很差。点击Seek
Time寻道时间)按钮来证实:

%Processor Time:如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。

指标范围

 

%User Time:表示耗费CPU的数据库操作,如排序,执行aggregate
functions等。如果该值很高,可考虑增加索引,尽量使用简单的表联接,水平分割大表格等方法来降低该值。

指标单位

www.hj8828.com 8  

%Privileged Time:(CPU内核时间)是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和”Physical
Disk”参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in
RAM,减低”max async
IO”,”max lazy
writer IO”等措施都会降低该值。
此外,跟踪计算机的服务器工作队列当前长度的
Server
Work Queues” Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4
则表示可能出现处理器拥塞。此计数器是特定时间的值,而不是一段时间的平均值。

SQL Server中访问方法( Access
Methods)

50毫秒ms)意味着,服务器每秒只能执行20次输入/输出操作。这样的速度仅仅相当于老式软盘!
有些服务器是处理器密集型的,下面是一台典型的处理器密集型服务器的模样:

% DPC Time:越低越好。在多处理器系统中,如果这个值大于50%并且Processor:%
Processor Time非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。

全表扫描 /秒 

www.hj8828.com 9

Thread
ContextSwitches/sec: (实例化inetinfo 和dllhost 进程)
如果你决定要增加线程字节池的大小,你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数,这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高,就应该减小线程字节池的大小。

( Full Scans/sec)  

一般来说,如果服务器是处理器密集型的,情况并不坏,只要绝对数值不是很高千万要牢记:Y轴表示服务器每秒使用所有处理器时的处理器毫秒,所以在4个处理器上,每秒使用处理器最多可以有4000毫秒。)但是如果处理使用率的绝对值很高,那么点击Query
Stats查询统计数字)按钮。你会看到按处理器、读取和写入分类的前十大有问题的查询。这些查询很可能是需要优化的对象。

Physical Disk:
%Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大,那么硬盘不是瓶颈。如果只有%Disk
Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器之前,请在Windows
2000 的命令行窗口中运行diskperf
-yD。若数值持续超过80%,则可能是内存泄漏。
Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2
倍。要提高性能,可增加磁盘。注意:一个Raid
Disk实际有多个磁盘。
Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加,应小于磁盘设备最大容量。

 

顺便说一下,你每天可以通过电子邮件来获得所有这些报告。只要在SQL
Heartbeat中进行配置:点击工具栏中的Reports报告)按钮。

Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。

指 每秒全表扫描的数量。全表扫描可以是基本表扫描或全索引扫描。由于全表扫描需要耗费大量时间,因此全表扫描的频率过高的话,会影响性能。

Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。

如果该指标的值比 1或 2 高,应该分析设计的查询以确定是否确实需要全表扫描,以及
SQL 查询是否可以被优化。

Network Interface:
Bytes Total/sec :为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较

次数 /秒

SQLServer性能计数器:
Access Methods(访问方法)
用于监视访问数据库中的逻辑页的方法。

Page splits/sec

. Full Scans/sec(全表扫描/秒)
每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高,应该分析你的查询以确定是否确实需要全表扫描,以及S Q
L查询是否可以被优化。
. Page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。

由于数据更新操作引起的每秒页分割的数量。

Buffer Manager(缓冲器管理器):监视 Microsoft® SQL Server? 如何使用: 内存存储数据页、内部数据结构和过程高速缓存;计数器在
SQL
Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理
I/O。 监视 SQL
Server 所使用的内存和计数器有助于确定: 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样,SQL
Server 必须从磁盘检索数据。 是否可通过添加更多内存或使更多内存可用于数据高速缓存或
SQL
Server 内部结构来提高查询性能。
SQL Server 需要从磁盘读取数据的频率。与其它操作相比,例如内存访问,物理
I/O 会耗费大量时间。尽可能减少物理 I/O
可以提高查询性能。

 

.Page Reads/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理
I/O 的开销大,可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,使开销减到最小。

 

.Page Writes/sec (.写的页/秒)
每秒执行的物理数据库写的页数。

SQL Server中缓冲器管理器(
Buffer Manager)

.Buffer Cache Hit Ratio. 在“缓冲池”(Buffer
Cache/Buffer Pool)中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自
SQL
Server 实例启动后对高速缓存的查找总数。经过很长时间后,这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多,一般希望这一数值高一些。通常,可以通过增加
SQL
Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定,但比率最好为90%
或更高。增加内存直到这一数值持续高于90%,表示90%
以上的数据请求可以从数据缓冲区中获得所需数据。
. Lazy Writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。
Cache Manager(高速缓存管理器)
对象提供计数器,用于监视 Microsoft® SQL Server? 如何使用内存存储对象,如存储过程、特殊和准备好的
Transact-SQL 语句以及触发器。
. Cache Hit Ratio(高速缓存命中率,所有Cache”的命中率。在SQL
Server中,Cache可以包括Log
Cache,Buffer
Cache以及Procedure
Cache,是一个总体的比率。)
高速缓存命中次数和查找次数的比率。对于查看SQL
Server高速缓存对于你的系统如何有效,这是一个非常好的计数器。如果这个值很低,持续低于80%,就需要增加更多的内存。
Latches(闩)
用于监视称为闩锁的内部 SQL
Server 资源锁。监视闩锁以明确用户活动和资源使用情况,有助于查明性能瓶颈。

缓冲区高速缓存命中率 (Buffer
Cache  

. Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒))
一个SQL
Server线程必须等待一个闩的平均时间,以毫秒为单位。如果这个值很高,你可能正经历严重的竞争问题。
. Latch Waits/sec (闩等待/秒)
在闩上每秒的等待数量。如果这个值很高,表明你正经历对资源的大量竞争。

Hit Ratio % )

Locks(锁)
提供有关个别资源类型上的 SQL
Server 锁的信息。锁加在
SQL
Server 资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。例如,如果一个排它 (X)
锁被一个事务加在某一表的某一行上,在这个锁被释放前,其它事务都不可以修改这一行。尽可能少使用锁可提高并发性,从而改善性能。可以同时监视
Locks 对象的多个实例,每个实例代表一个资源类型上的一个锁。

 

. Number of Deadlocks/sec(死锁的数量/秒)
导致死锁的锁请求的数量
. Average Wait Time(ms) (平均等待时间(毫秒))
线程等待某种类型的锁的平均等待时间

指在缓冲区高速缓存中找到而不需要从磁盘中读取的页的百分比。该比率是缓存命中总次数与缓存查找总次数之比。经过很长时间后,该比率的变化很小。由于从缓存中读取数据比从磁盘中读取数据的开销小得多,一般希望该比率高一些。

. Lock Requests/sec(锁请求/秒)
每秒钟某种类型的锁请求的数量。

该指标的值最好为 90% 或更高。通常可以通过增加 SQL Server
可用的内存数量来提高该指标的值。增加内存直到这指标的值持续高于
90%,表示 90% 以上的数据请求可以从数据缓冲区中获得所需数据。

Memory manager:用于监视总体的服务器内存使用情况,以估计用户活动和资源使用,有助于查明性能瓶颈。监视 SQL
Server 实例所使用的内存有助于确定:
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样,SQL
Server 必须从磁盘检索数据。
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或
SQL
Server 内部结构来提高查询性能。
Lock blocks:服务器上锁定块的数量,锁是在页、行或者表这样的资源上。不希望看到一个增长的值。

%

Total server memory:sql
server服务器当前正在使用的动态内存总量.

读的页 /秒 

监视IIS需要的一些计数器

( Page Reads/sec)

Internet Information Services Global:
File Cache Hits %、File
CacheFlushes、File Cache
Hits
File Cache Hits %是全部缓存请求中缓存命中次数所占的比例,反映了IIS
的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站,该值应该保持在80%左右。而File Cache
Hits是文件缓存命中的具体值,File
CacheFlushes 是自服务器启动之后文件缓存刷新次数,如果刷新太慢,会浪费内存;如果刷新太快,缓存中的对象会太频繁的丢弃生成,起不到缓存的作用。通过比较File Cache
Hits 和File Cache
Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值,可以得到一个适当的刷新值(参考IIS
的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize)
Web Service:
Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused:数值越低越好。高数值表明网络适配器或处理器存在瓶颈。

指每秒发出的物理数据库页读取数。该指标主要考察数据库从磁盘读取数据的频率。因为物理
I/O 会耗费大量时间,所以应尽可能地减少物理
I/O 以提高性能。 

Not Found Errors:显示由于被请求文件无法找到而无法由服务器满足的请求数(HTTP状态代码404)

该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,以降低该指标的值。 

个数 /秒

写的页 /秒 

( Page Writes/sec)

指每秒执行的物理数据库写的页数。该指标主要考察数据库向磁盘写入数据的频率。因为物理
I/O 会耗费大量时间,所以应尽可能地减少物理
I/O 以提高性能。 

该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,以降低该指标的值。 

个数 /秒

惰性写 /秒