标签：调整 ISE eset 测试 center 内存 故障 err 另一个
一、常见计数器
1、windows系统计数器
| 类别 | 计数器名称 | 计数器描述 |
| Memory | Available Mbytes | 可用物理内存数 |
| Pages/sec | 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的面数 | |
| Pages Read/sec | 页的硬故障，Pages/sec的子集，为了解析对内存的引用，必须读取页文件的次数。其阈值为5，数值越低越好，大树枝表示磁盘读而不是缓存读 | |
| Page Faults/sec | 此值为处理器中的页面错误的计数。当进程引用特定的虚拟内存页，该页不在其主内存的工作集中，将出现页面错误。如果某页已经位于主内存中，或者它正在被共享该页的其他进程所使用，则页面错误不会导致该页从磁盘中读取 | |
| Cache Bytes | 文件系统缓存，默认情况下为50%的可用物理内存 | |
| Process | %Processor Time | 被处理器消耗的处理器时间数量。如果专用于某种特定应用，则可用应用相关进程的%Processor Time进行衡量，此时可接受的上限一般不超过85% |
| Page Faults/sec | 将进程产生的页故障与系统产生的相比较，以判断该进程对系统页故障产生的影响 | |
| Work Set | 处理线程最近使用的内存页，反映每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值，页就会被清除出工作集 | |
| Private Bytes | 此进程所分配的无法与其他进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄露的最佳指示器 | |
| Processor | %Processor Time | 如果该值持续超过95%，表明瓶颈是CPU，可以考虑增加一个处理器或换一个更快的处理器 |
| %User Time | 非内核操作耗费的CPU时间。一般来说，如果系统中使用了大量的算法或复杂的计算操作，该值会比较大 | |
| %Pricileged Time | CPU内核时间是在特权模式下处理线程执行代码所花时间的百分比 | |
| %DPC Time | CPU消耗在网络处理上的时间，此值越低越好 | |
| Physical Disk | %Disk Time | 所选磁盘驱动器忙于为读或写入请求提供服务所用时间的百分比 |
| Average Disk Queue Length | 读取和写入请求(所选磁盘在实例间隔中列队)的平均数。该全值应不超过磁盘数的1.5~2倍，要提高性能，可增加磁盘。(一个Raid Disk实际有多个磁盘) | |
| DiskReads(Writes)/sec | 物理磁盘上每秒磁盘读、写的次数，两者相加应小于磁盘设备的最大容量 | |
| Average Disk sec/Read | 以秒计算的在磁盘上读取数据所需的平均时间 | |
| Average Disk sec/Transfer | 以秒计算的在磁盘上写入数据所需的平均时间 | |
| Network Interface | Bytes Total/sec | 为发送和接受字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前的宽带比较 |
| System | %Total Processor Time | 系统上所有处理器都忙于执行非空闲线程的平均时间百分比，反映了用于有用作业的时间比率。对单处理器系统来说，该值很容易理解；对于多服务器系统来说，该值体现了所有处理器的平均繁忙程度 |
| File Data Operations/sec | 计算机对文件系统设备执行读取和写入操作的速率。本计数器的计数不包括文件控制操作 | |
| Processor Queue Length | 线程单元中的处理队列的即时长度。所有处理器都是用单一队列(线程在该队列中等待处理器进行循环)。此长度不包括当前正在执行的线程，一般情况下，如果处理器队列的长度一直超过服务器上可用处理器的总数量+1，则表示处理器可能堵塞 |
2、IIS应用服务器计数器
| 类别 | 计数器名称 | 计数器描述 |
| Processor | %Total Processor Time | 被处理器消耗的处理器时间数量，对于IIS应用服务器来说，该值一般不应超过85% |
| Physical Disk | %Disk Time | 显示磁盘进行读/写活动所花费的时间百分比 |
| Memory | Available Bytes | 可用的剩余物理内存量。IIS基本占用2.5MB，每个附加连接将在此基础上占用10KB左右 |
| Pool Paged Bytes and Pool Nonpaged Bytes | 缓冲池，由应用程序和操作系统创建并使用的对象。如果池被填满，可能发生内存泄露 | |
| Pages/sec | 如果服务器没有足够的内存处理其工作负荷，此数值将一直很高 | |
| Object | Threads | 线程是执行处理器指令的基本可执行实体，如果该值一直持续上升，请打开Process:Threads Count计数器并查看所有线程是由哪个实例创建的 |
| Process | Private Bytes Total | 显示所有实例已经分配但无法与其他进程共享的当前字节数 |
1）Active Server Page计数器
重点需要关注超时的请求数、脚本运行时期的错误、队列中的请求数、请求等待时间、请求总数、失败的请求总数和送出的总字节数。
队列中的请求数和请求等待时间直接反映应用服务器的处理能力，如果队列中的请求数数值处于一个比较高的水平，同时请求等待时间是一个比较大的值，则应用服务器本身是瓶颈，需要解决。脚本运行时期的错误、请求总数、失败的请求总数和送出的总字节数都可以与测试工具在测试过程中获得的吞吐量、请求数等进行对比，从而确定数据的可信度。
2）Web Service计数器
①Bytes Total/Sec：显示Web服务器发送和接收的总字节数。低数值表明该IIS正在以较低的速度进行数据传输；
②Connection Refused：数值越低越好，高数值表明网络适配器或处理器存在瓶颈；
③Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数(http status=404)
3)dotNET计数器（略，查看官方文档）
3、J2EE应用服务器计数器
| 类别 | 计数器名称 | 计数器描述 |
| JVM | Heap Size | JVM堆大小，该计数器的值是一个实时值 |
| Heap Free | JVM可用堆大小，该计数器的值是一个实时值 | |
| JDBC Connection Pool | Waiting For Connection Current Count | 等待的连接数量，如果该值持续较大，可能需要考虑增加应用服务器的JDBC连接池大小 |
| Connections Total Count | 总的JDBC连接数 | |
| Max Capacity | JDBC连接池的总容量。可以通过该计数器和上两个计数器值的比较，获得连接池设置是否合理的结论 | |
| Active Connections Current Count | 当前活跃的JDBC连接数，分析该值可以知道JDBC连接的利用率是否合理 | |
| Execute Queue | Execute Thread Current Idle Count | 空闲的线程数量 |
| Pending Request Oldest Time | 队列请求的最久时间。该值可以看到队列有无明显的拥塞情况 | |
| Serviced Request Total Count | 已处理的请求总数。该值可以用来和性能测试工具测试后得到的单击数进行对比 | |
| Pending Request Current Count | 挂起请求的数量 |
4、数据库服务器计数器
| 类别 | 计数器名称 | 计数器描述 |
| System | Total Processor Time | 数据库进程占用的CPU时间。不同的数据库有不同的名称，例在Oracle中被称为cpu used by thisession |
| User Connections | 当前用户连接数。数据库服务器一般都有用户数连击数的限制，应用不合理时，有可能出现连接数超过限制的情况，导致一些异常的发生 | |
| Memory | Cache Hit Ratio | 缓存命中率。当该值比较小，而数据库比较繁忙时，可能需要调整缓存的大小 |
| Total Server Memory(仅适用于SQL Server) | 进程当前使用的内存量。结合其他计数器(ConnectionMemory、Lock Memory等)可以很清楚知道Memory的使用情况 | |
| PGA Memory/UGA Memory(仅适用于Oracle) | Oracle数据库进程的内存使用情况 | |
| Lock | Average Wait Time | 锁平均等待时间 |
| Lock Requesets/sec | 每秒的锁请求数 | |
| Number of Deadlocks/sec | 每秒产生的死锁数量，当该值比较大时，需要查询产生死锁的原因 | |
| I/O | Outstanding Reads(Writes) | 被挂起的物理读(写)，当该值比较大时，可能是CPU、磁盘I/O产生了瓶颈，可以通过服务器的CPU和I/O进一步分析原因 |
| Page Read/sec | 每秒页面读写的次数 | |
| Transactions/sec | 每秒产生的事务数量 |
二、分析方法（针对操作系统）
1、内存分析方法
1）查看Memory\Available Mbytes指标
该值是描述系统可用内存的直接指标，在对系统进行操作系统级别的内存分析时，首先通过该指标建立一个初步的印象，了解系统是否有足够的内存可用。如果值比较小，系统可能出现内存方面的问题，需要进一步分析。
PS：在Unix/Linux系统中，对应的指标是Free(KB)。
2）注意Pages/sec、Pages Read/sec和Page Faults/sec的值
操作系统经常会利用磁盘交换的方式提高系统可用的内存量或内存的使用效率，这三个指标直接反映了操作系统进行磁盘交换的频度。如果Pages/sec的计数持续高于几百？很可能会有内存方面的问题产生，但值很大不一定表明内存有问题，可能是运行使用内存映射文件的程序所致。Pages Faults/sec值表示每秒发生页面失效的次数，页面失效次数越多，说明操作系统向内存中读取的次数越多。此时还需要查看Pages Read/sec，此值阈值为5，如果计数值超过5，则可以判断存在内存方面的问题。
PS：在Unix/Linux系统中，对应的指标是(page)si和(page)so。
3）根据Physical Disk计数器的值分析性能瓶颈
如果Pages Read/sec很低，同时%Disk Time和Average Disk Queue Length的值很高，则可能有磁盘瓶颈。但是如果队列长度增加的同时Pages Read/sec并未降低，则是由于内存不足。
PS：在Unix/Linux系统中，对应的指标是Read(Writes)per sec、Percent of time the disk is busy和Average number of transactions waiting for service。
2、处理器分析方法
1）查看System\%Total Processor Time性能计数器的计数值
此值体现服务器整体的处理器利用率。对多处理系统而言，体现的是所有CPU的平均利用率。如果该值持续超过90%，则说明整个系统面临着处理器方面的瓶颈，可以增加处理器来提高性能。在某些多CPU系统中，该数据本身并不大，但是CPU之间的负载状态很不均衡，也可以视为系统产生了处理器方面的瓶颈。
2）查看每个CPU的Processor\%Processor Time、Processor\%User Time和Processor\%Privileged Time
如果Processor\%User Time值较大，可以考虑是否能通过算法优化等方法优化该值，如果服务器是数据库，Processor\%User Time值打的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。
3）研究系统处理器瓶颈
查看System\Processor Queue Length计数器的值，当大于CPU总量+1时，说明产生了处理器堵塞，在处理器的%Process Time值很高时一般都伴随着处理器堵塞。反之则不然，此时必须查找处理器堵塞的原因。
%DPC Time是另一个需要关注的，该计数值越低越好。在多处理器系统中，如果该值大于50%且Processor\%Processor Time值比较高，则考虑加一个网卡来提高性能。
3、磁盘I/O分析方法
1）计算每磁盘的I/O数
每磁盘的I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘的I/O数超过了磁盘标称的I/O能力，则说明确定存在磁盘的性能瓶颈。
| 每磁盘的I/O的计算方法 | |
| Raid类型 | 计算方法 |
| Raid0 | (Reads+Writes)/Number of Disks |
| Raid1 | (Read+2*Writes)/2 |
| Raid5 | (Read+4*Writes)/Number of Disks |
| Raid10 | (Read+2*Writes)/Number of Disks |
2）与Processor\Privileged Time组合进行分析
如果在Physical Disk计数器中，只有%Disk Time值较大，其他值适中，则硬盘可能会是瓶颈。若几个值都比较大，且数值持续超过80%，则可能是内存泄露。
3）根据Disk sec/Transfer进行分析
一般来说，定义Transfer数值小于15ms为优秀，15~30ms之间为良好，30~60ms之间可以接受，超过60ms则需要考虑更换硬盘或者硬盘的Raid方式了。
4、进程分析方法
1）查看进程的%Processor Time值
该值反映进程消耗的处理器时间。不同进程进行对比，可以轻易看出具体哪个进程在测试过程中消耗了最多的处理器时间，从而据此针对应用进行优化。
2）查看每个进程产生的页面失效
Process\Page Failures/sec与Memory\Page Failures/sec的比值，判断哪个进程产生了最多的页面失效，该进程要么是需要大量内存的进程，要么是非常活跃的进程，可以对其进行重点分析。
3）了解进程的Process\Private Bytes
该值指进程所分配的无法与其他进程共享的当前字节数量，主要用来判断进程在性能测试过程中有无内存泄露。例如一个在IIS上的Web应用，如果测试过程中，进程的Private Bytes计数值不断增加或是测试停止一段时间后，该值仍然持续在高水平，则说明应用存在内存泄露。
PS：在Unix/Linux系统中，对应的指标是Resident Size。
5、网络分析方法
一般的公司都有专门的网络管理人员，网络分析是门技术活，此处仅描述Network Interface\Bytes Total/sec的值。Network Interface\Bytes Total/sec为发送和接收字节的速率(包括帧字符)，可以通过该计数器的值和目前网络的带宽进行比较来判断网络连接速度是否是瓶颈。
PS：在Unix/Linux系统中，可以参照Unix/Linux系统提供的snmp服务接口进行网络分析。
标签：调整 ISE eset 测试 center 内存 故障 err 另一个
原文地址：https://www.cnblogs.com/zichuan/p/10166380.html
