服务器资源监控指标

内存:
1 UNIX资源监控中指标内存页交换速率(Paging rate,使用称为“页面”的单位,将固定大小的代码和数据块从 RAM 移动到磁盘的过程,其目的是为了释放内存空间),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。
Windows资源监控中,如果Process/Private Bytes计数器和Process/Working Set计数器的值在长时间内持续升高,同时Memory/Available bytes计数器的值持续降低,则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率; 
内存不够出错(out of memory errors)

处理器:
1 UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 
合理使用的范围在60%至70%。
2 Windows资源监控中,如果System/Processor Queue Length大于2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆: 
很慢的响应时间(slow response time) 
CPU空闲时间为零(zero percent idle CPU) 
过高的用户占用CPU时间(high percent user CPU) 
过高的系统占用CPU时间(high percent system CPU) 
长时间的有很长的运行进程队列(large run queue size sustained over time)

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非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。

磁盘I/O:
1 UNIX资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中,如果 Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization) 
太长的磁盘等待队列(large disk queue length) 
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 
太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 
太长的运行进程队列,但CPU却空闲(large run queue with idle CPU)

page/sec:表明由于硬件页面错误而从磁盘取出的页面数,或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百,那么您应该进一步研究页交换活动。有可能需要增加内存,以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。Pages/sec 的值很大不一定表明内存有问题,而可能是运行使用内存映射文件的程序所致。

page read/sec:页的硬故障,page/sec的子集,为了解析对内存的引用,必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间,因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此,在研究内存不足不太明显的页交换的原因时,您必须跟踪如下的磁盘使用情况计数器和内存计数器:
Physical Disk/ % Disk Time
Physical 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 :每秒钟检索的页数。该数字应少于每秒一页。

4.数据库服务器:
SQL Server数据库:
1 SQLServer资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。
2 如果Full Scans/sec(全表扫描/秒)计数器显示的值比1或2高,则应分析你的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。 
3 Number of Deadlocks/sec(死锁的数量/秒):死锁对应用程序的可伸缩性非常有害,并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒),通过优化查询来减少读取次数,可以减少该计数器的值。

Oracle数据库:
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,那么需要增加SHARED_POOL_SIZE的大小。
快存(共享SQL区)和数据字典快存的命中率: 
select(sum(pins-reloads))/sum(pins) from v$librarycache; 
select(sum(gets-getmisses))/sum(gets) from v$rowcache; 
自由内存: select * from v$sgastat where name=’free memory’;

2 如果数据的缓存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS参数的值(单位:块)。
缓冲区高速缓存命中率:
select name,value from v$sysstat where name in (’db block gets’,
‘consistent gets’,‘physical reads’) ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

3 如果日志缓冲区申请的值较大,则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况 :
select name,value from v$sysstat where name = ‘redo log space requests’ ;

4 如果内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避免磁盘排序 。
内存排序命中率 :
select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’
注:上述SQL Server和Oracle数据库分析,只是一些简单、基本的分析,特别是Oracle数据库的分析和优化,是一门专门的技术,进一步的分析可查相关资料。

时间: 2024-11-05 16:37:47

服务器资源监控指标的相关文章

大开测试:性能-如何实现对Web应用程序服务器资源监控(连载25)

7.25  如何实现对Web应用程序服务器资源监控 1.问题提出 如何实现对Web应用程序服务器资源监控? 2.问题解答 可以使用LoadRunner的Web应用程序服务器资源监控器,在场景或会话步骤运行期间监控Web应用程序服务器,并隔离应用程序服务器性能瓶颈. Web应用程序服务器资源监控器提供了场景或会话步骤执行过程中,有关Ariba.ATG Dynamo.BroadVision.ColdFusion.Fujitsu INTERSTAGE.iPlanet (NAS).Microsoft A

JMeter ServerAgent服务器资源监控插件

本文介绍对Linux服务器的服务进行压测时,使用jmeter serverAgent插件监控服务器资源. 1.插件准备 所需插件: JMeterPlugins-Extras.jar JMeterPlugins-Standard.jar ServerAgent-2.2.1 插件下载地址:https://jmeter-plugins.org/install/Install/ 下载后分别解压 将JMeterPlugins-Extras.jar 和 JMeterPlugins-Standard.jar

liunx服务器常见监控指标

1. CPU Utilization 英文翻译就是CPU的利用率75%以上就比较高了(也有说法是80%或者更高).有的博客上说除了这个指标外,还要结合Load Average和Context Switch Rate来看,有可能CPU高是因为后两个指标高导致的. 在Linux/Unix下,CPU利用率分为用户态.系统态和空闲态, 分别表示CPU处于用户态执行的时间,系统内核执行的时间,和空闲系统进程执行的时间,其中有些小的指标1)用户时间(User time) 官方英文为user cpu time

性能测试-监控指标数据分析

监控指标数据分析 1.最大并发用户数: 应用系统在当前环境(硬件环境.网络环境.软件环境(参数配置))下能承受的最大并发用户数. 在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数. 如果测得的最大并发用户数到达了性能要求,且各服务器资源情况良好,业务操作响应时间也达到了用户要求,那么OK.否则,再根据各服务器的资源情况和业务操作响应时间进一步分

JMeter监控Linux服务器资源案例

JMeter是一款压力测试工具,我们也可以用它来监控服务器资源使用情况.JMeter正常自带可以通过Tomcat的/manager/status来监控服务资源使用情况.这种情况只能监控Tomcat支持的资源使用部分. 本文主要来说一下如何通过JMeter插件来监控服务器CPU.内存.磁盘.网络等相关资源.JMeter 插件网址:http://jmeter-plugins.org/Perf Mon 插件 http://jmeter-plugins.org/wiki/PerfMon/ 1 服务本身:

大数据资源监控(一)—— IDC机房集群指标获取

背景:公司自建IDC机房,基于IDC机房构建大数据集群:需要对集群资源进行监控,集群采用的是CDH集群,采集主要分两块进行: HDFS和YARN相关的指标进行采集IDC机器自身的指标进行采集 注意: 也许有人会有疑惑,CM界面已经提供了监控的图表,为什么还需要自己进行展示.原因在于,这些信息需要集成到内部的数据平台上面去,做成对应的数据报表,可视化的方式展示在自己的数据平台上 实现思路大致可以分为两种: 使用CM所提供的Java API去获取 使用CM提供的REST API去获取 其实两者本质上

大开测试:性能-如何实现对数据服务器的监控(连载24)

7.24  如何实现对数据服务器的监控 1.问题提出 一个应用系统通常都会或多或少地和数据库打交道,用户记录主要的业务信息,以备后期对相关数据进行查询和统计等处理操作.那么LoadRunner除了可以监控应用服务器相关系统资源的利用情况,是否还可以监控数据服务器的相关指标呢? 2.问题解答 使用LoadRunner的数据库服务器资源监控器,可以在场景或会话步骤运行期间监控DB2.Oracle.SQL Server或Sybase数据库的资源使用率.在场景或会话步骤运行期间,使用这些监控器可以隔离数

容器和实时资源监控的必知要素

您是否实时监控您的容器资源?如果没有,那意味着您可能没有对之进行有效监控.在快速变化的.动态的微服务环境中,即使是几秒钟以前的监视数据也可能不再可行.为了防止中断,您需要实时监控. 在这篇文章中,我解释了为什么对容器资源进行实时监控是很重要的,以及实时监控中您应该关注的容器指标. 首先要明确的是,这篇文章并非在为哪个特定的容器监控产品站台.虽然现在有很多可供容器使用的实时监控平台,但我认为最好的做法,还是充分了解容器监控的基本要素,而不是只关注特定产品的某些特性.如果您知道为保证容器基础设施正常

深度解析Tengine的调试与资源监控方法论

摘要: Tengine是由淘宝网发起的Web服务器项目.它在Nginx的基础上,针对大访问量网站的需求,提供更强大的流量负载均衡能力.全站HTTPS服务.安全防×××.链路追踪等众多高级特性.团队的核心成员来自于淘宝.搜狗等互联网企业,从2011年12月开始,Tengine成为一个开源项目,团队在积极地开发和维护着它,最终目标是打造一个高效.稳定.安全.易用的Web平台. 阿里云CDN现在服务超过24万家客户,Tengine作为接入层提供高性能Web Server服务,是CDN系统最核心的组件之