loadrunner监控常用性能指标

合集下载

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性能测试分析

LoadRunner性能测试分析

1 衡量web 性能的基本指标(1)响应时间:响应时间=网络响应时间+应用程序响应时间,反映完成某个业务所需要的时间,响应时间通常随负载的增加而增加。

响应时间的单位一般为“秒”或者“毫秒”。

(2)吞吐量:反应系统处理能力指标,随着负载的增加,吞吐量往往增长到一个峰值后下降,队列变长。

通常情况下,吞吐量用“请求数/秒”或者“页面数/秒”来衡量。

(3)服务器资源占用:反应系统能耗指标。

随着用户和吞吐量的上升,服务器的资源会被占用的越来越多,直到服务器资源被完全占用。

资源利用率通常以占用最大值的百分比n%来衡量。

(4)轻负载区:随着用户数量的上升,响应时间基本上没有太大的变化,吞吐量随着用户的增加而增加,说明这个系统资源是足够的,所以没有出现响应时间和吞吐量的明显变化。

在这个状态下,系统完全能够轻松地处理业务,所以称之为轻负载区。

(5)重负载区:当用户数量继续上升,响应时间开始明显上升,吞吐量上升速度开始变慢,并且到达峰值,随后开始小幅回落,逐渐稳定。

在这个阶段中,系统已经达到了处理的高峰,由于资源的逐渐匮乏,吞吐量下降,而响应时间变长。

在这个状态下,说明系统资源已经高负荷使用,处理能力达到极限。

在重负载区有几个数据比较关键:轻负载区到重负载区分界点的用户数:这个用户数是系统最优的高性能用户数,系统资源正在被高效的分配和利用。

重负载区中的吞吐量峰值:这个峰值就是系统的最高处理能力,而同时的用户数也是系统所能达到的高性能处理能承受的用户数,在这个时刻资源利用率应该正好达到峰值。

重负载区到负载失效区分界点的用户数:这个用户数是系统所能达到性能需求的最大在线用户数,超过这个数目的用户将无法正常使用系统。

负载失效区:当用户数量继续增加,响应时间会大幅上升,而吞吐量会逐渐加速下降,资源被消耗殆尽。

当响应时间超出用户能够忍受的范围时,这部分用户将会选择放弃访问。

通过上面的说明可以看出一个系统最好能够工作在轻负载区,接近重负载区即可,不能出现系统进入负载失效区的情况。

loadrunner中各性能指标解释

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)

性能测试(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 能够对整个企业架构进行测试。

通过使用LoadRunner,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。

目前企业的网络应用环境都必须支持大量用户,网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。

难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢,系统崩溃等问题。

这些都不可避免地导致公司收益的损失。

Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源,无需购置额外硬件而最大限度地利用现有的IT 资源,并确保终端用户在应用系统的各个环节中对其测试应用的质量,可靠性和可扩展性都有良好的评价。

LoadRunner 是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。

LoadRunner 的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。

此外,LoadRunner 能支持广范的协议和技术,为您的特殊环境提供特殊的解决方案。

负载测试通常由五个阶段组成:计划、脚本创建、场景定义、场景执行和结果分析。

.(1)计划负载测试:定义性能测试要求,例如并发用户的数量、典型业务流程和所需响应时间。

.(2)创建 Vuser 脚本:将最终用户活动捕获到自动脚本中。

选择协议录制脚本编辑脚本检查修改脚本是否有误(3)定义场景:使用LoadRunner Controller 设置负载测试环境。

创建场景(Scenario)选择脚本设置机器虚拟用户数设置Schedule (场景计划表)如果模拟多机测试,设置Ip Spoofer (ip 欺骗)(4)运行场景:通过LoadRunner Controller 驱动、管理和监控负载测试。

Loadrunner性能指标定位系统瓶颈

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中参数的设置在做负载或者压力测试时,很多人选择使用了Loadrunner测试工具。

该工具的基本流程是先将用户的实际操作录制成脚本,然后产生数千个虚拟用户运行脚本(虚拟用户可以分布在局域网中不同的PC 机上),最后生成相关的报告以及分析图。

但是在录制脚本的过程中会遇到很多实际的问题,比如不同的用户有不同的使用数据,这就牵涉到参数的设置问题。

本文就Loadrunner中参数的设置进行说明,希望对大家有所帮助。

录制程序运行的过程中,VuGen(脚本生成器)自动生成了包含录制过程中实际用到的数值的脚本。

如果你企图在录制的脚本中使用不同的数值执行脚本的活动(如查询、提交等等),那么你必须用参数值取代录制的数值。

这个过程称为参数化脚本。

本文主要包括如下内容:理解参数的局限性、建立参数、定义参数的属性、理解参数的类型、为局部数据类型设置参数的属性、为数据文件设置参数的属性、从已经存在的数据库中引入数据。

除了GUI,以下的内容适合于各种类型的用户脚本。

一、关于参数的定义在你录制程序运行的过程中,脚本生成器自动生成由函数组成的用户脚本。

函数中参数的值就是在录制过程中输入的实际值。

例如,你录制了一个Web应用程序的脚本。

脚本生成器生成了一个声明,该声明搜索名称为“UNIX”的图书的数据库。

当你用多个虚拟用户和迭代回放脚本时,也许你不想重复使用相同的值“UNIX”。

那么,你就可以用参数来取代这个常量。

结果就是你可以用指定的数据源的数值来取代参数值。

数据源可以是一个文件,也可以是内部产生的变量。

用参数表示用户的脚本有两个优点:① 可以使脚本的长度变短。

② 可以使用不同的数值来测试你的脚本。

例如,如果你企图搜索不同名称的图书,你仅仅需要写提交函数一次。

在回放的过程中,你可以使用不同的参数值,而不只搜索一个特定名称的值。

loadrunner监控常用性能指标

loadrunner监控常用性能指标

一、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 Len gth例如,包括Page Reads/sec 和% Disk Time 及Avg.Disk Queue Length。

如果页面读取操作速率很低,同时% Disk Time和Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。

但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。

要确定过多的页交换对磁盘活动的影响,请将Physical Disk' Avg.Disk sec/Tra nsfer 和Memory' Pages/sec计数器的值增大数倍。

如果这些计数器的计数结果超过了0.1,那么页交换将花费百分之十以上的磁盘访问时间。

服务器监控指标了解常用的性能指标和监控工具

服务器监控指标了解常用的性能指标和监控工具

服务器监控指标了解常用的性能指标和监控工具服务器监控是确保系统运行正常的关键一环。

通过实时监控服务器性能指标,可以及时发现并解决潜在的问题,提高服务器的稳定性和可靠性。

本文将介绍几个常用的服务器性能指标以及用于监控这些性能指标的工具。

一、CPU使用率CPU使用率是衡量服务器负载的重要指标之一。

它表示CPU正在执行指令的时间占总时间的比例。

通常,当CPU使用率超过70%时,就表明服务器正在超负荷运行。

常用的CPU监控工具有:1. top:top是Linux系统中常用的监控工具,它可以实时显示CPU 的使用率、内存使用率、进程信息等。

2. Windows任务管理器:在Windows系统中,任务管理器可以监控系统CPU的使用率,并以图表的形式展示。

二、内存使用率内存使用率是反映服务器内存负载的重要指标。

它表示已用内存占总内存的比例。

当内存使用率过高时,可能会导致服务器响应变慢或出现蓝屏等问题。

常用的内存监控工具有:1. free:free命令可以实时显示系统的内存使用情况,包括已用内存、可用内存、缓存等信息。

2. Performance Monitor(Perfmon):Perfmon是Windows系统自带的监控工具,可以实时监控系统的内存使用情况,并生成详细的报告。

三、磁盘空间使用率磁盘空间使用率是评估服务器存储容量的重要指标。

它表示已用磁盘空间占总磁盘空间的比例。

当磁盘空间使用率接近或超过100%时,可能会导致服务器无法正常写入数据,从而影响系统运行。

常用的磁盘监控工具有:1. df:df命令可以实时显示文件系统的使用情况,包括已用空间、可用空间、挂载点等信息。

2. Windows资源监视器:在Windows系统中,资源监视器可以监控磁盘空间的使用情况,并提供详细的磁盘分析报告。

四、网络流量网络流量是评估服务器网络性能的重要指标。

它表示服务器单位时间内收发的数据量。

通过监控网络流量,可以及时发现网络拥堵、带宽瓶颈等问题。

LoadRunner Windows资源监控

LoadRunner Windows资源监控
提示输入密码时,输入远程计算机的密码。 例如:
net use \\192.168.200.244 administrator net use \\192.168.200.244 /user:administrator 如果提示错误,则不加用户名: net use \\192.168.200.244 需要用户名和密码的话,系统会提示输入用户名和密码,按提示做即 可。
系统
以线程为单位的处理器队列瞬时长度。除非同时还监控线程计数器,否则此计数 器始终为 0。所有处理器使用一个队列,线程在此队列中等待处理器周期。此长度 不包括当前正在执行的线程。处理器队列长度持续大于2 通常表示发生处理器拥 塞。这是一个瞬时计数,而不是一段时间间隔内的平均值。 计算机接收和处理硬件中断的速率。可以生成中断的设备包括系统计时器、鼠 标、数据通信线路、网络接口卡和其他外围设备。此计数器指示这些设备在计算 机上的繁忙程度。另请参阅处理器:每秒中断数。
资源监控
——Windows性能监控
目录
Windows系统资源 SQL Server IIS
配置windows系统
保证被监视的windows系统开启以下二个服务:Remote Procedure Call(RPC) 和Remote Registry Service 获得对远程计算机的管理权限,请在命令提示符(运行 cmd命令)下执行以下命令:
请求和连接管理设置
Http.sys管理入站HTTP/HTTPS 连接,并且是在这些连接上处理请求的 第一个层。它使用内部数据结构保存有关连接和请求的信息。虽然这样 的数据结构可以按需创建(或释放),但如果在look-aside里表中保存 部分数据结构留作备用,则可以实现更高的 CPU 效率。保存这样的储 备有助于Http.sys利用更少的CPU资源来处理负载波动。 储备有助于减少CPU的使用率和缩短延迟时间,同时能够增加Web服务 器的处理能力,但是也会增加内存的使用率。您可以使用以下请求和连 接管理设置:

LoadRunner性能测试手册V10

LoadRunner性能测试手册V10

LoadRunner性能测试手册目录目录 (1)1. LoadRunner简介 (2)2. LoadRunner原理 (3)3. 性能测试介绍 (3)4. 性能测试相关术语 (4)5. LoadRunner安装 (5)6.LoadRunner的基本使用 (6)6.1打开Virtual User Generator (6)6.2 打开Controller (7)6.3打开Analysis (7)6.4网关测试常用设置 (7)6.4.1设置迭代 (7)6.4.2 日志 (8)6.4.3 思考时间 (8)6.4.4 运行方式 (8)6.4.5参数化 (9)7.Loadrunner常用函数 (10)8.压测场景设置 (18)8.1 增加负载生成器 (18)8.2压测时场景设置 (19)8.3基准测试场景设置 (19)8.4单场景负载测试 (20)8.5 稳定性测试 (20)8.6压测开始 (21)9.报告分析 (22)9.1生成报告 (22)9.2重要图表分析 (23)9.2.1 结果摘要 (23)9.2.2响应时间 (24)9.2.3 TPS (24)1.LoadRunner简介LoadRunner,是一种预测系统行为与性能的负载测试工具。

通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认与查找问题,LoadRunner能够对整个企业架构进行测试。

企业使用LoadRunner能最大限度地缩短测试时间,优化性能与加速应用系统的发布周期。

LoadRunner可适用于各种体系架构的自动负载测试,能预测系统行为并评估系统性能。

LoadRunner由Analysis 、Controller 、Virtual User Generator 三大模块组成,功能分别为录制脚本、创建运行及监视场景、分析测试结果。

2.LoadRunner原理loadrunner会自动监控指定的URL或应用程序所发出的请求及服务器返回的响应,它做为一个第三方(Agent)监视客户端与服务器端的所有对话,然后把这些对话记录下来,生成脚本,再次运行时模拟客户端发出的请求,捕获服务器端的响应。

使用LoadRunner的铁路视频监控网管系统性能测试

使用LoadRunner的铁路视频监控网管系统性能测试

用 于 铁 路 线 路 、 四 电 、客 服 、 编 组 站 等 场 景 的视 频 监 控
本 次 测 试 用 产 品为 通 信 信 号 信 息 集 团有 限 公 司 系统 相关设 备 的集 中维护 和管 理 。系 统采用 标准S N MP ( 简称通信 信号信 息集 团 )铁路综 合视 频监控 网管系统 网 络 管 理 协 议 , 可 方 便 接 入 各 视 频 厂 家 的 多 种 视 频 设
性能。
2 性 能测试 及 L o a d R u n n e r 简介
性 能 测 试 是 通 过 自动 化 的测 试 工 具 模 拟 多 种 正 常 、
4 实例 解析
4 . 1 测试内容及测试 环境
模拟1 o C - 虚拟 用户登录视频监 控网管系统 ,每 隔5 S 同时登陆2 个用户 ;虚拟用户随机进入系统的用户管理 、
试 的 目标是测试 当负 载逐渐增加 时 ,系统各项性 能指标 中 ,并 成 功 查询 该 版 块 的 当前 记 录 数据 。设 置 迭代 次 数 共
的变化 情况 ;压力测试 是通过不 断增加 系统负载 ,确定 为 1 0 0 0 次。共计模拟 1 0 0 0 0 次登陆、查询数据过程 。
当 前 记 录 数 据 。应 用 L o a d R u n n e r 测 试 工 具 建 立 测 试 脚 本 和 测 试 场 景 , 并 监 测 此 过 程 中 系 统 服 务 器 及 网 络 的各 种 性 能指 标 。
0 引言
测 试 工 作 在 产 品研 发 中 的地 位 越 来 越 重 要 ,其 性 能
( Ce n t r a l i z e d Ne t wo r k Ma n a g e me nt f o r Vi d e o Mo n i t o r i n g

如何在Loadrunner中监控服务器资源使用情况

如何在Loadrunner中监控服务器资源使用情况

如何在Loadrunner中监控服务器资源使用情况一.监控需要进行的配置:在LR控制台设置监控Windows服务器的资源比较容易,直接添加Measurements即可。

但是大多情况下面服务器的操作系统是Linux或者Unix,这时想监控系统的资源使用情况就需要进行一些设置:1.由于LR是通过rpc.rstatd进程获得系统的性能数据,因此首先查看进程中是否存在该进程,或者能否通过运行./rpc.rstatd启动该进程,如果可以,恭喜你,你可以直接在LR的控制台添加Measurements;否则需要下载rstatd.tar.gz,下载地址:.安装rstatd$tar xvzf rstatd.tar.gz$cdrpc.rstatd$./configure--prefix=/usr$make#sudo su#make install3.Add aline to the hosts.allow file within/etc/to specify thesubnet(s)allowed to make rstatd requests.For example:rpc.rstatd:10.0.95.0/255.255.255.0 10.0.8.0/255.255.255.0 Alternately,if youwant to live dangerously:rpc.rstatd:ALL4.Add rstatd entryin/etc/xinetd.d/rstatd:#default:off#description:An xinetd internal service which rstatd's characters back to clients.servicerstatd{type=RPC rpc_version=2-4 socket_type=dgram protocol=udpwait=yes user=root only_from=10.0.95.0/24 log_on_success+=USERIDlog_on_failure+=USERID server=/usr/sbin/rpc.rstatddisable=no.}5.Restart xinetd:#/etc/rc.d/init.d/xinetd restart补充的udp服务rpc.rstatd查看rpc服务进程rpcinfo-p理论上info为7个进程(前面共有两次start),如果各位有兴趣可以自己使用rpcinfo来查看前后的服务对比。

loadrunner中各性能指标解释

loadrunner中各性能指标解释

1、Transactions(用户事务分析)用户事务分析是站在用户角度进行的基础性能分析。

1.1、TransationSunmmary(事务综述)对事务进行综合分析是性能分析的第一步,通过分析测试时间内用户事务的成功与失败情况,可以直接判断出系统是否运行正常。

1.2、Average Transaciton Response Time(事务平均响应时间)“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间,通过它可以分析测试场景运行期间应用系统的性能走向。

例:随着测试时间的变化,系统处理事务的速度开始逐渐变慢,这说明应用系统随着投产时间的变化,整体性能将会有下降的趋势。

1.3、Transactions per Second(每秒通过事务数/TPS)“每秒通过事务数/TPS”显示在场景运行的每一秒钟,每个事务通过、失败以及停止的数量,是考查系统性能的一个重要参数。

通过它可以确定系统在任何给定时刻的时间事务负载。

分析TPS主要是看曲线的性能走向。

将它与平均事务响应时间进行对比,可以分析事务数目对执行时间的影响。

例:当压力加大时,点击率/TPS曲线如果变化缓慢或者有平坦的趋势,很有可能是服务器开始出现瓶颈。

1.4、Total Transactions per Second(每秒通过事务总数)“每秒通过事务总数”显示在场景运行时,在每一秒内通过的事务总数、失败的事务总数以及停止的事务总数。

1.5、Transaction Performance Sunmmary(事务性能摘要)“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间,可以直接判断响应时间是否符合用户的要求。

重点关注事务的平均和最大执行时间,如果其范围不在用户可以接受的时间范围内,需要进行原因分析。

1.6、Transaction Response Time Under Load(事务响应时间与负载)“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合,通过它可以看出在任一时间点事务响应时间与用户数目的关系,从而掌握系统在用户并发方面的性能数据,为扩展用户系统提供参考。

LoadRunner一般都监控哪些指标

LoadRunner一般都监控哪些指标
厘秒
缓冲区忙
(buffer busy(cs))
当一个会话想要访问缓存中的某个块,而这个块正在被其它会话使用时,将会产生该等待事件。这时候,其它会话可能正在从数据文件向缓存中的这个块写入信息,或正在对这个块进行修改。
出现这个等待事件的频度不应大于1%。如果这个等待事件比较显著,则需要根据等待事件发生在缓存中的哪一块(如字段头部、回退段头部块、回退段非头部块、数据块、索引块等),采取相应的优化方法。
解析的比率
(Execute to Parse %)
指SQL语句执行与解析的比率。SQL语句一次解析后执行的次数越多,该比率越高,说明SQL语句的重用性很好。
该指标的值应尽可能到高,如果过低,可以考虑设置
session_cached_cursors参数。
%
共享池内存使用率
(Memory Usage %)
%
共享区命中率
(Library Hit%)
该指标主要代表sql在共享区的命中率。
该指标的值通常应在95%以上,否则需要考虑加大共享池(修改shared_pool_size参数值),绑定变量,修改cursor_sharing等参数。
%
软解析的百分比
(Soft Parse %)
该指标是指Oracle对sql的解析过程中,软解析所占的百分比。软解析(soft parse)是指当Oracle接到Client提交的Sql后会首先在共享池(Shared Pool)里面去查找是否有之前已经解析好的与刚接到的这一个Sql完全相同的Sql。当发现有相同的Sql就直接用之前解析好的结果,这就节约了解析时间以及解析时候消耗的CPU资源。
这个等待事件是指当一个会话完成一个事务(提交或者回滚数据)时,必须等待LGWR进程将会话的redo信息从日志缓冲区写到日志文件后,才能继续执行下去。

loadrunner监控指标

loadrunner监控指标
成延迟而产生丢包。
网络相关指标
Packets Outbound Errors ——发送错误信息包
在发送信息包错误信息情况 通过监控网络中发生的传输错误和故障,验
证该网络系统的可靠性。
网络相关指标
Packets Received Discarded ——接收丢失信息包
内存相关指标
Pool Nonpaged Bytes ——非分页池的字节数
在访问数比较固定的情况下,Pool Nonpaged Bytes是比较固定的,如果访问数逐步增加,该 值会缓慢的增加。
物理磁盘相关指标
% Disk Time ——磁盘利用率
所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的 百分比
LR监控指标
操作系统部分
LR监控指标
Windows部分
UNIX部分
准备知识
数据
硬盘

虚拟内存(交换分区swap)
内存
CPU缓存
CPU执行队列
执行

Windows部分
CPU 内存 物理磁盘(硬盘) 网络
CPU相关指标
%Processor Time ——CPU占用率
处理器执行非空闲线程的时间百分比 查看处理器饱和状况的最佳计数器,显示所
物理磁盘相关指标
Disk Bytes/sec ( Disk Read Bytes/sec + Disk Write Bytes/sec ) ——磁盘工作速率
磁盘工作时每秒钟写入/读取的字节数 反映磁盘工作时的吞吐量
网络相关指标
Bytes Total/sec (Bytes Sent/sec +Bytes Received/sec ) ——字节传输速率

压力测试衡量CPU的三个指标

压力测试衡量CPU的三个指标

压力测试衡量CPU的三个指标:CPU Utilization、Load Average和Context Switch Rate上篇讲如何用LoadRunner监控Linux的性能指标,但是关于CPU的几个指标没有搞清楚,下面就详细说说。

CPU Utilization好理解,就是CPU的利用率,75%以上就比较高了(也有说法是80%或者更高)。

除了这个指标外,还要结合Load Average和Context Switch Rate来看,有可能CPU高是因为后两个指标高导致的。

Load Average,这个很难衡量。

网上搜了一圈,还没见到几个合理的解释。

我100个并发用户测试数来这两个值是:77.534%,6.108,CPU利用率比较高,Load Average也好像有点高。

“Load Average是CPU的Load,后来发现了如下两片博文:理解Load Average做好压力测试,它所包含的信息不是CPU的使用率状况,而是在一段时间内CPU正在处理以及等待CPU 处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息。

”,基本解释了multi-process,multi-thread程序的原理。

理解Linux处理器的负载均值(翻译),简单说起来就一句话:Load Average < CPU个数* 核数*0.7比如1个1核CPU,Load Average < 1 * 1 * 0.7;1个4核的CPU,Load Average必须< 1 * 4 * 0.7 = 2.8。

查看cpu的信息:grep 'model name' /proc/cpuinfoContext Switch Rate。

就是Process(Thread)的切换,如果切换过多,会让CPU忙于切换,也会导致影响吞吐量。

《高性能服务器架构》这篇文章的第2节就是说的是这个问题的。

究竟多少算合适?google了一大圈,没有一个确切的解释。

loadrunner性能测试指标

loadrunner性能测试指标

Committed Bytes (Memory)
Context Switches/sec (System)
W i n d o w s R e s o u r c e s
Disk Transfers/sec (PhysicalDisk _Total) File Data Operations/sec (System) Free Megabytes (LogicalDisk _Total)
磁盘中断所用时间的百分比
(CPU内核时间)是在特权模式下处理线程执行 代码所花时间的百分比。
(处理器利用率)被处理器消耗的处理器时间数 量。
计算机运行进程的可用物理内存大小
磁盘字节/转移 读取和写入请求(为所选磁盘在实例间隔中列队 的)的平均数。 为发送和接收字节的速率,包括帧字符在内。 文件系统缓存(File System Cache)
Pool Paged Bytes (Memory)
Pool Paged Bytes (Server) Pool Paged Failures (Server) Private Bytes (Process _Total)
Processor Queue Length (System)
Split IO/Sec (PhysicalDisk _Total)
名称 Average Wait Time (ms) (SQLServer|Locks _Total)
Batch Requests/sec (SQLServer|SQL Statistics)
Buffer cache hit ratio (SQLServer|Buffer Manager) Cache Hit Ratio (SQLServer|Plan Cache _Total) Checkpoint pages/sec (SQLServer|Buffer Manager) Full Scans/sec (SQLServer|Access Methods) Lazy Writes/sec (SQLServer|Buffer Manager) Memory Grants Pending (SQLServer|Memory Manager) Number of Deadlocks/sec (SQLServer|Locks _Total) Page Life Expectancy (SQLServer|Buffer Manager) Page Splits/sec (SQLServer|Access Methods) SQL Compilations/sec (SQLServer|SQL Statistics) SQL Re-Compilations/sec (SQLServer|SQL Statistics) Stolen Pages (SQLServer|Buffer Manager) Target Pages (SQLServer|Buffer Manager) Target Server Memory (KB) (SQLServer|Memory Manager) Temp Tables Creation Rate (SQLServer|General Statistics) Total Pages (SQLServer|Buffer Manager) Total Server Memory (KB) (SQLServer|Memory Manager) % Disk Time (PhysicalDisk _Total) % Idle Time (PhysicalDisk _Total)
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 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%。

相关文档
最新文档