您的位置:新葡亰496net > 网络数据库 > 新葡亰496net:windows质量监视器常用流量计,学习

新葡亰496net:windows质量监视器常用流量计,学习

发布时间:2019-11-30 06:19编辑:网络数据库浏览(189)

    背景

    最近一个客户找到我说是所有的SQL Server 服务器的内存都被用光了,然后截图给我看了一台服务器的任务管理器。如图

    新葡亰496net 1

    这里要说明一下任务管理器不会完整的告诉真的内存或者CPU的使用情况,也就是说这里只能得到非精确的信息,有可能就是一个假警报。

    为了让我的客户放心,我检查了服务器并且查看了很多性能指标。我所看到的就是CPU和硬盘使用都是很低的只有内存是高的,这恰恰是我们期望的SQLServer 服务器的状态。SQL Server会尽可能的使用内存,通过缓存尽可能多的磁盘来改善性能。当然如果OS需要它也会立即释放资源回来。

    SQL Server 对内存是“贪得无厌”的,它会持有所有分配给它的内存,不论是否使用。而这也是我们想要它去做的。因为它会存储数据和执行计划在缓存中,然后当使用完这些内存时,它不会释放这些内存,缓存到内存中,除非两种情况才会释放缓存的数据内存:1) SQL Server 重启或者内存不足 2) 操作系统需要内存 
    默认的内存设定就是使用所有内存(安装时设置),当操作系统需要内存时,它也会大量释放内存。然后等到有内存时在重新大量持有。但是这种不是最佳实践,最好还是设定一个最大内存限制,这样操作系统就会保证一定量的内存永远为SQL Server 使用。

    新葡亰496net 2

     

    当看到资源管理器,Available MB 的内存有两部分组成Standby--备用和Free--可用,这Standby 的空间系统已经把它缓存了,而Free的内存意味着没有被使用。它们都叫做可利用内存。因此针对一开始那个客户担忧我们大可不必太担心。当然我们还需要健康其他的性能计数器,查明是否存在内存影响性能的隐患。需要关注的指标如下:

    • Page Life Expectancy
    • Available Bytes
    • Buffer Cache Hit Ratio
    • Target & Total Server Memory
    • Memory Grants Pending
    • Pages/sec (Hard Page Faults)
    • Batch Requests/sec & Compilations/sec

    介绍下这些性能参数:

    性能监视的工具有很多,首先介绍Microsoft Windows Server自带的Performance Monitor. Windows性能监视器是一个很好用的工具,可以实时检查运行程序影响计算机性能的方式(CPU,ROM,IO等),并通过收集日志数据供以后分析使用. 通过性能监视能了解系统loading以及这种loading对系统资源的影响, 分析性能或者资源使用率的变化趋势, 有效的对系统做出调整, 优化或者升级. 诊断系统故障或确定优化的组件或升级的步骤, 也可以找出性能瓶颈. 

    最近研究性能测试工具中发现这些所谓的性能测试工具的数据、全部来至windows操作系统提供的数据、然后通过API提供给性能测试工具、性能测试工具在用一种比较直观的图形展示出来。也就是说不部分情况下如果把你没有弄明白性能监视器中数据得意义,那么性能测试工具的那些图表对你的意义也就没有多大的用处。下面我整理了一部分windows中性能监视器中比较常用的性能计数器。

    Page Life Expectancy (PLE)

    这个性能计数器记录了数据页(非锁定)在缓冲池中的平均时间。在生产高峰这个数值可能比较低,但是一般要保持这个数据在300s以上,数据待在缓冲中时间越长,那么SQL的IO操作越少。

    如果长期这个数值在300s以下,可以考虑增加内存,当然由于现在内存越来越大,这个值也变得不那么重要了,但是对于中小系统依然可以作为一个标准阈值。

    由于这个阈值基于32位系统的4G内存,那么标准算法可以大致可以推算:内存大小(GB)/4*300

    也可以使用下面的语句来查询该计数器:

    SELECT [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%Buffer Manager%' AND [counter_name] = 'Page life expectancy'
    

    Performance Monitor是一个系统内置的MMC控制台: 包括系统监视器(System Monitor)和性能日志和警报(Performance Logs and Alerts)两个部分. 通过实时和日志的方式来记录服务器性能. 使用系统监视器可以取现, 曲方图或者报表的方式实时查看内存, 硬盘, 处理器, 网络等各种对象的性能数据. 使用性能日志也警报可以对计数器日志进行配置, 记录性能数据, 设置性能警报, 通过设定性能警报, 可以使系统在某一特定的计数器值低于或高于指定的值时及时通知系统管理员.

    这里整理的比较多的内容:处理器对象、系统对象、逻辑磁盘对象、物理磁盘对象、内存。这些性能计数器我们经常在使用的过程中都会用得到,所以这篇文章大部分内容是这些的。

    Available MBytes

    该计数器监测还有多少可用内存,是否操作系统存在内存压力。一般我们调查是否这个计数器持续在500MB以下,这说明内存过低。如果持续低于500则说明你需要增加更多的内存。

    这个计数器不能通过T-SQL查询,只能通过性能监视器观察。

    新葡亰496net 3

    一、处理器对象(Processor Object)

    Buffer Cache Hit Ratio

    缓冲命中率,这个计数器记录平均多少频率从缓冲池中取得数据。我们在OLTP数据库中一般这个比率是90%-95%(该数值经由@MSSQL123 指出发现是错误的,再次进行修改)。由于sqlserver 把预读也作为缓冲比例,所以导致该值很高,所以该计数器只做理解,不能作为真实性能瓶颈参考了。如果该计数器持续低于90%,则需要增加内存。

    在可以使用下面的T-SQL语句查询:

    SELECT [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%Buffer Manager%' AND [counter_name] = 'Buffer cache hit ratio'
    

    下面简单介绍Windows Server 2003下的Performance Monitor, 通过日志记录性能数据, 之后分析.

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

    Target & Total Server Memory

    服务器当前总内存(buffer)以及目标内存,在缓冲池初始化增加内存的时候,总内存会比目标内存稍低一点。这个比例会逐渐接近1,如果总内存没有增长很快,就会显著低于目标内存,这就表示如下两点:

    1)  你可以分配尽可能多的内存,SQL能缓存整个数据库到内存中,然后如果数据库小于机器内存,内存不会完全用光,在这种情况下,总内存将永远小于目标内存。

    2)  SQL不能增加缓冲池,比如系统内存有压力。如果这种情况你需要增加最大服务器内存,或者增加内存来改善性能。

    SELECT [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%Memory Manager%' AND [counter_name] IN ('Total Server Memory (KB)','Target Server Memory (KB)')
    
    1. 打开:Administrative Tools->Performance, 

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

    Memory Grants Pending

    这个计数器测量等待内存授予的SQL的进程数量。一般推荐阈值为1或者更少。如果大于1这说明内存不足按顺序等待内存释放再操作SQL。

    新葡亰496net:windows质量监视器常用流量计,学习笔记。一般工作中出现这种等待可能是由于糟糕的查询,缺失索引,排序或者哈希引起的。为了查明原因可以查询DMV --sys.dm_exec_query_memory_grants 这个视图,将会展示哪一个查询需要内存授予执行。

    如果不是以上原因引起的内存等待,则需要增加内存来解决这个问题。此时就有理由增加硬件了。查询的T-SQL语句如下:

    SELECT [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%Memory Manager%' AND [counter_name] = 'Memory Grants Pending'
    

    或SQL Server Profiler->Tools->Performance Monitor,或在运行中输入"perfmon"

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

    Pages/sec (Hard Page Faults)

    这里也使用数据库级别计数器:当需要读取或写入的页不在内存中,需要到磁盘中读取时计数。这个计数器是一个记录读和写的总和并且不能直接在内存中获取只能从因盘中读取(导致resulting in hard page faults),这个问题是由于操作系统必须交换文件在磁盘上,当访问内存时,内存不足则需要交换文件到磁盘上,由于磁盘读写速度远低于内存,性能就会受到严重影响。

    对于这个计数器,推荐阈值为<50(或者某个稳定值),如果看到高于这个值,不过需要注意,只要这个值能够稳定在一个较低的水平,没有持续性的大批量数据的写入(磁盘)于读取(从磁盘载入内存),都可以接受。相反,如果长期在一个高位水平,并且观察到PLE不能稳定在参考值范围内,说明内存可能存在瓶颈。当然,如果数据库备份或者还原,包括导出、导入数据以及内存中映射文件等等这些也会导致性能计数器超出某个稳定值。

    2.重要的性能计数器

    3.新葡亰496net:windows质量监视器常用流量计,学习笔记。 用户时间百分比(%User Time) 处理器用于在用户模式工作的时间百分比。这种类型的工作是由应用产生的。通常,希望极大化用户时间百分比的值,极小化特权时间百分比的值。

    Batch Request & Compilations

    该计数器包含两个检查

    • SQL Server: SQL Statistics – Batch Request/Sec.  传入查询的数量(批处理数量)
    • SQL Server: SQL Statistics - Compilations/Sec.  新建立的执行计划数量

    如果Compilations/sec是25%或者相对Batch Requests/sec更高,则执行计划将被放到缓存中,但是永远不会重用执行计划。宝贵的内存就被浪费了,而不是缓存数据。这是糟糕的实践,我们要做的就是阻止这种情况,

    如果Compilation/sec 很高比如100,表示有大量的即席查询正在运行。这时可以启用“optimize for ad hoc”把执行计划缓存,但是只有在第二次查询时才能被使用。

    使用如下T-SQL可以得到相应的指标:

    SELECT [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%SQL Statistics%' AND [counter_name] = 'Batch Requests/sec';
    
    SELECT [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%SQL Statistics%' AND [counter_name] = 'SQL Compilations/sec';
    

    同样可以获得比率:

    SELECT ROUND (100.0 * (SELECT [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%SQL Statistics%' AND [counter_name] = 'SQL Compilations/sec') / (SELECT [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%SQL Statistics%' AND [counter_name] = 'Batch Requests/sec') ,2) as [Ratio]
    

    (1). Processor

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

    关于如何设定数据库可用的内存最大值,如图所示:

    新葡亰496net 4

    推荐阈值:一般来说,我都是采用10%用于操作系统其它90%分配给数据库。当然如果内存很大可以调整这个比例小于1/9,对于内存较小的通常我都预留4-6G左右给操作系统。

    (2). PhysicalDisk

    5.中断数/秒(Interrupts/sec) 处理器每秒接收并处理的硬件中断的数量。它不包括系统D P C,系统D P C单独计数。

    我们看一下实际例子:

    在性能监视器中看一下这个计数器,我们可以看到这个服务器处于健康状态下,有11GB的可用空间,没有PageFaults(I/O只从缓存中没有交换到磁盘),缓冲的比率为100%,PLE超过20000s,没有内存等待,充足的总内存和较低的编译比率(编译数/查询数).

    新葡亰496net 5

    这个测量数据很容易理解,这要比任务管理器更具有作用,能依据此做出判断是否有足够的内存在这台SQL Server服务器上。

    (3). Memory

    二、系统对象(System Object)

    总结

        如果只根据任务管理器来做出判断,我们很容易出现错误决定。因为不管系统多少内存,SQL Server 会尽可能的使用占用内存,这不是bug。缓存数据在内存中有很好的效果,意味着服务器是健康的,也为用户提供了更好的执行效率。在实际数据库环境中,一般突然遇到的性能问题多半是因为T-SQL语句引起的,就如我前面提到糟糕的查询(缺失索引、排序、哈希等等),这个时候通过语句优化可以很好的解决突发问题,这里就不详解了。如果服务器普遍存在文章中出现的内存性能计数器问题,那就写报告提交内存增加需求吧。

    (4). Network Interface

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

    (5). SQL Server Access Methods

    1.处理器队列长度(Processor Queue Length) 处理器队列中的线程的数量。换句话说,它是等待运行的线程数。即使你的系统具有多个处理器,但只有一个队列用于处理器时间。计数器只记录那些准备执行但仍处于等待的线程,不是那些正在运行的线程。

    (6). SQL Server: SQL Statistics

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

    (7). SQL Server: Databases

    三、 SQL Server:缓冲区管理器对象( B u ffer Manager Object)

    (8). SQL Server General Statistics

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

    (9). SQL Server Locks

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

    (10). SQL Server Buffer Manager

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

    下表对重要的性能计数器做一个简要的说明:            

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

    性能计数器:

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

     

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

     

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

    Performance Object

    四、 SQL Server:数据库对象(Database Object)

    Counter

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

    Description

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

    Processor

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

    %processor Time

    五、 SQL Server:常规统计对象(General Statistics Object)

    指处理器执行非闲置线程时间的百分比,测量处理器繁忙的时间 这个计数器设计成用来作为处理器活动的主要指示器,可以选择单个CPU实例,也可以选择Total

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

    Interrupts/sec

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

    处理器正在处理的来自应用程序或硬件的中断的数量

    六、 SQL Server:闩对象(Latches Object)

     

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

     

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

     

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

    PhysicalDisk

    七、 SQL Server:锁对象(Locks Object)

    % Disk Time

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

    计数器监视磁盘忙于读/写活动所用时间的百分比.在系统监视器中,PhysicalDisk: % Disk Time 计数器监视磁盘忙于读/写活动所用时间的百分比。如果 PhysicalDisk: % Disk Time 计数器的值较高(大于 90%),请检查 PhysicalDisk: Current Disk Queue Length 计数器了解等待进行磁盘访问的系统请求数量。等待 I/O 请求的数量应该保持在不超过组成物理磁盘的轴数的 1.5 到 2 倍。大多数磁盘只有一个轴,但独立磁盘冗余阵列 (RAID) 设 备通常有多个轴。硬件 RAID 设备在系统监视器中显示为一个物理磁盘。通过软件创建的多个 RAID 设备在系统监视器中显示为多个实例。

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

    可以使用 Current Disk Queue Length 和 % Disk Time 计数器的值检测磁盘子系统中的瓶颈。如果 Current Disk Queue Length 和 % Disk Time 计数器的值一直很高,则考虑下列事项:

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

    1.使用速度更快的磁盘驱动器。

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

    2.将某些文件移至其他磁盘或服务器。

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

    3.如果正在使用一个 RAID 阵列,则在该阵列中添加磁盘。

    八、 SQL Server:内存管理器对象(Memory Manager Object)

    计数器监视磁盘忙于读/写活动所用时间的百分比.在系统监视器中,PhysicalDisk: % Disk Time 计数器监视磁盘忙于读/写活动所用时间的百分比。
    如果 PhysicalDisk: % Disk Time 计数器的值较高(大于 90%),请检查 PhysicalDisk: Current Disk Queue Length 计数器了解等待进行磁
    盘访问的系统请求数量。等待 I/O 请求的数量应该保持在不超过组成物理磁盘的轴数的 1.5 到 2 倍。大多数磁盘只有一个轴,但独立磁盘冗余阵列 
    (RAID) 设备通常有多个轴。硬件 RAID 设备在系统监视器中显示为一个物理磁盘。通过软件创建的多个 RAID 设备在系统监视器中显示为多个实例。
    可以使用 Current Disk Queue Length 和 % Disk Time 计数器的值检测磁盘子系统中的瓶颈。如果 Current Disk Queue Length 和 % Disk Time 计数器的值一直很高,则考虑下列事项:
    1.使用速度更快的磁盘驱动器。
    2.将某些文件移至其他磁盘或服务器。
    3.如果正在使用一个 RAID 阵列,则在该阵列中添加磁盘。

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

    Avg.Disk Queue Length

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

    指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数

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

    Current Disk Queue Length

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

    指示被挂起的磁盘 I/O 请求的数量。如果这个值始终高于 2, 就表示产生了拥塞

    内存数量。

    Avg.Disk Bytes/Transfer

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

    写入或读取操作时向磁盘传送或从磁盘传出字节的平均数

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

    Disk Bytes/sec

    九、 SQL Server:S Q L统计对象(SQL Statistics Object)

    在读写操作中,从磁盘传出或传送到磁盘的字节速率

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

     

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

     

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

     

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

    Memory

    十、 逻辑磁盘对象(Logical Disk Object)

    Pages/sec

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

    被请求页面的数量.

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

    Available Bytes

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

    可用物理内存的数量

    百分比。

    Committed Bytes

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

    已分配给物理 RAM 用于存储或分配给页面文件的虚拟内存

    的百分比。

    Pool Nonpaged Bytes

    新葡亰496net,3. 磁盘时间百分比(%Disk Time) 选中的逻辑磁盘忙于服务读请求或写请求总共用的时间

    未分页池系统内存区域中的 RAM 数量

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

    Page Faults/sec

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

    是每秒钟出错页面的平均数量

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

     

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

     

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

     

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

    Network Interface

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

    Bytes Received/sec

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

    使用本网络适配器接收的字节数

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

    Bytes Sent/sec

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

    使用本网络适配器发送的字节数

    13. 磁盘读/秒(Disk Reads/sec) 逻辑磁盘上的读操作比率。

    Bytes Total/sec

    14. 磁盘写/秒(Disk Writes/sec) 逻辑磁盘上的写操作比率。

    使用本网络适配器发送和接收的字节数

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

    Server

    十一、 物理磁盘对象(PhysicalDisk Object)

    Bytes Received/sec

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

    把此计数器与网络适配器的总带宽相比较,确定网络连接是否产生瓶颈

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

     

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

     

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

     

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

    SQL Server Access Methods

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

    Page Splits/sec

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

    每秒由于索引页溢出而发生的页拆分数.如果发现页分裂的次数很多,考虑提高Index的填充因子.数据页将会有更多的空间保留用于做数据的填充,从而减少页拆分

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

    Pages Allocated/sec

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

    在此 SQL Server 实例的所有数据库中每秒分配的页数。这些页包括从混合区和统一区中分配的页

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

    Full Scans/sec

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

    每秒不受限制的完全扫描数. 这些扫描可以是基表扫描,也可以是全文索引扫描

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

     

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

     

    13. 磁盘读/秒(Disk Reads/sec) 物理磁盘上的读操作比率。

     

    14. 磁盘写/秒(Disk Writes/sec) 物理磁盘上的写操作比率。

    SQL Server: SQL Statistics

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

    Batch Requests/Sec

    十二、 内存

    每秒收到的 Transact-SQL 命令批数。这一统计信息受所有约束(如 I/O、用户数、高速缓存大小、请求的复杂程度等)影响。
    批处理请求数值高意味着吞吐量

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

    SQL Compilations/Sec

    1. 失效的页/秒(Page Faults/sec) 每秒由处理器处理的失效页的全部数量。当一个进程需要的代码或数据不在它的工作区(它的空间在物理内存中)中时,发生失效页。这个计数器包括硬的页失效(那些需要磁盘访问的)和软的页失效(在物理内存的其他地方发现了失效页)。

    每秒的编译数。表示编译代码路径被进入的次数。包括 SQL Server 中语句级重新编译导致的编译。当 SQL Server 用户活动稳定后,
    该值将达到稳定状态

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

    Re-Compilations/Sec

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

    每秒语句重新编译的次数。计算语句重新编译被触发的次数。一般来说,这个数最好较小,存储过程在理想情况下应该只编译一次,
    然后执行计划被重复使用. 如果该计数器的值较高,或许需要换个方式编写存储过程,从而减少重编译的次数

    4. 页/秒(Pages/sec) 是指为解决硬页错误从磁盘读取或写入磁盘的速度。这个计数器是可以显示导致系统范围延缓类型错误的主要指示器。它是 Memory\Pages Input/sec 和 Memory\Pages Output/sec 的总和。是用页数计算的,以便在不用做转换的情况下就可以同其他页计数如: Memory\Page Faults/sec 做比较,这个值包括为满足错误而在文件系统缓存(通常由应用程序请求)的非缓存映射内存文件中检索的页。

     

     

     

    SQL Server: Databases

    Log Flushes/sec

    每秒日志刷新数目

    Active Transactions

    数据库的活动事务数

    Backup/Restore Throughput/sec

    每秒数据库的备份和还原操作的读取/写入吞吐量。例如,并行使用多个备份设备或使用更快的设备时,可以测量数据库备份操作性能的变化情况。
    数据库的备份或还原操作的吞吐量可以确定备份和还原操作的进程和性能

     

     

     

    SQL Server General Statistics

    User Connections

    系统中活动的SQL连接数. 该计数器的信息可以用于找出系统的最大并发用户数

    Temp Tables Creation Rate

    每秒创建的临时表/表变量的数目

    Temp Tables For Destruction

    等待被清除系统线程破坏的临时表/表变量数

     

     

     

    SQL Server Locks

    Number of Deadlocks/sec

    指每秒导致死锁的锁请求数. 死锁对于应用程序的可伸缩性非常有害, 并且会导致恶劣的用户体验. 该计数器必须为0

    Average Wait Time (ms)

    每个导致等待的锁请求的平均等待时间

    Lock requests/sec

    锁管理器每秒请求的新锁和锁转换数. 通过优化查询来减少读取次数, 可以减少该计数器的值

     

     

     

    SQL Server:Memory Manager

    Total Server Memory (KB)

    从缓冲池提交的内存(这不是 SQL Server 使用的总内存)

    Target Server Memory (KB)

    服务器能够使用的动态内存总量

    SQL Cache Memory(KB)

    服务器正在用于动态 SQL 高速缓存的动态内存总数

    Memory Grants Pending

    指每秒等待工作空间内存授权的进程数. 该计数器应该尽可能接近0,否则预示可能存在着内存瓶颈

     

     

     

    SQL Server Buffer Manager

    Buffer Cache Hit Ratio

    缓存命中率,在缓冲区高速缓存中找到而不需要从磁盘中读取(物理I/O)的页的百分比. 如果该值较低则可能存在内存不足或不正确的索引

    Page Reads/sec

    每秒发出的物理数据库页读取数。此统计信息显示的是所有数据库间的物理页读取总数。由于物理 I/O 的开销大,可以通过使用更大的数据缓存、智能索引、更有效的查询或更改数据库设计等方法,将开销降到最低

    Page Writes/sec

    每秒执行的物理数据库页写入数

    Page Life Expectancy

    页若不被引用将在缓冲池中停留的秒数

    Lazy Writes/Sec

    每秒被缓冲区管理器的惰性编写器写入的缓冲区数

    Checkpoint Pages/Sec

    由要求刷新所有脏页的检查点或其他操作每秒刷新到磁盘的页数

     

     

     

    提示:

     

    当监视Windows Server或SQL Server以调查与性能有关的问题时,请首选关注一下硬件的三方面:

    (1) CPU(处理器使用率)

    (2) RAM(内存使用率)

    (3) HDD(磁盘活动即IO)

    3.建立监视

    下面要建立监视(我监视的HP Server配置为:Intel 4x4 x 3.0 GHz/RAM 16.0G,业务系统为OLTP).

    (1) 在performance->Performance Logs and Alerts->New Log Setting...

    (2) General Tab->Add Counters,添加需要监测的计数器(可参考如上的计数器列表)

    (3) General Tab->Interval,设置监测的时间间隔(默认是15s)

    (4) Log Files Tab->Log file type,选择Log File保存的方式(text File,Binary File,SQL Database),这里我选择text File(Tab delimited).

    (5) Schedule Tab,设置监测的开始时间及结束时间.

    4.分析(我做测试监测的时间段(2010/7/7 10:30-23:59))

    在监测一段时间之后,你就会得到Server重要的性能计数器信息,接下来就可以分析Server的性能. 我是借助数据透视图来做的,看起来会比较直观.

    4.1 CPU使用率.分析%Processor Time(_Total)(所用时间的百分比,横轴取时间,竖轴取%Processor Time)

    如下图在2010/7/7 10:30-12:40和2010/7/7 16:44-18:48这两段时间内CPU的使用率很高基本上都在50%以上.尤其在17:00-17:12,17:53-18:00CPU很繁忙,在这段时间会有大量的事务需要处理(T-SQL查询,SP,后台job, User操作等等).

    如果CUP使用率一直居高不下(持续80%到90%的状态),就要考虑升级CPU, 增加更多的处理器或者系统调优(建议先做系统调优,升级硬件需要增加额外的成本).

    新葡亰496net 6

    新葡亰496net 7

    4.2 磁盘I/O(%Disk Time,磁盘忙于读/写活动所用时间的百分比)

    监视磁盘活动涉及到两个主要方面:

    (1)监视磁盘I/O及检测是否有过度换页

    (2)隔离SQL Server产生的磁盘活动

    从做的数据透视图来看,磁盘I/O的读写很清闲,只在11:58,15:00,18:00,23:45左右(图上没有截出来)会有较大的IO.

    如果磁盘I/O很高(>90%),则考虑更换快速磁盘(如固态硬盘等).

    新葡亰496net 8

    请参考微软给出的解决方案:

    监视磁盘 I/O 及检测过度换页

    可以对下面两个计数器进行监视以确定磁盘活动:

    • PhysicalDisk: % Disk Time 
    • PhysicalDisk: Avg. Disk Queue Length 

    在系统监视器中,PhysicalDisk: % Disk Time 计数器监视磁盘忙于读/写活动所用时间的百分比。如果 PhysicalDisk: % Disk Time 计数器的值较高(大于 90%),请检查PhysicalDisk: Current Disk Queue Length 计数器了解等待进行磁盘访问的系统请求数量。等待 I/O 请求的数量应该保持在不超过组成物理磁盘的轴数的 1.5 到 2 倍。大多数磁盘只有一个轴,但独立磁盘冗余阵列 (RAID) 设备通常有多个轴。硬件 RAID 设备在系统监视器中显示为一个物理磁盘。通过软件创建的多个 RAID 设备在系统监视器中显示为多个实例。

    可以使用 Current Disk Queue Length 和 % Disk Time 计数器的值检测磁盘子系统中的瓶颈。如果 Current Disk Queue Length 和 % Disk Time 计数器的值一直很高,则考虑下列事项:

    • 使用速度更快的磁盘驱动器。
    • 将某些文件移至其他磁盘或服务器。
    • 如果正在使用一个 RAID 阵列,则在该阵列中添加磁盘。

    如果使用 RAID 设备,% Disk Time 计数器会指示大于 100% 的值。如果出现这种情况,则使用 PhysicalDisk: Avg.Disk Queue Length 计数器来确定等待进行磁盘访问的平均系统请求数量。

    I/O 依赖的应用程序或系统可能会使磁盘持续处于活动状态。

    监视 Memory: Page Faults/sec 计数器可以确保磁盘活动不是由分页导致的。在 Windows 中,换页的原因包括:

    • 配置进程占用了过多内存。
    • 文件系统活动。

    如果在同一硬盘上有多个逻辑分区,请使用 Logical Disk 计数器而非 Physical Disk 计数器。查看逻辑磁盘计数器有助于确定哪些文件被频繁访问。当发现磁盘有大量读/写活动时,请查看读写专用计数器以确定导致每个逻辑卷负荷增加的磁盘活动类型,例如,Logical Disk: Disk Write Bytes/sec。

    隔离 SQL Server 产生的磁盘活动

    可以进行监视以确定由 SQL Server 组件生成的 I/O 活动量的两个计数器为:

    • SQL Server:Buffer Manager:Page reads/sec 
    • SQL Server:Buffer Manager:Page writes/sec 

    在系统监视器中,这些计数器通过检查以下操作的性能监视由 SQL Server 组件生成的 I/O 活动量。

    • 向磁盘写入页
    • 从磁盘读取页

    如果这些计数器的值达到硬件 I/O 子系统的容量限制,则需要减小这些值,方法是调整应用程序或数据库以减少 I/O 操作(如索引覆盖、索引优化或规范化),增加硬件的 I/O 容量或添加内存

    4.3 缓存命中率(Buffer Cache Hit Ratio)

    根据检测的数据来看,缓存命中率基本上在99.99%-100%之间,表示数据缓存几乎满足所有的数据请求.

    4.4 页拆分(Page Splits/sec,每秒由于索引页益处而发生的页拆分数)

    如果页拆分很频繁,可以考虑增加填充因子(我设置的Index fill factor为85,也就是每个页会留有15%的空间做数据填充).

    从我做的检测来看,只有在很少的时间段内会有较大的页拆分,此时可能会有大量的数据事务操作.总体来看性能还好.

    新葡亰496net 9

    4.5 每秒日志刷新数目(Log Flushes/sec)

    日志刷新发生在当transaction提交, 数据从日志缓存写入磁盘日志文件时. 应该尽可能的减少日志刷新.

    如果检测到数值一直很高的话,说明transaction非常活跃,就要减少transaction数.

    这里有一个简单的示例来说明:

    比如说要向Table中Insert 1w条数据

    做法1: 一条一条的Insert,一个transaction一条. 会产生1w个log flushes

    做法2: 1w条数据在一个transaction Insert.只产生1个log flushes

    明显的第二种产生的日志刷新会大大减少,相应的磁盘I/O也大大减少.从而有助于提高性能.

    新葡亰496net 10

    总结:

    (1). 还有很多的日志记录没有做一一的简单分析.

    (2). Performance Monitor只是提供一个方法来帮助发现问题,提供一个性能优化的方向. 一旦影响性能的问题找到了,就可以从这个方向来着手处理.

    (3). 网上有很多性能检测的工具,大抵应该是把如上所做的工作封装起来,并且UI上面已经分析好,更加的直观.

    本文由新葡亰496net发布于网络数据库,转载请注明出处:新葡亰496net:windows质量监视器常用流量计,学习

    关键词: