系统资源详解

 System(系统)
   %Total Processor Time
系统中所有处理器都处于繁忙状态的时间百分比,对于多处理器系统来说,该值可以反映所有处理器的平均繁忙状态,该值为100%,如果有一半的处理器为繁忙状态,该值为50%服务器。器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率.
   File Data Operations/sec
计算机对文件系统进行读取和写入操作的频率,但是不包括文件控制操作
   Process Queue Length
线程在等待分配CPU资源所排队列的长度,此长度不包括正在占有CPU资源的线程。如果该队列的长度大于处理器个数+1,就表示处理器有可能处于阻塞状态(参考值:<=处理器个数+1)


  Processor(处理器)
  %Processor Time
CPU利用率,该计数器最为常用,可以查看处理器是否处于饱和状态,如果该值持续超过 95%,就表示当前系统的瓶颈为CPU,可以考虑增加一个处理器或更换一个性能更好的处理器。(参考值:<80%)
  %Priviliaged Time
CPU在特权模式下处理线程所花的时间百分比。一般的系统服务,进城管理,内存管理等一些由操作系统自行启动的进程属于这类
  %User Time
与%Privileged Time计数器正好相反,指的是在用户状态模式下(即非特权模式)的操作所花的时间百分比。如果该值较大,可以考虑是否通过算法优化等方法降低这个值。如果该服务器是数据库服务器,导致此值较大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间,此时可以考虑对数据库系统进行优化。表示耗费CPU的数据库操作,如排序,执行aggregate functions等。如果该值很高,可考虑增加索引,尽量使用简单的表联接,水平分割大表格等方法来降低该值。
  %DPC Time
处理器在网络处理上消耗的时间,该值越低越好。越低越好。在多处理器系统中,如果这个值大于50%并且Processor:% Processor Time非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。


  Memory(内存)
  Page Faults/sec
当处理器在内存中读取某一页出现错误时,就会产生缺页中断,也就是 page Fault。如果这个页位于内存的其他位置,这种错误称为软错误,用Transition Fault/sec 来衡量;如果这个页位于硬盘上,必须从硬盘重新读取,这个错误成为硬错误。硬错误会使系统的运行效率很快将下来。Page Faults/sec这个计数器就表示每秒钟处理的错误页数,包括硬错误和软错误。
  Page Input/sec
表示为了解决硬错误而写入硬盘的页数(参考值:>=Page Reads/sec)
  Page Reads/sec
表示为了解决硬错误而从硬盘上读取的页数。
  Page/sec
表示为了解决硬错误而从硬盘上读取或写入硬盘的页数(参考值:00~20)
  Pages per second:
每秒钟检索的页数。该数字应少于每秒一页Working set:理线程最近使用的内存页,反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存,页就会被留在工作集中,当自由内存少于一个特定的阈值时,页就会被清除出工作集。
  Available Mbytes
剩余的可用物理内存,单位是兆字节(参考值:>=10%)用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
  Cathe Bytes
文件系统的缓存(默认为50%的可用物理内存)
  Process(进程)
  private Bytes
进程无法与其他进程共享的字节数量。该计数器的值较大时,有可能是内存泄露的信号
  Work set
最近处理线程使用的内存页


  PhysicalDisk(磁盘)
  %Disk Time
表示磁盘驱动器为读取或写入请求提供服务所用的时间百分比,如果只有%Disk Time比较大,硬盘有可能是瓶颈。指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大,那么硬盘不是瓶颈。如果只有%Disk Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器之前,请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%,则可能是内存泄漏。应当总小于90%
  Average Disk Queue Length
表示磁盘读取和写入请求提供服务所用的时间百分比,可以通过增加磁盘构造磁盘阵列来提高性能(<=磁盘数的2倍)读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能,可增加磁盘。注意:一个Raid Disk实际有多个磁盘。不应当超过物理磁盘数量的2倍,正常值<0.5
  Average Disk Read Queue Length
表示磁盘读取请求的平均数
  Average Disk write Queue Length
表示磁盘写入请求的平均数
  Average Disk sec/Read
磁盘中读取数据的平均时间,单位是秒
  Average Disk sec/Transer
磁盘中写入数据的平均时间,单位是秒,一般来说,定义该值小于15ms最为优异,介于15-30ms之间为良好,30-60ms之间为可以接受,超过60ms则需要考虑更换硬盘或硬盘的RAID方式了
  %Disk reads/sec(physicaldisk_total):
每秒读硬盘字节数. 该指标应总小于磁盘I/O子系统的容量
  %Disk write/sec(physicaldisk_total):
每秒写硬盘字节数. 该指标应当总小于硬盘I/O子系统的容量
  Disk Bytes/sec
指在进行写入或读取操作时从磁盘上传送或传出的字节速率。
此值取决于硬盘的速度
  Disk Transfers/sec
指在此盘上读取/写入操作速率。
正常值<(Disk Bytes/sec)/3,此值过大表示系统要求的IO速度已接近硬盘的最大速度,要更换更快的硬盘

  Network Interface(网络)
  Byte Total/sec
表示网络中接受和发送字节的速度,可以用该计数器来判断网络是否存在瓶颈(参考值:该计数器和网络带宽相除,<50%)
判断瓶颈
  判断应用程序的问题
  如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.
  从图的整体看.context switches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.
  判断CPU瓶颈
如果processor queue length显示的队列长度保持不变(>=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.
 
%processor time平均值大于95,processor queue length大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(%User Time)
过高的系统占用CPU时间(%Priviliaged Time:长期大于90%或者95%)
长时间的有很长的运行进程队列(Process Queue Lengt:大于处理器个数+1)
 
  判断内存泄露问题
  内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\private bytes计数器和process\working set 计数器的值往往会升高,同时avaiable bytes的值会降低.内存泄漏应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.
 
图中可以看到该程序并不存在内存泄露的问题.内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的关注.
 Windows资源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,则很可能存在内存泄漏。
 
  判断内存不足
 如果队列长度(Avg.Disk Queue Length)增加的同时页面读取速率(Page Reads/sec)并未降低,则内存不足。
如果Available Mbytes(剩余物理内存数)的值很小(4 MB 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
  硬件问题
请观察 Processor\ Interrupts/sec 计数器的值,该计数器测量来自输入/输出 (I/O) 设备的服务请求的速度。如果此计数器的值明显增加,而系统活动没有相应增加,则表明存在硬件问题。
 
  I/O资源成为系统性能的瓶颈的征兆
IO Data Bytes/sec(处理从I/O操作读取/写入字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备I/O的活动计数。)
IO Data Operations/sec
IO Other Bytes/sec
IO Other Operations/sec
IO Read Bytes/sec(每秒IO读取字节数)
IO Read Operations/sec
IO Write Bytes/sec(每秒IO写出字节数)
IO Write Operations/sec
 
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(Physical Disk\ Current Disk Queue Length,正在等待磁盘访问的系统请求数量)
等待磁盘I/O的时间所占的百分率太高(Average Disk Queue Length)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列,但CPU却空闲(Process Queue Length)
 
在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数
  监视磁盘的使用情况
监视磁盘活动涉及两个主要方面:
监视磁盘 I/O 及检测过度换页
隔离 SQL Server 产生的磁盘活动
  监视磁盘 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。
  判断磁盘瓶颈
Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。
  Physical Disk\ Disk Reads/sec and Disk Writes/sec
  Physical Disk\ Current Disk Queue Length
  Physical Disk\ % Disk Time
  LogicalDisk\ % Free Space
  测试磁盘性能时,将性能数据记录到另一个磁盘或计算机,以便这些数据不会干扰您正在测试的磁盘。
  可能需要观察的附加计数器包括 Physical Disk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer,和Disk Bytes/sec。
  Avg.Disk sec/Transfer 计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。对于大多数磁盘,较高的磁盘平均传送时间是大于 0.3 秒。
  也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示该磁盘驱动器通常运行良好;如果应用程序正在访问磁盘,则会产生较低的值。例如,随机访问磁盘的应用程序会增加平均 Disk sec/Transfer 时间,因为随机传送需要增加搜索时间。
  Disk Bytes/sec 提供磁盘系统的吞吐率。
  决定工作负载的平衡要平衡网络服务器上的负载,需要了解服务器磁盘驱动器的繁忙程度。使用 Physical Disk\ %Disk Time 计数器,该计数器显示驱动器活动时间的百分比。如果 % Disk Time 较高(超过90%),请检查 Physical Disk\ Current Disk Queue Length 计数器以查看正在等待磁盘访问的系统请求数量。等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到2倍。
  尽管廉价磁盘冗余阵列 (RAID) 设备通常有多个主轴,大多数磁盘有一个主轴。硬件 RAID设备在“系统监视器”中显示为一个物理磁盘;通过软件创建的 RAID 设备显示为多个驱动器(实例)。可以监视每个物理驱动器(而不是 RAID)的 Physical Disk 计数器,也可以使用 _Total 实例来监视所有计算机驱动器的数据。
使用 Current Disk Queue Length 和 % Disk Time 计数器来检测磁盘子系统的瓶颈。如果Current Disk Queue Length 和 % Disk Time 的值始终较高,可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。


如何调优
  CPU问题
a)        考虑使用更高级的CPU代替目前的CPU
b)       对于多个CPU,考虑CPU之间的负载分配
c)       考虑在其他体系上设计系统,例如增加前置机、设置并行服务器等
  内存和高速缓存
a)      内存的优化包括操作系统、数据库、应用程序的内存优化
b)     过多的分页与交换可能降低系统的性能
c)     内存分配也是影响系统性能的主要原因
d)     保证保留列表具有较大的邻接内存块
e)      调整数据块缓存区大小(用数据块的个数表示)是一个重要内容
f)      将最频繁使用的数据保存在存储区中
 磁盘(I/O)资源问题
a)      磁盘读写进度对数据库系统是至关重要的,数据库对象在物理设备上的合理分布能改善性能
b)     磁盘镜像会减慢磁盘写的速度
c)     通过把日志和数据库对象分布在独立的设备上,可以提高系统的性能
d)     把不同的数据库放在不同的硬盘上,可以提高读写速度。建议把数据库、回滚段、日志放在不同的设备上
e)      把表放在一块硬盘上,把非簇的索引放在另一块硬盘上,保证物理读写更快。
 调整配置参数
a)      包括操作系统和数据库的参数配置
b)     并行操作资源限制的参数(并发用户的数目、会话数)
c)     影响资源开销的参数
d)     与I/O有关的参数
 优化应用系统网络设置
a)        可以通过数组接口来减少网络呼叫。不是一次提取一行,而是在单个往来往返中提取10行,这样效率较高
b)       调整会话数据单元的缓冲区大小
c)       共享服务进程比专用服务进程提供更好的性能

 

SQLServer性能计数器:
Access Methods(
访问方法) 用于监视访问数据库中的逻辑页的方法。
. Full Scans/sec(
全表扫描/秒) 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高,应该分析你的查询以确定是否确实需要全表扫描,以及S Q L查询是否可以被优化。


. Page splits/sec(
页分割/秒)由于数据更新操作引起的每秒页分割的数量。


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

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

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

.Buffer Cache Hit Ratio. 缓冲池Buffer Cache/Buffer Pool)中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后,这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多,一般希望这一数值高一些。通常,可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定,但比率最好为90%或更高。增加内存直到这一数值持续高于90%,表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。

. Lazy Writes/sec(惰性写/)惰性写进程每秒写的缓冲区的数量。值最好为0

 

Cache Manager(高速缓存管理器)对象提供计数器,用于监视 Microsoft&reg; SQL Server™ 如何使用内存存储对象,如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。

. Cache Hit Ratio(高速缓存命中率,所有Cache”的命中率。在SQLServer中,Cache可以包括LogCache,Buffer Cache以及ProcedureCache,是一个总体的比率。) 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效,这是一个非常好的计数器。如果这个值很低,持续低于80%,就需要增加更多的内存。


Latches(
闩) 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况,有助于查明性能瓶颈。

. Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒))一个SQL Server线程必须等待一个闩的平均时间,以毫秒为单位。如果这个值很高,你可能正经历严重的竞争问题。

. Latch Waits/sec (闩等待/)在闩上每秒的等待数量。如果这个值很高,表明你正经历对资源的大量竞争。


Locks(
锁) 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。例如,如果一个排它 (X) 锁被一个事务加在某一表的某一行上,在这个锁被释放前,其它事务都不可以修改这一行。尽可能少使用锁可提高并发性,从而改善性能。可以同时监视 Locks 对象的多个实例,每个实例代表一个资源类型上的一个锁。
. Number ofDeadlocks/sec(
死锁的数量/秒) 导致死锁的锁请求的数量
. Average WaitTime(ms) (
平均等待时间(毫秒)) 线程等待某种类型的锁的平均等待时间
. LockRequests/sec(
锁请求/秒) 每秒钟某种类型的锁请求的数量。


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

监视IIS需要的一些计数器 
InternetInformation Services Global:

File Cache Hits %、File CacheFlushes、File CacheHits
File Cache Hits %
是全部缓存请求中缓存命中次数所占的比例,反映了IIS的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站,该值应该保持在80%左右。而FileCache Hits是文件缓存命中的具体值,File CacheFlushes是自服务器启动之后文件缓存刷新次数,如果刷新太慢,会浪费内存;如果刷新太快,缓存中的对象会太频繁的丢弃生成,起不到缓存的作用。通过比较File Cache Hits 和File CacheFlushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值,可以得到一个适当的刷新值(参考IIS的设置ObjectTTL、MemCacheSize 、MaxCacheFileSize)
Web Service:

Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused
:数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
Not Found Errors
:显示由于被请求文件
无法找到而无法由服务器满足的请求数(HTTP状态代码404)

 

SQL Server
注:以下指标取自SQL Server自身提供的性能计数器。
指标名称:指标描述:指标范围:指标单位:
1.SQL Server中访问方法(Access Methods)对象包含的性能计数器
指标名称:全表扫描/秒(Full Scans/sec)
指标描述:指每秒全表扫描的数量。全表扫描可以是基本表扫描或全索引扫描。由于全表扫描需要耗费大量时间,因此全表扫描的频率过高的话,会影响性能。
指标范围:如果该指标的值比1或2高,应该分析设计的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
指标单位:次数/秒


2.SQL Server中缓冲器管理器(Buffer Manager)对象包含的性能计数器
指标名称:缓冲区高速缓存命中率 (Buffer Cache Hit Ratio %)
指标描述:指在缓冲区高速缓存中找到而不需要从磁盘中读取的页的百分比。该比率是缓存命中总次数与缓存查找总次数之比。经过很长时间后,该比率的变化很小。由于从缓存中读取数据比从磁盘中读


取数据的开销小得多,一般希望该比率高一些。
指标范围:该指标的值最好为90% 或更高。通常可以通过增加 SQL Server 可用的内存数量来提高该指标的值。增加内存直到这指标的值持续高于90%,表示90% 以上的数据请求可以从数据缓冲区中获得


所需数据。指标单位:%


指标名称:读的页/秒(Page Reads/sec)
指标描述:指每秒发出的物理数据库页读取数。该指标主要考察数据库从磁盘读取数据的频率。因为物理I/O 会耗费大量时间,所以应尽可能地减少物理I/O 以提高性能。
指标范围:该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,以降低该指标的值。
指标单位:个数/秒


指标名称:写的页/秒(Page Writes/sec)
指标描述:指每秒执行的物理数据库写的页数。该指标主要考察数据库向磁盘写入数据的频率。因为物理I/O 会耗费大量时间,所以应尽可能地减少物理I/O 以提高性能。
指标范围:该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,以降低该指标的值。
指标单位:个数/秒


指标名称:惰性写/秒(Lazy Writes/sec)
指标描述:指每秒被缓冲区管理器的惰性编写器写入的缓冲区数。惰性编写器是一个系统进程,用于成批刷新脏的老化的缓冲区(包含更改的缓冲区,必须将这些更改写回磁盘,才能将缓冲区重用于其他


页),并使它们可用于用户进程。
指标范围:该指标的值最好为0。
指标单位:个数/秒


3.SQL Server中高速缓存管理器(Cache Manager)对象包含的性能计数器
指标名称:高速缓存命中率 (Cache Hit Ratio %)
指标描述:指高速缓存命中次数和查找次数的比率。在SQL Server中,Cache包括Log Cache,Buffer Cache以及Procedure Cache,该指标是指所有Cache的命中率,是一个总体的比率。
指标范围:该指标的值越高越好。如果该指标的值持续低于80%,就需要增加更多的内存。
指标单位:%


4.SQL Server中闩(Latches)对象包含的性能计数器
指标名称:平均闩等待时间(毫秒)(Average LatchWait Time(ms))
指标描述:指一个SQL Server线程必须等待一个闩的平均时间。
指标范围:如果该指标的值很高,则系统可能正经历严重的资源竞争问题。
指标单位:毫秒


指标名称:闩等待/秒(Latch Waits/sec)
指标描述:指在一个闩上每秒的平均等待数量。
指标范围:如果该指标的值很高,则系统可能正经历严重的资源竞争问题。
指标单位:个数/秒


5.SQL Server中锁(Locks)对象包含的性能计数器
指标名称:死锁的数量/秒(Number of Deadlocks/sec)
指标描述:指每秒导致死锁的锁请求数。
指标范围:锁加在SQL Server资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。应尽可能少使用锁以提高事务的并发性,从而改善性能。
指标单位:个数/秒


指标名称:平均等待时间(毫秒)(Average WaitTime(ms))
指标描述:指线程等待某种类型的锁的平均等待时间。
指标范围:同上
指标单位:毫秒


指标名称:锁请求/秒(Lock Requests/sec)
指标描述:指每秒钟某种类型的锁请求的数量。
指标范围:同上
指标单位:个数/秒


Oracle
注:以下指标取自Oracle的性能分析工具Statspack所提供的性能分析指标。
指标名称指标描述指标范围指标单位
1.关于实例效率(Instance Efficiency Percentages)的性能指标
指标名称:缓冲区未等待率(Buffer Nowait %)
指标描述:指在缓冲区中获取Buffer的未等待比率。
指标范围:该指标的值应接近100%,如果该值较低,则可能要增大buffer cache。
指标单位:%


指标名称:Redo缓冲区未等待率(Redo NoWait %)
指标描述:指在Redo缓冲区获取Buffer的未等待比率。
指标范围:该指标的值应接近100%,如果该值较低,则有2种可能的情况:
1)online redo log没有足够的空间;
2)log切换速度较慢。
指标单位:%


指标名称:缓冲区命中率(Buffer Hit %)
指标描述:指数据块在数据缓冲区中的命中率。
指标范围:该指标的值通常应在90%以上,否则,需要调整。如果持续小于90%,可能要加大db_cache_size。但有时,缓存命中率低并不意味着cache设置小了,可能是潜在的全表扫描降低了缓存命中率。
指标单位:%


指标名称:内存排序率(In-memory Sort %)
指标描述:指排序操作在内存中进行的比率。当查询需要排序的时候,数据库会话首先选择在内存中进行排序,当内存大小不足的时候,将使用临时表空间进行磁盘排序,但磁盘排序效率和内存排序效率


相差好几个数量级。
指标范围:该指标的值应接近100%,如果指标的值较低,则表示出现了大量排序时的磁盘I/O操作,可考虑加大sort_area_size参数的值。
指标单位:%


指标名称:共享区命中率(Library Hit %)
指标描述:该指标主要代表sql在共享区的命中率。
指标范围:该指标的值通常应在95%以上,否则需要考虑加大共享池(修改shared_pool_size参数值),绑定变量,修改cursor_sharing等参数。
指标单位:%


指标名称:软解析的百分比(Soft Parse %)
指标描述:该指标是指Oracle对sql的解析过程中,软解析所占的百分比。软解析(soft parse)是指当Oracle接到Client提交的Sql后会首先在共享池(Shared Pool)里面去查找是否有之前已经解析好


的与刚接到的这一个Sql完全相同的Sql。当发现有相同的Sql就直接用之前解析好的结果,这就节约了解析时间以及解析时候消耗的CPU资源。
指标范围:该指标的值通常应在95%以上,如果低于80%,那么就可能sql基本没被重用,sql没有绑定变量,需要考虑绑定变量。
指标单位:%


指标名称:闩命中率 (Latch Hit %)
指标描述:指获得Latch的次数与请求Latch的次数的比率。
指标范围:该指标的值应接近100%,如果低于99%,可以考虑采取一定的方法来降低对Latch的争用。
指标单位:%


指标名称:SQL语句执行与解析的比率(Execute to Parse %)
指标描述:指SQL语句执行与解析的比率。SQL语句一次解析后执行的次数越多,该比率越高,说明SQL语句的重用性很好。
指标范围:该指标的值应尽可能到高,如果过低,可以考虑设置session_cached_cursors参数。
指标单位:%


指标名称:共享池内存使用率(Memory Usage %)
指标描述:该指标是指在采集点时刻,共享池(share pool)内存被使用的比例。
指标范围:这指标的值应保持在75%~90%,如果这个值太低,就浪费内存,如果太高,会使共享池外部的组件老化,如果SQL语句被再次执行,则就会发生硬分析。
指标单位:%


2.关于等待事件(Wait events)的性能指标
指标名称:文件分散读取(db file scattered read (cs))
指标描述:该等待事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的,通常情况下它不可能被放入连续的缓冲区中,所以就散布在缓冲区的缓存中。
指标范围:如果这个等待事件比较显著,可能说明对于某些全表扫描的表,没有创建索引或没有创建合适的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效,但如果出现这种等待时,最好检


查一下这些全表扫描是否必要。
指标单位:厘秒


指标名称:文件顺序读取(db file sequential read (cs))
指标描述:该等待事件通常与单个数据块相关的读取操作有关。
指标范围:如果这个等待事件比较显著,可能表示在多表连接中,表的连接顺序存在问题,或者可能不合适地使用了索引。对于大量事务处理、调整良好的系统,这一数值大多是很正常的,但在某些情况


下,它可能暗示着系统中存在问题。应检查索引扫描,以保证每个扫描都是必要的,并检查多表连接的连接顺序。另外DB_CACHE_SIZE 也是这些等待出现频率的决定因素。
指标单位:厘秒


指标名称:缓冲区忙(buffer busy (cs))
指标描述:当一个会话想要访问缓存中的某个块,而这个块正在被其它会话使用时,将会产生该等待事件。这时候,其它会话可能正在从数据文件向缓存中的这个块写入信息,或正在对这个块进行修改。


指标范围:出现这个等待事件的频度不应大于1%。如果这个等待事件比较显著,则需要根据等待事件发生在缓存中的哪一块(如字段头部、回退段头部块、回退段非头部块、数据块、索引块等),采取相


应的优化方法。
指标单位:厘秒


指标名称:(enqueue (cs))
指标描述:enqueue 是一种保护共享资源的锁定机制。该锁定机制保护共享资源,如记录中的数据,以避免两个人在同一时间更新同一数据。enqueue 包括一个排队机制,即FIFO(先进先出)排队机制。注


意:Oracle 的latch 机制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。
指标范围:如果enqueue等待事件比较显著,则需要根据enqueue等待类型,采取相应的优化方法。
指标单位:厘秒


指标名称:闩释放(latch free (cs))
指标描述:该等待事件意味着进程正在等待其他进程已持有的latch。
指标范围:latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构。latch 就像是一种快速地被获取和释放的内存锁。latch 用于防止共享内存结构被


多个用户同时访问。
对于常见的Latch等待通常的解决方法:
1)Share pool latch:在OLTP应用中应该更多的使用绑定变量以减少该latch的等待。
2)Library cache latch:同样的需要通过优化sql语句使用绑定变量减少该latch的等待。
指标单位:厘秒


指标名称:日志文件同步(log file sync (cs))
指标描述:这个等待事件是指当一个会话完成一个事务(提交或者回滚数据)时,必须等待LGWR进程将会话的redo信息从日志缓冲区写到日志文件后,才能继续执行下去。
指标范围:这个等待事件的时间过长,可能是因为commit太频繁或者lgwr进程一次写日志的时间太长(可能是因为一次log io size太大),可调整 _log_io_size,结合log_buffer,使得 


(_log_io_size*db_block_size)*n = log_buffer,这样可避免和增大log_buffer引起冲突,或者可以将日志文件存放在高速磁盘上
指标单位:厘秒


DB2
注:以下指标取自DB2的运行状况指示器所包含的各项指标。
指标名称指标描述指标范围指标单位
1.表空间存储器运行状况指示器
指标名称:自动调整大小表空间利用率 (ts.ts_util_autoResize %)
指标描述:该指标用来跟踪每个DMS表空间的存储器消耗情况,这些DMS表空间已经定义了最大大小,并且可以自动调整大小,达到最大大小时,则认为DMS表空间已满。
指标范围:该指标是用消耗的最大表空间存储器所占的百分比度量的。高百分比指示表空间接近已满程度。该指标的附加信息中包括的短期增长率和长期增长率可用来确定,当前增长率是短期畸变还是与


长期增长一致。附加信息中对离空间已满所余时间的计算可以预测达到最大大小所余的时间。
指标单位:%


指标名称:表空间利用率(ts.ts_util %)
指标描述:如果在表空间上没有启用自动调整大小,则可用该指标来跟踪每个DMS表空间的存储器消耗情况;反之,DB2不会评估该指标。
指标范围:该指标以消耗空间的百分比来度量。高百分比指示未达到该指标的最优运行状况。该指标的附加信息中包括的短期增长率和长期增长率可用来确定,当前增长率是短期畸变还是与长期增长一致


。附加信息中对离空间已满所余时间的计算可以预测达到最大大小所余的时间。
指标单位:%


指标名称:表空间容器利用率(ts.ts_op_status %)
指标描述:该指标用来跟踪未使用自动存储器的每个SMS表空间的存储器消耗情况。如果对其定义容器的任何文件系统上都没有更多空间,则认为SMS表空间已满。如果文件系统上没有可用空间可供扩展


SMS容器,则表示关联表空间已满。
指标范围:该指标以消耗空间的百分比来度量。高百分比指示未达到该指标的最优运行状况。该指标的附加信息中包括的短期增长率和长期增长率可用来确定,当前增长率是短期畸变还是与长期增长一致


。附加信息中对离空间已满所余时间的计算可以预测达到最大大小所余的时间。
指标单位:%


2.排序运行状况指示器
指标名称:专用排序内存利用率(db2.sort_privmemUtil %)
指标描述:该指标用来跟踪专用排序内存的利用率。
指标范围:如果该指标的值等于或超过100%,则说明已达到了排序堆阀值,没有足够的堆空间可用于执行排序。“阀值后排序数”快照监视元素可在调整该指标值时作为参考。该监视元素记录了超过排序


堆阀值后请求堆的排序数。
指标单位:%


指标名称:共享排序内存利用率(db2.sort_shrmemUtil %)
指标描述:该指标用来跟踪共享排序内存的利用率。
指标范围:如果该指标的值等于或超过100%,则说明已达到了排序堆阀值,没有足够的堆空间可用于执行排序。
建议使用自调整内存功能,以根据当前工作负载的需要自动分配排序内存资源。
指标单位:%


指标名称:溢出排序百分比(db.spilled_sorts %)
指标描述:该指标值是指用完排序堆后可能需要磁盘空间以供临时存储器使用的总排序数占已执行的排序总数的利率。
指标范围:该指标值应为0,因为溢出至磁盘的排序可能导致严重的性能下降。
建议使用自调整内存功能,以根据当前工作负载的需要自动分配排序内存资源。
指标单位:%


3.日志记录运行状况指示器
指标名称:日志利用率(db.log_util %)
指标描述:该指标用来跟踪在数据库中使用的总活动日志空间量。
指标范围:该指标以消耗空间的百分比来度量。高百分比指示空间消耗接近已满程度。这时可调整一些与日志有关的数据库配置参数的值。这些参数的值显示在附加信息中。
指标单位:%


指标名称:日志文件系统利用率(db.log_fs_util %)
指标描述:该指标用来跟踪事务日志所在的文件系统的充满程度。如果文件系统上没有空间,则DB2可能无法创建新的日志文件。
指标范围:该指标以消耗空间的百分比来度量。高百分比指示文件系统中的可用空间量已接近于0。这时可调整一些与日志有关的数据库配置参数的值。这些参数的值显示在附加信息中。
指标单位:%


4.应用程序并发性运行状况指示器
指标名称:死锁率(db.deadlock_rate%)
指标描述:该指标用来跟踪死锁出现在数据库上的比率以及应用程序遇到争用问题的等级。
指标范围:该指标值应为0,该值越高,则争用等级就越高。
指标单位:%


指标名称:锁定列表利用率(db.locklist_util %)
指标描述:该指标用来跟踪要使用的锁定列表内存量。每个数据库有一个锁定列表,锁定列表包含由同时连接至数据库的所有应用程序挂起的锁定。这是对锁定列表内存设置的限制。一旦达到该限制,就


会因为下列情况而使得性能下降:
1)锁定升级将行锁定转换为表锁定,从而降低了数据库中的共享对象的并行性;
2)因为应用程序等待有限数目的表锁定,所以应用程序间会出现更多死锁。因此将回滚事务。
指标范围:该指标以消耗内存的百分比来度量,出现高百分比表示状况不佳。
建议使用自调整内存功能,以根据当前工作负载的需要自动分配排序内存资源。
指标单位:%


指标名称:等待锁定的应用程序的百分比(db.apps_waiting_locks %)
指标描述:该指标度量所有当前执行的等待锁定的应用程序所占的百分比。
指标范围:高百分比可能指示应用程序遇到并行性问题,这对性能有负面影响。
指标单位:%


5.程序包和目录高速缓存,以及工作空间运行状况指示器
指标名称:目录高速缓存命中率(db.catcache_hitratio %)
指标描述:该指标用于指示目录高速缓存对避免对磁盘上的目录的实际访问所起到的帮助作用。
指标范围:高命中率指示在避免实际磁盘I/O访问方面很成功。
指标单位:%


指标名称:程序包高速缓存命中率(db.pkgcache_hitratio %)
指标描述:该指标用于指示程序包高速缓存对避免从系统目录重新装入静态SQL的程序包和段以及避免重新编译动态SQL语句所起到的帮助作用。
指标范围:高命中率指示在避免从系统目录重新装入静态SQL的程序包和段以及避免重新编译动态SQL语句方面很成功。
指标单位:%


指标名称:共享工作空间命中率(db.shrworkspace_hitratio %)
指标描述:该指标用于指示共享SQL工作空间对避免初始化要执行的SQL语句的各段所起到的帮助作用。
指标范围:高命中率指示在避免初始化要执行的SQL语句的各段方面很成功。
指标单位:%


6.内存运行状况指示器
指标名称:数据库堆利用率(db.db_heap_util %)
指标描述:该指标用来跟踪基于带有标识SQLM_HEAP_DATABASE的内存池的监视器堆内存的消耗。
指标范围:一旦此百分比达到最大值100%,查询和操作可能会因为没有堆可用而失败。
指标单位:%


 

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Odoo 是一个开源的企业资源计划(ERP)系统,它提供了一套完整的商业应用程序,包括销售、采购、库存管理、生产管理、财务管理、人力资源管理等。下面是 Odoo 的系统架构详解: 1. 前端:Odoo 使用了基于 Web 技术的前端框架,提供了直观、用户友好的界面。前端部分主要负责与用户交互,并将用户输入的数据发送给后端进行处理。 2. Web 服务器:Odoo 支持多种 Web 服务器,如 Nginx、Apache 等。Web 服务器主要负责接收用户请求,并将请求转发给 Odoo 服务器进行处理。 3. Odoo 服务器:Odoo 服务器是整个系统的核心组件,它负责处理用户请求,并根据请求的类型进行相应的操作。Odoo 服务器采用了模块化的架构,每个功能模块都可以独立安装、升级和卸载。 4. 数据库:Odoo 使用关系型数据库来存储数据,常用的数据库包括 PostgreSQL、MySQL 等。所有的数据都存储在数据库中,包括用户信息、产品信息、订单信息等。 5. 模块:Odoo 的功能被组织成多个模块,每个模块负责一个特定的功能领域。例如,销售模块负责管理销售流程,采购模块负责管理采购流程等。用户可以根据自己的需求选择安装相应的模块。 6. 业务逻辑:Odoo 的每个模块都包含了一套完整的业务逻辑。例如,在销售模块中,用户可以创建销售订单、确认订单、生成发票等。这些业务逻辑被封装在模块中,并通过 Odoo 服务器进行处理。 7. API:Odoo 提供了一组丰富的 API,使开发人员能够通过编程的方式来与系统进行交互。开发人员可以使用 API 创建新的模块、扩展现有模块的功能,或者与其他系统进行集成。 总结来说,Odoo 的系统架构包括前端、Web 服务器、Odoo 服务器数据库、模块、业务逻辑和 API。它提供了一个灵活、可扩展的平台,满足企业各种不同的业务需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值