loadrunner监控常用性能指标
LoadRunner性能测试指标参考
性能测试指标参考目录1术语 (2)1.1响应时间 (2)1.2并发用户数 (2)1.3在线用户数 (2)1.4吞吐量 (3)2 Vuser图 (3)2.1 “运行Vuser ”图（Running Vusers） (3)2.2 “集合”图(Rendezvous) (3)3 错误图 (3)3.1 “每秒错误数（按描述）”图（Error Statistics） (3)4 事务图 (4)4.1 “平均事务响应时间”图（Average Transaction Response Time） (4)4.2“负载下的事务响应时间”图（Running Vuser –Average Transaction Response Time） (4)4.3“页面细分”图（Web Page Diagnostics图） (5)4.4“每秒事务数”（Transactions per second 简称：TPS） (6)5 Web资源图 (6)5.1“每秒点击次数”图（Hits per Second） (6)5.2“吞吐量”图（Throughput） (6)6 系统资源图 (6)6.1 LoadRunner下监控的UNIX资源指标 (6)6.1.1平均负载（Average load） (6)6.1.2 CPU利用率（CPU utilization） (7)6.1.3 每秒传入的包数（Paging rate） (7)6.2使用NMON工具监控Linux资源 (7)6.2.1 系统资源汇总（SYS_SUMM） (7)6.2.2 磁盘资源汇总（DISK_SUMM） (8)6.2.3 内存资源（MEM） (8)7 网络监控器图 (9)7.1 “网络延迟时间”图（Network Delay Time） (9)8 数据库服务器资源图 (10)8.1 Oracle服务器监控度量 (10)8.1.1 添加Oracle自定义计数器 (11)8.1.2 性能分析工具Statspack所提供的性能分析指标 (15)8.2 SQL Server服务器监控度量 (18)1术语1.1响应时间响应时间是从请求到响应所需时间，从客户端请求开始，结束于来自服务器的响应并呈现页面的时间。
如何进行系统性能监控与调优
如何进行系统性能监控与调优系统性能监控与调优是保证系统正常运行和提高系统性能的重要环节。
通过实时监控系统的运行状态，发现和解决系统性能瓶颈，可以提高系统的稳定性和响应速度，提升用户体验。
一、系统性能监控1.系统性能监控的重要性系统性能监控可以实时了解系统的负载、资源使用和性能瓶颈，在系统出现问题时能够迅速发现并采取相应的措施。
通过合理设置性能监控指标，可以做到及时预警和快速定位问题，以保障系统的正常运行。
2.性能监控的指标（1）CPU使用率：监测CPU的使用情况，以便及时发现CPU过载或者负荷不均衡的情况。
（2）内存使用情况：检测内存的占用情况，及时发现内存泄漏或者内存不足的问题。
（3）磁盘读写情况：监控磁盘的读写速度，了解磁盘的繁忙程度，以便优化磁盘IO操作。
（4）网络带宽使用情况：监测网络带宽的使用情况，发现网络拥塞或者瓶颈问题。
（5）系统响应时间：记录系统的响应时间，以便发现系统的性能问题。
3.监控工具的选择根据实际需求选择合适的监控工具，常用的系统监控工具有Zabbix、Nagios、Cacti等。
这些工具可以通过在监控服务器上安装相应的代理软件，采集关键指标并进行展示和告警。
4.监控数据的分析通过监控工具采集的数据可以获得系统的各项性能指标，需要对这些数据进行定期分析，以便发现问题并采取相应的调优措施。
可以通过图表和报表的形式展示监控数据，更直观地了解系统的运行状态。
二、系统性能调优1.性能调优的方法（1）优化数据库：可以通过如索引的创建、查询语句的优化、分表分库等方式来提高数据库的性能。
（2）优化代码：对于性能瓶颈较大的代码进行优化，如减少循环次数、避免重复计算、异步操作等。
（3）优化网络：通过优化网络架构和使用CDN技术等方式来提升网络传输速度。
（4）优化系统配置：合理配置系统参数，如调整内核参数、网络参数等，以提高系统的性能。
2.性能调优的工具（1）性能分析工具：如Apache JMeter、Gatling等，可以模拟大量用户并监测系统的性能。
LoadRunner性能测试分析
1 衡量web 性能的基本指标（1）响应时间：响应时间=网络响应时间+应用程序响应时间，反映完成某个业务所需要的时间，响应时间通常随负载的增加而增加。
响应时间的单位一般为“秒”或者“毫秒”。
（2）吞吐量：反应系统处理能力指标，随着负载的增加，吞吐量往往增长到一个峰值后下降，队列变长。
通常情况下，吞吐量用“请求数/秒”或者“页面数/秒”来衡量。
（3）服务器资源占用：反应系统能耗指标。
随着用户和吞吐量的上升，服务器的资源会被占用的越来越多，直到服务器资源被完全占用。
资源利用率通常以占用最大值的百分比n%来衡量。
（4）轻负载区：随着用户数量的上升，响应时间基本上没有太大的变化，吞吐量随着用户的增加而增加，说明这个系统资源是足够的，所以没有出现响应时间和吞吐量的明显变化。
在这个状态下，系统完全能够轻松地处理业务，所以称之为轻负载区。
（5）重负载区：当用户数量继续上升，响应时间开始明显上升，吞吐量上升速度开始变慢，并且到达峰值，随后开始小幅回落，逐渐稳定。
在这个阶段中，系统已经达到了处理的高峰，由于资源的逐渐匮乏，吞吐量下降，而响应时间变长。
在这个状态下，说明系统资源已经高负荷使用，处理能力达到极限。
在重负载区有几个数据比较关键：轻负载区到重负载区分界点的用户数：这个用户数是系统最优的高性能用户数，系统资源正在被高效的分配和利用。
重负载区中的吞吐量峰值：这个峰值就是系统的最高处理能力，而同时的用户数也是系统所能达到的高性能处理能承受的用户数，在这个时刻资源利用率应该正好达到峰值。
重负载区到负载失效区分界点的用户数：这个用户数是系统所能达到性能需求的最大在线用户数，超过这个数目的用户将无法正常使用系统。
负载失效区：当用户数量继续增加，响应时间会大幅上升，而吞吐量会逐渐加速下降，资源被消耗殆尽。
当响应时间超出用户能够忍受的范围时，这部分用户将会选择放弃访问。
通过上面的说明可以看出一个系统最好能够工作在轻负载区，接近重负载区即可，不能出现系统进入负载失效区的情况。
loadrunner中各性能指标解释
Transactions（用户事务分析）用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。
通过它可以确定系统在任何给定时刻的时间事务负载。
分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。
性能测试(LoadRunner)
开始 分析应用系统 定义压力测试的对象和目标 测试计划评审 编写测试案例 测试环境的搭建 测试数据的准备 测试工具的准备 录制脚本，增强脚本 实施方案，监视系统资源 分析测试结果 是否可以接受
Part4 . L oa d R u n n e r 应 用
2、录制、编辑及调试脚本 性能测试最重要的一步是生成虚拟用户脚本
Virtual User Generator
事务：为了衡量服务器的性能，需要定义事务；如：数据查询 操作，为了衡量服务器执行查询操作的性能，需要把这个操作 定义为一个事务，这样在运行测试脚本时，LoadRunner运行 到该事务的开始点时，LoadRunner就会开始计时，直到运行 到该事务的结束点，计时结束。这个事务的运行时间在结果中 会有反映。
数据准备时根据测试需要，在执行测试之前在被 测系统种加入复合要求的数据。 数据准备方法： 1、手工：要加入的数据量比较少的情况下可以手工 在系统中加入。 2、使用LR或其他自动化测试工具：在数据量比较多 的情况下就要使用工具，录制脚本反复迭代运行脚本 或在场景中运行脚本； 3、数据直接写入数据库：这种方法使用sql语句（或 存储过程）实现数据批量写入数据库；
Part1.性 能 测 试 简 介
性能测试的定义
（5）思考时间：Think Time，也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时， 每个请求之间的间隔时间。从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个 操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think 的函数，使得脚本在执行两 个操作之间等待一段时间。 （6）TPS ：Transaction per second，每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要 指标。 （7）HPS：点击率Hit Per second ，每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个 指标，WEB应用是"请求—响应"模式，用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理 的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对 服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点 击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求。
Loadrunner使用手册整理版
一、Loadrunner简介LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。
通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。
通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。
难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。
这些都不可避免地导致公司收益的损失。
Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。
LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。
LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。
此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。
负载测试通常由五个阶段组成：计划、脚本创建、场景定义、场景执行和结果分析。
.(1)计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需响应时间。
.(2)创建 Vuser 脚本：将最终用户活动捕获到自动脚本中。
选择协议录制脚本编辑脚本检查修改脚本是否有误(3)定义场景：使用LoadRunner Controller 设置负载测试环境。
创建场景（Scenario）选择脚本设置机器虚拟用户数设置Schedule （场景计划表）如果模拟多机测试，设置Ip Spoofer （ip 欺骗）(4)运行场景：通过LoadRunner Controller 驱动、管理和监控负载测试。
Loadrunner性能指标定位系统瓶颈
都配置在一台机器上）性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。
分析原则：• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）• 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。
对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
• 分段排除法很有效分析的信息来源：•1 根据场景运行过程中的错误提示信息•2 根据测试结果收集到的监控指标数据一．错误提示分析分析实例：1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection•Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely分析：•A、应用服务死掉。
（小用户时：程序上的问题。
程序上处理数据库的问题）•B、应用服务没有死（应用服务参数设置问题）例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic 中的server元素的AcceptBacklog属性值设得过低。
如果连接时收到connection refused消息，说明应提高该值，每次增加25％•C、数据库的连接(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)2 Error: Page download timeout (120 seconds) has expired分析：可能是以下原因造成•A、应用服务参数设置太大导致服务器的瓶颈•B、页面中图片太多•C、在程序处理表的时候检查字段太大多二．监控指标数据分析1．最大并发用户数：应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
Loadrunner中参数的设置（五篇模版）
Loadrunner中参数的设置（五篇模版）第一篇：Loadrunner中参数的设置Loadrunner中参数的设置在做负载或者压力测试时，很多人选择使用了Loadrunner测试工具。
该工具的基本流程是先将用户的实际操作录制成脚本，然后产生数千个虚拟用户运行脚本（虚拟用户可以分布在局域网中不同的PC 机上），最后生成相关的报告以及分析图。
但是在录制脚本的过程中会遇到很多实际的问题，比如不同的用户有不同的使用数据，这就牵涉到参数的设置问题。
本文就Loadrunner中参数的设置进行说明，希望对大家有所帮助。
录制程序运行的过程中，VuGen（脚本生成器）自动生成了包含录制过程中实际用到的数值的脚本。
如果你企图在录制的脚本中使用不同的数值执行脚本的活动（如查询、提交等等），那么你必须用参数值取代录制的数值。
这个过程称为参数化脚本。
本文主要包括如下内容：理解参数的局限性、建立参数、定义参数的属性、理解参数的类型、为局部数据类型设置参数的属性、为数据文件设置参数的属性、从已经存在的数据库中引入数据。
除了GUI，以下的内容适合于各种类型的用户脚本。
一、关于参数的定义在你录制程序运行的过程中，脚本生成器自动生成由函数组成的用户脚本。
函数中参数的值就是在录制过程中输入的实际值。
例如，你录制了一个Web应用程序的脚本。
脚本生成器生成了一个声明，该声明搜索名称为“UNIX”的图书的数据库。
当你用多个虚拟用户和迭代回放脚本时，也许你不想重复使用相同的值“UNIX”。
那么，你就可以用参数来取代这个常量。
结果就是你可以用指定的数据源的数值来取代参数值。
数据源可以是一个文件，也可以是内部产生的变量。
用参数表示用户的脚本有两个优点：① 可以使脚本的长度变短。
② 可以使用不同的数值来测试你的脚本。
例如，如果你企图搜索不同名称的图书，你仅仅需要写提交函数一次。
在回放的过程中，你可以使用不同的参数值，而不只搜索一个特定名称的值。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一、windows常见计数器Memory:Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。
一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。
有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。
Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。
阈值为>5. 越低越好。
大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。
因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：Physical Disk\ % Disk TimePhysical Disk\ Avg.Disk Queue Length例如，包括Page Reads/sec 和% Disk Time 及Avg.Disk Queue Length。
如果页面读取操作速率很低，同时% Disk Time 和Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。
但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将Physical Disk\ Avg.Disk sec/Transfer 和Memory\ Pages/sec 计数器的值增大数倍。
如果这些计数器的计数结果超过了0.1，那么页交换将花费百分之十以上的磁盘访问时间。
如果长时间发生这种情况，那么您可能需要更多的内存。
Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。
如IIS5.0 运行内存不够时，它会自动整理缓存。
需要关注该计数器的趋势变化如果您怀疑有内存泄露，请监视Memory\ Available Bytes 和Memory\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的Process\Private Bytes、Process\Working Set 和Process\Handle Count。
如果您怀疑是内核模式进程导致了泄露，则还应该监视Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和Process(process_name)\ Pool Nonpaged Bytes。
Pages per second :每秒钟检索的页数。
该数字应少于每秒一页。
Process：%Processor Time: 被处理器消耗的处理器时间数量。
如果服务器专用于sql server,可接受的最大上限是80-85%Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。
如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。
如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。
可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。
如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。
如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。
可考虑更换更快的硬盘系统。
另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。
队列长度持续大于4 则表示可能出现处理器拥塞。
此计数器是特定时间的值，而不是一段时间的平均值。
% DPC Time:越低越好。
在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
ThreadContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。
增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。
如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
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: 物理磁盘上每秒钟磁盘读、写的次数。
两者相加，应小于磁盘设备最大容量。
Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Network Interface：Bytes Total/sec :为发送和接收字节的速率，包括帧字符在内。
判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较二、Linux常见计数器CPU相关指标◆CPU utilization（System mode CPU utilization +User mode CPU utilization ）——CPU利用率CPU占用率，即使用CPU的时间百分比。
该项指标的最大上限为85%，若超过此上限，则说明系统CPU成为资源瓶颈；该项指标的合理使用范围60%~70%，若指标值较低，则意味着资源的浪费。
CPU利用率=系统CPU利用率+用户CPU利用率◆Average load——平均负载上一分钟同时处于“就绪”状态的平均进程数在过去的1分钟，的平均负载一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题。
例如，假设系统有两个CPU，LR监控到的平均负载为8.13，那么其每个CPU的当前任务数为：8.13/2=4.065。
这表示该系统的性能是可以接受的◆Context switches rate——上下文交换率Context Switches/sec 指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。
当正在运行的线程自动放弃处理器时出现上下文转换，由一个有更高优先就绪的线程占先或在用户模式和特权(内核)模式之间转换以使用执行或分系统服务。
它是在计算机上的所有处理器上运行的所有线程的Thread: Context Switches/sec 的总数并且用转换数量衡量。
在系统和线程对象上有上下文转换计数器频繁的页交换将降低系统性能。
减少页交换将显著提高系统响应速度◆Interrupt rate——中断率每秒内的设备中断数内存相关指标◆Paging rate（Page-in rate +Page-out rate ）——内存页交换速率每秒写入内存页和从物理内存中读出页的数目如果该值偶尔走高，表明当时有线程竞争内存。
如果持续很高，则内存可能是瓶颈◆Swap-in rate/Swap-out rate——进程入交换率/进程出交换率交换区输入输出的进程数目若交换分区进程交换频繁，也反映了系统内存资源紧张。
物理磁盘相关指标◆Disk rate——磁盘传输率物理磁盘与内存交互时的传输速度网络相关指标◆Incoming packets rate/Outgoing packets rate——数据包接收速度/数据包发送速度每秒钟传入/传出的以太网数据包数◆Incoming packets error rate/Outgoing packets errors rate——数据包接收错误率/数据包发送错误率接收/发送以太网数据包时每秒钟发生的错误数可能是网络设备（网卡、网线、路由设备等）引起，该值较大会影响响应时间，甚至超时内存相关指标◆Collision rate——冲突率每秒钟在以太网上检测到的冲突数该值过高会导致网络响应变慢三、Oracle常用自定义计数器列表序号监控名称SQL算法说明select count(*) from v$process; 取得数据库目前的进程数select value from v$parameter where name = 'processes'; 取得进程数的上限。
1、数据高速缓存区命中率SELECTround(1-SUM(PHYSICAL_READS)/(SUM(DB_BLOCK_GETS) +SUM(CONSISTENT_GETS)), 4) * 100 FROM (SELECT CASE WHEN NAME='physical reads' THEN V ALUE END PHYSICAL_READS,CASE WHEN NAME = 'db block gets' THENV ALUE END DB_BLOCK_GETS,CASE WHEN NAME = 'consistent gets' THEN V ALUE END CONSISTENT_GETS FROM V$SYSSTAT WHERE Name IN ('physical reads','db block gets','consistent gets')) （监控SGA 的命中率）命中率应大于0.90最好2、库快存命中率SELECT 100*((sum(pins-reloads))/sum(pins)) fromv$librarycache 该计数器返回当前库快存命中率3 、共享区库缓存区命中率Select round(sum(pins-reloads)/sum(pins) * 100, 2) from v$librarycache （监控SGA 中共享缓存区的命中率）命中率应大于0.994、监控SGA 中字典缓冲区的命中率Selectround(sum(gets-getmisses-usage-fixed)/sum(gets) * 100, 2) from v$rowcache （共享区字典缓存区命中率）命中率应大于0.855、检测回滚段的争用select round(sum(waits)/sum(gets) * 100, 2) fromv$rollstat 小于1%6、检测回滚段收缩次数select sum(shrinks) from v$rollstat, v$rollname wherev$n = v$n7、监控表空间的I/O读总数select sum(f.phyrds) pyr from v$filestat f, dba_data_files df where f.file# = df.file_id 监控表空间的I/O8、监控表空间的I/O块读总数select sum(f.phyblkrd) pbr from v$filestat f,dba_data_files df where f.file# = df.file_id 监控表空间的I/O9、监控表空间的I/O写总数select sum(f.phywrts) pyw from v$filestat f,dba_data_files df where f.file# = df.file_id 监控表空间的I/O10、监控表空间的I/O块写总数select sum(f.phyblkwrt) pbw from v$filestat f,dba_data_files df where f.file# = df.file_id 监控表空间的I/O11、监控SGA 中重做日志缓存区的命中率SELECTDecode(immediate_gets+immediate_misses,0,0,immediate_misses/(immediate_gets+immediate_ misses)*100) ratio2 FROM v$latch WHERE name IN ('redo copy') 应该小于1%12、监控内存和硬盘的排序比率select round(sum(case when name='sorts (disk)' then value else 0 end) / sum(case when name='sorts (memory)' then value else 0 end)*100,2) from (SELECT name, value FROM v$sysstatWHERE name IN ('sorts (memory)', 'sorts (disk)')) 最好使它小于10%。