此主题介绍了可以用来监视下列硬件组件的计数器，并包括了每个组件的建议值和其他调整策略。
监视内存（上）
监视处理器容量 （上）
监视多处理器系统（上）
监视网络容量和带宽 （下）
监视和优化硬盘（下）
文章列表
监视和调整硬件性能（上）
监视和调整硬件性能（下）
推荐阅读：技术人员，为什么会苦逼
监视内存
解决内存不足的问题之后，IIS 上将获得最大的性能改善。在作出任何有关更改硬件配置的决定之前，应首选排除内存问题。应首先监视内存以验证服务器是否有足够的内存，然后再继续处理服务器环境其他部分的问题。内存不足引起的问题常常会表现为系统的其他部分的问题。对于电子商务站点、具有许多内容的站点，以及流量非常大的站点，内存更大一点特别有益。
可以使用系统监视器判断服务器上的当前内存量是否满足需要。系统监视器以图形方式显示计数器读数随时间的变化。
监视下面的计数器来判断是否存在与内存有关的性能瓶颈：
| 计数器 | 监视 |
|---|---|
| Memory\Available Bytes | 试图保留至少 10％ 的可用内存以供高峰时间使用。 |
| Memory\Page Faults/sec
Memory\Pages Input/sec Memory\Page Reads/sec Memory\Transition Faults/sec |
如果进程请求内存中的某个页面而系统无法在请求的位置找到它，就会产生页错误。如果该页在内存中的其他地方，那么该错误叫做软页错误（由 Transition Faults/sec 度量）。如果该页必须从磁盘中检索，那么该错误就叫作硬页错误。大多数处理器可以处理大量的软错误而不会造成任何后果。然而，硬错误会造成严重的延迟。
Page Faults/sec 是处理器处理硬页错误和软页错误的总体速率。Pages Input/sec 是为解决硬页错误而从磁盘读取的页的总数。Page Reads/sec 是为解决硬页错误而读取磁盘的次数。Pages Input/sec 将大于等于 Page Reads/sec，并可以使您很好地了解硬页错误率。如果这些数字较低，则服务器响应请求的速度可能很快。如果它们较高，可能是因为您为缓存分配的内存太多，而没有为系统的其他操作保留足够的内存。可能需要提高服务器的 RAM 量，虽然减少缓存大小也是一个有效办法。 |
| Memory\Cache Bytes | 显示文件系统的大小。默认情况下，缓存被设置为最多可以使用 50％ 的可用物理内存。由于 IIS 会自动在内存不足的情况下减少缓存，因此要确保监视此计数器的趋势。 |
| WWW service cache\File Cache Flushes
WWW service cache\File Cache Hits WWW service cache\File Cache % |
这些计数器描述了用户模式文件缓存。文件缓存基本上是一个文件名或者文件内容缓存。如果用户请求一个文件，IIS 就会搜索文件缓存，如果它位于缓存中，就返回该文件。如果 IIS 在缓存中找不到该文件，它将从硬盘中读取并返回该文件，从而导致硬页错误。
File Cache Flushes 表示了 IIS 从万维网发布服务 （WWW 服务)缓存中清除条目的次数。如果文件已经更改或者如果在 30 秒内没有访问文件，将清除条目。如果该计数器值较高，IIS 就用没有被访问的文件填充缓存，随后再将这些文件清空。 File Cache Hits 是 IIS 在缓存中找到文件的次数。
File Cache % 是缓存命中率。这是 IIS 在缓存中找到请求的文件的次数百分比。如果缓存命中率较低（例如，70％），您可能需要考虑围绕能轻易在文件缓存中找到的少量的“热门”信息重新设计站点，从而改善性能。 |
| Process\Page File Bytes
Process\Page File Bytes Peak Paging File\% Usage Paging File\% Usage Peak |
这些计数器反映了在使用中的页面文件实例的数量。页面文件越大，系统提交给它的内存越多。Windows Server 2003 家族成员在系统驱动器上创建页面文件。可以在每个逻辑磁盘上创建页面文件，并可更改现有文件的大小。事实上，通过跨多个单独的物理驱动器对页面文件进行条带化，可以改善页面文件的性能（即，它所使用的驱动器不包含站点的内容或日志文件）。记住，系统驱动器上的页面文件至少应是物理内存大小的两倍，这样，系统便可以在系统意外地锁定或关闭的情况下将 RAM 中的全部内容写入磁盘。 |
| Memory\Pool Paged Bytes
Memory\Pool Non-paged Bytes Process\Virtual Bytes (W3wp.exe) Process\Virtual Bytes (Inetinfo.exe) Process\Working Set (W3wp.exe) Process\Working Set (Inetinfo.exe) |
Pool Paged Bytes 和 Pool Non-paged Bytes监视服务器上的所有进程的池空间。
Virtual Bytes 计数器既可以通过 Inetinfo.exe 进程，也可以通过在服务器上实例化的 W3wp.exe 进程（来监视 IIS 直接保留的虚拟地址空间的量。 Working Set 计数器计量每个进程使用的内存页面的数量。一定要监视服务器上的 W3wp.exe 的所有实例的计数器；否则，您就不能获得 IIS 使用的虚拟内存的准确读数。系统的内存池保留了应用程序和操作系统创建和使用的对象。内存池的内容只有在特权模式下才可以访问。即，只有操作系统的内核才能直接使用内存池；而用户进程不能直接使用。在运行 IIS 6.0 的服务器上，为连接提供服务的线程与该服务使用的其他对象（如文件句柄和套接字）一起存储在非页面缓冲池中。 |
除了添加更多的 RAM 外，还可以使用下面的过程来提高内存性能。
- 改善数据组织。
- 使用磁盘镜像或带区。
- 用托管代码（ASP.NET）或 Internet 服务器 API (ISAPI) 应用程序替换通用网关接口 (CGI) 应用程序。
- 增大页面文件。
- 消除不必要的功能。
- 改变文件系统缓存与 IIS 工作集之间的平衡。
监视处理器容量
由于用户要求网站有快速的响应时间以及这些站点能提供不断增加的动态生成的内容量，快速和有效的处理器使用应放在首位。当一个或多个进程消耗了大多数处理器时间时，就会发生瓶颈。这会迫使已准备执行的线程在队列中等待处理器时间。添加其他硬件，无论是内存、硬盘还是网络连接，以试图克服处理器瓶颈并非有效办法，并可能会引发更大的问题。
监视下列计数器以判断是否存在与处理器容量相关的性能瓶颈：
| 计数器 | 监视 |
|---|---|
| System\Processor Queue Length | 显示队列中等待执行的并由系统上的所有处理器共享的线程的数量。如果此计数器有两个或两个以上的持续不变的线程，则说明服务器出现瓶颈。 |
| Processor\%Processor Time | 处理器瓶颈的特征在于这样的情况，其中，% Processor Time 数字较高，而网络适配卡和磁盘 I/O 低于容量值。在多处理器计算机上，请检查 % Processor Time 计数器，以查找处理器和处理时间之间的任何不平衡现象。 |
| Thread (svchost/host number)\Context Switches/sec
System\Context Switches/sec |
如果您决定增加任何线程池的大小，则应监视此计数器。提高线程的数量可能会将上下文开关的数量提高到某一点，造成性能降低而不是提高。如果每秒钟上下文开关达到一万或更多，则说明该计数器的值较大。如果看到该数字有这么大，则请考虑降低线程池的大小。可能很难平衡线程与由连接和请求计量的总体性能。每次调整线程时，都应进行总体性能监视，以了解性能是提高还是降低了。
要判断是否应调整线程计数，应将线程数量和进程中的每个线程的处理器时间与总处理器时间进行比较。如果线程持续处于忙状态，但没有完全使用处理器时间，则可以通过产生更多的线程来改善性能。然而，如果所有线程都忙，并且处理器接近于它们的最大容量，最好在多台服务器之间分布负载而不是提高线程的数量。 |
| Processor\Interrupts/sec
Processor\% DPC Time |
可以使用这些计数器判断处理器花费在中断和延迟的过程调用上的时间长短。这两个因素可能是造成处理器上负载的另一个原因。客户端请求可能是中断和延迟的过程调用的主要原因。一些新的网络适配卡包括中断调解，它会在中断的级别太高时将中断堆积在缓冲区中。 |
监视多处理器系统
IIS 可以在多处理器计算机上缩放，但可伸缩性可能会由于网站和 Web 应用程序的拙劣设计而削弱。Web 园和进程回收可以帮助最大限度地减少与不完善的应用程序相关的性能问题。然而，一定要监视和测试多处理器计算机上的网站和 Web 应用程序的可伸缩性。在更改多处理器计算机的设置之前，应排除系统的所有其他方面的瓶颈。
还应考虑向特定的处理器指派进程（叫做处理器关系），以更好地管理服务器处理请求和应用程序处理的方式。此外，在更改多处理器计算机的设置之前，应在 IIS 中启用服务质量功能。服务质量功能用于限制特定网站或 Web 应用程序使用的资源，以确保系统的其他部分有足够的资源使用。
监视下列计数器以判断是否存在与多处理器计算机相关的性能瓶颈：
| 计数器 | 监视 |
|---|---|
| Processor\% Processor Time (_Total) | 通过将采样间隔内所有处理器的平均非空闲时间相加并将总和除以处理器的数量，即可衡量计算机中所有处理器的处理器活动。例如，如果平均起来，所有处理器在半个采样间隔内处于忙状态，则显示 50%。如果半数处理器在整个间隔内处于忙状态，而其他的处理器处于空闲状态，也显示 50%。 |
| Thread\% Processor Time (_Total/_Total) | 衡量线程的处理器时间量。 |
管理多处理器系统中的处理器关系
设置处理器关系意味着向特定的处理器指派特定的进程或应用程序。控制处理器关系可以通过减少线程从一个处理器移动到另一个处理器时处理器缓存刷新的次数来提高性能。对于专用的文件服务器，这可能是一种好的选择。然而，请注意，为程序分配特定的处理器可能会不允许其他程序线程迁移到最不繁忙的处理器。
这些天看了一篇微软官方发布的MS SQL Server2008性能问题处理及优化的英文文档，里面知识点介绍地很详细，在现实工作中也很实用，遂产生了想把它翻译一下的念头。翻译的过程，既可以帮助自己复习一下这些技术，也可以向其他还不熟悉这一块的朋友介绍一些新的知识，何乐而不为呢。只是这篇文章有点长，我会分成几篇随笔去介绍，所以，不光是对我耐性的考验，也是对你的考验哦！
--------------------------------------------
使用不当的游标
SQL Server 2005之前的版本只支持在一个连接中共存唯一一个活动。一个正在执行的查询或者正在有结果被返回给客户端都被认为是一个活动。在很多情况下，客户端应用可能需要从结果集中按行读取数据，然后把这些数据提交给其他的查询语句使用。这种需要使用默认的结果集是不能实现的，因为它可能有其它未决定的结果。一个通用的解决方案是改变连接属性，使用一个服务器端的游标。
当一个服务器端的游标被使用后，数据库客户端软件（OLE DB 支持和ODBC驱动）会显式地将客户端需求结果压缩进指定的扩展存储过程，比如sp_cursoropen或者sp_cursorfetch。这就是所谓的API cursor（与transact-SQL游标截然相反）。当用户执行查询时，查询内容会通过sp_cursoropen被传送至服务器端；从结果集中读取数据的请求会导致sp_cursorfetch引导服务器只返回一定数量的结果行。通过控制匹配的行数，ODBC驱动或者OLE DB支持会缓存一定的结果行。这样做避免了这样一种情况：服务器等待客户端读取传送过去的所有行。这样，服务器服务器就做好了去接受连接上的新请求的准备。
应用程序某一时刻打开一个游标并且读取一行（或者小数目的几行），很容易就会因为网络延迟出现瓶颈，尤其是在WAN环境。在一个拥有多个用户连接的快速网络环境里，运行多个游标的开销会变得很明显。因为多个游标都需要定位各自的结果集，预请求就会变得开销很大，比使用100个游标，但每个游标返回一行更高效的做法是使用一个单独的游标返回100行数据。
诊断
你可以使用下面的工具去诊断不当的游标使用。
Performance Monitor
通过查看SQL Server:Cursor Manager By Type- Cursor/sec计数器，你可以初步感受下系统中有多少正在被使用。系统的使用率很高是因为每秒钟有许多的小匹配数目的游标被使用。没有一个特殊的计数器可以列举出来取出的缓冲大小。
DMVs
你可以使用下面的查询去确定API cursor的连接（与transact-SQL游标截然相反）对应每行获取的缓冲大小。使用更大的获取缓冲会更高效，例如100行。
select * from sys.dm_exec_connections con cross apply sys.dm_exec_cursors(con.session_id) as cur where cur.fetch_buffer_size=1 and cur.properties like 'API%' --API cursor(Transaction-SQL cursors always have a fetch buffer of 1)
SQL Trace
使用一个包含PRC:Completed 事物类的trace去查找sp_cursorfetch语句。其中第四个参数会去限制返回过来的匹配结果行数。最大的返回行数会在对应的PRC:Starting事物类的输入参数中设置。
解决方案
--确定下是游标是否是最合适的手段去完成对应的需求，考虑下是否有其它的方案可以替代。
--在连接至SQL Server 2008时，考虑启用多活动结果集（MARS）。
--参照对应的文档，针对特定的API，为游标指定一个更大的匹配缓冲：
-ODBC： SQL_ATTR_ROW_ARRAY_SIZE
-OLE DB: IRowset::GetNextRows or IRowsetLocate::GetRowsAt
如果要为一个处理器指派特定的进程或程序，以牺牲其他进程为代价提高其性能，则请在 IIS 配置数据库中更改 SMPProcessorAffinityMask 属性
作者：小洋，燕洋天
出处：http://yanyangtian.cnblogs.com/
承接架构设计，性能优化（程序，数据库等方面）技术咨询