标签：cache ntile jvm 四次握手 情况 系统负载 最大的 监控 一起
（1）硬件设施（部署结构、机器配置）
（2）网络环境（客户端带宽、服务器端带宽）
（3）操作系统（类型、版本、参数配置）
（4）中间件（类型、版本、参数配置）
（5）应用程序（性能）
（6）并发用户数（系统当前访问状态）
（7）客户端
（8）数据服务器
（9）编程语言、程序实现方式、算法
1、时间特性，主要指的是软件产品的事务响应时间（用户发出请求到收到应答的这段时间）
2、资源利用率，包括：cpu、内存、网络、硬盘、虚拟内存（如Java虚拟机）
3、服务器可靠性，指服务器能在相对高负载情况下持续的运行
4、可配置优化性，指服务器配置优化、业务逻辑优化、代码优化等
1、对资源利用（包括：cpu、内存、网络、硬盘、虚拟内存（如Java虚拟机）等）进行的精确度量；
2、对执行间隔；
3、日志事件（如中断，报错）
4、响应时间
5、吞吐量（TPS）
6、辅助存储区（例如缓冲区、工作区的大小等）
7、处理精度等进行的监测
bs结构程序一般会关注的通用指标如下（简）：
Web服务器测试指标：
* Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）：平均每秒业务脚本的迭代次数，有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Buffer Cache hit ：数据库Cache的命中情况
当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。
我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。一般软件可以按照系统架构分成几种类型：
c/s
client/Server 客户端/服务器架构
基于客户端/服务器的三层架构
基于客户端/服务器的分布式架构
b/s
基于浏览器/Web服务器的三层架构
基于中间件应用服务器的三层架构l
基于Web服务器和中间件的多层架构l
从外部看，性能测试主要关注如下四个指标
从单个请求来看就是服务响应一次请求的花费的时间。但是在性能测试中，单个请求的响应时间并没有什么参考价值，通常考虑的是完成所有请求的平均响应时间及中位数时间。
平均响应时间很好理解，就是完成请求花费的总时间/完成的请求总数。但是平均响应时间有一点不靠谱，因为系统的运行并不是平稳平滑的，如果某几个请求的时间超短或者超长就会导致平均数偏离很多。因此有时候我们会用中位数响应时间。
所谓中位数的意思就是把将一组数据按大小顺序排列，处在最中间位置的一个数叫做这组数据的中位数 ，这意味着至少有50%的数据低于或高于这个中位数。当然，最为正确的统计做法是用百分比分布统计。也就是英文中的TP – Top Percentile ，TP50的意思在，50%的请求都小于某个值，TP90表示90%的请求小于某个时间。
响应时间的指标取决于具体的服务。如智能提示一类的服务，返回的数据有效周期短（用户多输入一个字母就需要重新请求），对实时性要求比较高，响应时间的上限一般在100ms以内。而导航一类的服务，由于返回结果的使用周期比较长（整个导航过程中），响应时间的上限一般在2-5s。
我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。
系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统响应时间；
关键路径是由CPU运算、IO、外部系统响应等等组成。
计算公式
1、响应时间：对一个请求做出响应所需要的时间
网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=网络响应时间+应用程序响应时间=（N1+N2+N3+N4）+(A1+A2+A3)
2、平均响应时间：所有请求花费的平均时间
系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。
如：如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms
平均响应时间： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms并不能反映服务器的整体效率，因为98个请求耗时才1ms，引申出百分位数
百分位数：以响应时间为例，指的是 99% 的请求响应时间，都处在这个值以下，更能体现整体效率。
注：（一般响应时间在3s内，用户会感觉比较满意。在3s~8s之间用户勉强能接受，大于8s用户就可能无法接受，从而刷新页面或者离开，仅供参考）
响应时间与负载对应关系
图中拐点说明：
（1）响应时间突然增加
（2）意味着系统的一种或多种资源利用达到的极限
（3）通常可以利用拐点来进行性能测试分析与定位
一、首先涉及到并发用户数可以从以下几个方面去做数据判断。
1.系统用户数
2.在线用户数
3.并发用户数
二、三者之间的关系
1.在线用户数的预估可以采取20%的系统用户数。例如某个系统在系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考。
2.在线用户数和并发用户数又存在着关系。即：平均并发用户数为:c=NL/T L为在线时长，T为考核时长。例如:考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n*2/8 n为登录系统的用户数，L为登录的时常。例如:一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户则为:c=400*2/8
并发主要是针对服务器而言，在同一时刻与服务器进行交互（指向服务器发出请求）的在线用户数。
（1）并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能。
（2）在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。如多个用户在浏览网页，但没有对同时对服务器进行数据请求，需要与并发用户数区分开。
（3）系统用户数：系统注册的总用户数据
三者之间的关系：系统用户数 >= 在线用户数 >= 并发用户数
同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间
平均并发用户数的计算：C=nL / T
其中C是平均的并发用户数，n是平均每天访问用户数（login session），L是一天内用户从登录到退出的平均时间（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）
并发用户数峰值计算：C^约等于C + 3*根号C 也是峰值C1,即最大并发数，计算公式C1=C+³√C
其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。
注：理解最佳并发用户数和最大并发用户数
看了《LoadRunner没有告诉你的》之理发店模式，对最佳并发用户数和最大的并发用户数的理解小小整理了一下。
所谓的理发店模式，简单地阐述一下，一个理发店有3个理发师，当同时来理发店的客户有3个的时候，那么理发师的资源能够有效地利用，这时3个用户数即为最佳的并发用户数；当理发店来了9个客户的时候，3个客户理发，而6个用户在等待，3个客户的等待时间为1个小时，另外的3个客户的等待时间为2小时，客户的最大忍受时间为3小时包括理发的1个小时，所以6个客户的等待时间都在客户的可以承受范围内，故9个客户是该理发店的最大并发用户数。
我把吞吐量定义为“单位时间内系统处理的客户请求的数量”（ 吞吐量表示单位时间内能够完成的事务数量，因此也被称为每秒事务数（Transaction Per Second），计算方式是完成的事务数除以时间。），直接体现软件系统的性能承载能力，对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。
吞吐量的指标受到响应时间、服务器软硬件配置、网络状态等多方面因素影响。
在低吞吐量下的响应时间的均值、分布比较稳定，不会产生太大的波动。在高吞吐量下，响应时间会随着吞吐量的增长而增长，增长的趋势可能是线性的，也可能接近指数的。当吞吐量接近系统的峰值时，响应时间会出现激增。
系统吞度量要素
一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS(每秒请求数)（TPS （Transaction Per Second）每秒事务数）：每秒钟系统处理的request/事务数量，它是衡量系统处理能力的重要指标；
并发数：系统同时处理的request/事务数
响应时间：一般取平均响应时间
理解了上面三个要素的意义之后，就能推算出它们之间的关系：QPS（TPS）= 并发数/平均响应时间
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。而通常情况下，我们面对需求，我们评估出来的QPS、并发数之外，还有另外一个维度：日页面流量PV。
PV：访问一个URL，产生一个PV（Page View，页面访问量），每日每个网站的总PV量是形容一个 网站规模的重要指标。
UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Visitor，用户访问）
通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。只要能拿到日流量图和QPS我们就可以推算日流量。
通常的技术方法：
1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）
2. 通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。
无论有无思考时间（T_think），测试所得的TPS值和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：TPS=U_concurrent / (T_response+T_think)。
并发数、QPS、平均响应时间三者之间关系
X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。
X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。
同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。
最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发 用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。
Light Load（较轻压力）-----最佳用户数（资源利用最高）---（较重压力，系统可以持续工作，但用户等待时间较长，满意度会下降）-----Heavy Load-------最大并发用户数--------Buckle Zone（用户无法忍受而放弃请求）
最佳并发用户数：当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待
最大并发用户数：系统的负载一直持续，有些用户在处理而有的用户在自己最大的等待时间内等待的时候
我们需要保证的是：
（1）最佳并发用户数需大于系统的平均负载
（2）系统的最大并发用户数要大于系统需要承受的峰值负载
怎么理解这两句话呢？
（1）系统的平均负载：在特定的时间内，系统正在处理的用户数和等待处理的用户数的总和
如果系统的平均负载大于最佳并发用户数，则用户的满意度会下降，所以我们需要保证系统的平均负载小于或者等于最佳并发用户数
（2）峰值：指的是系统的最大能承受的用户数的极值
只有最大并发用户数大于系统所能承受的峰值负载，才不会造成等待空间资源的浪费，导致系统的效率低下
指单位时间内系统处理用户的请求数
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量
从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R /T
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
图中拐点说明：
（1）吞吐量逐渐达到饱和
（2）意味着系统的一种或多种资源利用达到的极限
（3）通常可以利用拐点来进行性能测试分析与定位
超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。
错误率和服务的具体实现有关。通常情况下，由于网络超时等外部原因造成的错误比例不应超过5%%，由于服务本身导致的错误率不应超过1% 。
内部指标|资源指标（与硬件资源消耗相关指标）
资源利用率指的是对不同系统资源的使用程度，一般使用“资源实际使用/总的资源可用量”形成资源利用率。例如服务器的 CPU 利用率、磁盘利用率等。资源利用率是分析系统性能指标进而改善性能的主要依据，因此，它是 Web 性能测试工作的重点。资源利用率主要针对 Web 服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需要采集具体的资源利用率参数来进行分析。
从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等
注：PR数值越小，其进程优先级越高，就优先被执行。
TIME+表示的是这个进程或则命令持续在线活跃了多长时间。
1.硬件性能指标：CPU，内存Memory，磁盘I/O（Disk I/O），网络I/O（Network I/O）
CPU：主要解释计算机指令以及处理计算机软件中的数据
Linux系统中top命令查看CPU的使用率
CPU的利用率（<=75%）有：user（用户使用）,sys（系统调用<=30%）,wait（等待<=5%），idle（空闲）
当user消耗高时，通过top命令查看哪个用户进程占用cpu的使用
user消耗过高的原因可能有:
（1）代码问题。如代码中耗时循环中不加sleep，即例如while的死循环中，没有加sleep时间，导致没有空余的时间将cpu的控制权给其他的进程，一直陷入该死循环中，cpu得不到休息，所以usr的消耗过高，则cpu的消耗高
（2）gc频繁。gc则为垃圾回收，由于垃圾回收也是需要大量的计算，也消耗cpu，所以当gc频繁时也导致usr用户空间的消耗也过高，cpu消耗过高
当sys消耗高时，通过top命令查看系统调用资源的情况
sys消耗过高的原因可能有：
（1）上下文切换频繁。上下文切换发生的情况有：中断处理，多任务处理，用户状态改变。
中断处理，当cpu停止处理当前的进程转而处理中断请求的进程时发生上下文切换。多任务处理则为有多个进程请求cpu的处理，进程的数量多于cpu的核数，则分配进程时间片，根据时间片处理进程，意味着会强制停止一个进程而去处理另一个进程，形成频繁的上下文切换。用户状态改变则为user状态与sys状态的改变。
wait较高时，即等待的进程占比高则可以考虑是否磁盘读写，磁盘瓶颈问题， 等待的进程较多时，cpu无论如何切换都是切换到等待的进程，导致cpu一直在频繁切换等待的线程而利用率较低
内存：与cpu沟通的桥梁，计算机中所有程序的运行都在内存中进行，内存分为物理内存、页面交换（Paging），SWAP内存（虚拟内存）
页面交换：当物理内存即实际的内存满了的时候，将物理内存中不常用的进程调出存储到虚拟内存中，以缓解物理内存空间的压力，所以当物理内存与虚拟内存的数据交换频繁的时候，这时候就要关注下内存的性能情况。
SWAP内存：为进程分配虚拟的内存空间，即调用硬盘的空间作为内存使用。
内存的性能分析是又可用内存与页面交换来分析的，可用内存使用占70%-80%为上限，当超出这个数值，内存性能情况就比较危险，而且即使可用内存使用不超过80%的数值时，页面交换比较频繁时，也是要关注下内存情
一般物理内存即使是满内存也不能代表内存出现问题，主要是看虚拟内存swap，虚拟内存应该<=70%，大于则可以考虑是否内存问题或者内存泄漏
磁盘吞吐量，指单位时间内通过磁盘的数据量。主要关注磁盘的繁忙率，如果高于70%，则磁盘瓶颈
网络吞吐量，指单位时间内通过网络的数据量，当吞吐量大于网路设备或链路最大传输能力，即带宽时，则应该考虑升级网络设备或者增加带宽，Linux命令netstate
网络IO也有可能出现终止连接失败。例如当服务端出现大量的TIME_WAIT，见以下TCP终止连接的第4个步骤，在主动发起关闭连接方接收到结束符FIN时状态变为TIME_WAIT,这时在服务端发现大量的TIME_WAIT,意味着关闭连接是由服务端发起的。
常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。
问？什么情况是由服务端发起关闭连接？答：在用户端的应用程序忘记关闭连接
另外如果在服务端发现大量状态CLOSE_WAIT,则说明第二次关闭回不去，也就是TCP关闭连接的第三个步骤没有执行，停留在CLOSE_WAIT的状态，浏览器如果这时发起请求则会返回超时连接，因为服务端这边一直无法进行第二次关闭，将结束符返回去给用户端。
注：普及TCP连接的三次握手，终止连接的四次握手
TCP三次握手连接：
(1)用户端发送SYN给服务器，用户端的状态为SYN_SEND
(2)服务端接收到后发送ACK给用户端，服务端的状态为SYN_RECV
(3)用户端接收到服务端发送过来的后发送了ACK给服务端，用户端的状态变为Estabilished
TCP终止连接：
(1)用户端的应用主动发起关闭连接，即应用调用close发送FIN给服务端
(2)服务端接收到FIN后发送ACK给用户端，服务端的状态变为CLOSE_WAIT
(3)服务端发送ACK给用户端的同时也将FIN作为一个文件结束符传递给接收端应用程序
(4)用户端的应用程序接收到FIN后将调用close关闭它的套接字，确认FIN，这时用户端的状态变为TIME_WAIT
(5)用户端发送ACK回执给服务端，连接终止
2.中间件：常用的中间件例如web服务器Tomcat,Weblogic web服务器，JVM（java虚拟机），ThreadPool线程池，JDBC数据驱动
注：http服务器和web服务器与应用服务器的差别是一个存储静态网页的服务器，一个是存储css，js等动态加载网页的服务器，而tomcat则属于应用服务器
注：对中间件例如对服务器的性能测试，需要将监控的jmeter-server的文件下载在服务端上，然后开启即可监控被测服务器的性能，或者将监控的软件下载在被测服务器上，远程启动监控软件等
3.数据库指标
应关注SQL，吞吐量，缓存命中率，连接数等，则是关注sql语句执行时间，以微妙为单位，吞吐量TPS，缓存命中率应>=95%
注：对数据库的性能测试通过jemter利用批量的sql语句对数据库进行操作，从而测试数据库的性能，前提是需要将jdbc的驱动加载在测试计划添加的驱动文件中，然后添加jdbc的前置处理器和jdbc的请求sample。
4.JVM，java虚拟机，为使java的代码可以编译运行在不同的平台上顺畅，仿真模拟各种计算机来实现
GC：自动内存管理程序，被引用的对象保存在内存中，当对象不被引用时则释放。关注的参数有Full GC完全java虚拟机垃圾部分回收频率
5.前端指标
前端应该关注页面展示，即首次显示时间，页面数量，页面大小，网络startRender，firstRender等
注：关注前端的性能与后端的性能的不同点在于，前端是每个用户的直观的感受，以及前端页面的加载元素耗费时间给予用户的感受，而后端的性能关注点在于多用户使用系统时，服务器是否能够承受或者服务器的处理能力如何，能否以较好的响应时间响应。
6.Load：系统平均负载，特定时间间隔内运行进程数，Load与cpu核数一致
CPU
指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。
后台服务的所有指令和数据处理都是由CPU负责，服务对CPU的利用率对服务的性能起着决定性的作用。
Linux系统的CPU主要有如下几个维度的统计数据：
us：用户态使用的cpu时间百分比
sy：系统态使用的cpu时间百分比
ni：用做nice加权的进程分配的用户态cpu时间百分比
id：空闲的cpu时间百分比
wa：cpu等待IO完成时间百分比
hi：硬中断消耗时间百分比
si：软中断消耗时间百分比
us & sy：大部分后台服务使用的CPU时间片中us和sy的占用比例是最高的。同时这两个指标又是互相影响的，us的比例高了，sy的比例就低，反之亦然。通常sy比例过高意味着被测服务在用户态和系统态之间切换比较频繁，此时系统整体性能会有一定下降。另外，在使用多核CPU的服务器上，CPU 0负责CPU各核间的调度，CPU 0上的使用率过高会导致其他CPU核心之间的调度效率变低。因此测试过程中CPU 0需要重点关注。
ni：每个Linux进程都有个优先级，优先级高的进程有优先执行的权利，这个叫做pri。进程除了优先级外，还有个优先级的修正值。这个修正值就叫做进程的nice值。一般来说，被测服务和服务器整体的ni值不会很高。如果测试过程中ni的值比较高，需要从服务器Linux系统配置、被测服务运行参数查找原因
id：线上服务运行过程中，需要保留一定的id冗余来应对突发的流量激增。在性能测试过程中，如果id一直很低，吞吐量上不去，需要检查被测服务线程/进程配置、服务器系统配置等。
wa：磁盘、网络等IO操作会导致CPU的wa指标提高。通常情况下，网络IO占用的wa资源不会很高，而频繁的磁盘读写会导致wa激增。如果被测服务不是IO密集型的服务，那需要检查被测服务的日志量、数据载入频率等。
hi & si：硬中断是外设对CPU的中断，即外围硬件发给CPU或者内存的异步信号就是硬中断信号；软中断由软件本身发给操作系统内核的中断信号。通常是由硬中断处理程序或进程调度程序对操作系统内核的中断，也就是我们常说的系统调用(System Call)。在性能测试过程中，hi会有一定的CPU占用率，但不会太高。对于IO密集型的服务，si的CPU占用率会高一些。
内存利用率：
内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。
性能测试过程中对内存监控的主要目的是检查被测服务所占用内存的波动情况。
在Linux系统中有多个命令可以获取指定进程的内存使用情况，最常用的是top命令，如下图所示
其中
VIRT：进程所使用的虚拟内存的总数。它包括所有的代码，数据和共享库，加上已换出的页面，所有已申请的总内存空间
RES：进程正在使用的没有交换的物理内存（栈、堆），申请内存后该内存段已被重新赋值
SHR：进程使用共享内存的总数。该数值只是反映可能与其它进程共享的内存，不代表这段内存当前正被其他进程使用
SWAP：进程使用的虚拟内存中被换出的大小，交换的是已经申请，但没有使用的空间，包括（栈、堆、共享内存）
DATA：进程除可执行代码以外的物理内存总量，即进程栈、堆申请的总空间
从上面的解释可以看出，测试过程中主要监控RES和VIRT，对于使用了共享内存的多进程架构服务，还需要监控SHR。
LOAD（服务器负载）
Linux的系统负载指运行队列的平均长度，也就是等待CPU的平均进程数
从服务器负载的定义可以看出，服务器运行最理想的状态是所有CPU核心的运行队列都为1，即所有活动进程都在运行，没有等待。这种状态下服务器运行在负载阈值下。
通常情况下，按照经验值，服务器的负载应位于阈值的70%~80%，这样既能利用服务器大部分性能，又留有一定的性能冗余应对流量增长。
Linux提供了很多查看系统负载的命令，最常用的是top和uptime
top和uptime针对负载的输出内容相同，都是系统最近1分钟、5分钟、15分钟的负载均值
Uptime命令结果的每一列的含义如下：
“当前时间 系统运行时长 登录的用户数最 近1分钟、5分钟、15分钟的平均负载”
查看系统负载阈值的命令如下，下方是查看CPU每个核心的使用情况：
在性能测试过程中，系统负载是评价整个系统运行状况最重要的指标之一。通常情况下，压力测试时系统负载应接近但不能超过阈值，并发测试时的系统负载最高不能超过阈值的80%，稳定性测试时，系统负载应在阈值的50%左右。
网络
一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。
性能测试中网络监控主要包括网络流量、网络连接状态的监控。
可以使用nethogs命令。该命令与top类似，是一个实时交互的命令，运行界面如下
在后台服务性能测试中，对于返回文本结果的服务，并不需要太多关注在流量方面。
性能测试中对网络的监控主要是监控网络连接状态的变化和异常。对于使用TCP协议的服务，需要监控服务已建立连接的变化情况（即ESTABLISHED状态的TCP连接）。对于HTTP协议的服务，需要监控被测服务对应进程的网络缓冲区的状态、TIME_WAIT状态的连接数等。Linux自带的很多命令如netstat、ss都支持如上功能。下图是netstat对指定pid进程的监控结果
磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。
性能测试过程中，如果被测服务对磁盘读写过于频繁，会导致大量请求处于IO等待的状态，系统负载升高，响应时间变长，吞吐量下降。
Linux下可以用iostat命令来监控磁盘状态，如下图
tps：该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的
kB_read/s：每秒从设备（driveexpressed）读取的数据量，单位为Kilobytes
kB_wrtn/s：每秒向设备（driveexpressed）写入的数据量，单位为Kilobytes
kB_read：读取的总数据量，单位为Kilobytes
kB_wrtn：写入的总数量数据量，单位为Kilobytes
从iostat的输出中，能够获得系统运行最基本的统计数据。但对于性能测试来说，这些数据不能提供更多的信息。需要加上-x参数
rrqm/s：每秒这个设备相关的读取请求有多少被合并了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）
wrqm/s：每秒这个设备相关的写入请求有多少被Merge了
await：每一个IO请求的处理的平均时间（单位是毫秒）
%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，该参数暗示了设备的繁忙程度。
资源利用与负载对应关系
图中拐点说明：
（1）服务器某一资源使用逐渐达到饱和
（2）通常可以利用拐点来进行性能测试分析与定位
性能计数器（counters）
是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析系统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
常见性能瓶颈
吞吐量到上限时系统负载未到阈值：一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因
CPU的us和sy不高，但wa很高：如果被测服务是磁盘IO密集型型服务，wa高属于正常现象。但如果不是此类服务，最可能导致wa高的原因有两个，一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大，如不合理的数据载入策略、log过多等，都有可能导致这种问题。二是服务器内存不足，服务在swap分区不停的换入换出。
同一请求的响应时间忽大忽小：在正常吞吐量下发生此问题，可能的原因有两方面，一是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁；二是Linux本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。
内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位。
性能瓶颈定位之拐点分析法
“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法。它的基本思想就是性能产生瓶颈的主要原因就是因为某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能却出现急剧下降，这样就产生了“拐点”现象。当得到“拐点”附近的资源使用情况时，就能定位出系统的性能瓶颈。
思考时间的计算公式
Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。
在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R = T / TS
下面给出一个计算思考时间的一般步骤：
1、首先计算出系统的并发用户数
C=nL / T F=R×C
2、统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T
3、统计出平均每个用户发出的请求数量
R=u*C*T/VU
4、根据公式计算出思考时间
TS=T/R
监控指标 描述
平均负载 系统正常状态下，最后60秒同步进程的平均个数
冲突率 在以太网上监测到的每秒冲突数
进程/线程交换率 进程和线程之间每秒交换次数
CPU利用率 CPU占用率（%）
磁盘交换率 磁盘交换速率
接收包错误率 接收以太网数据包时每秒错误数
包输入率 每秒输入的以太网数据包数目
中断速率 CPU每秒处理的中断数
输出包错误率 发送以太网数据包时每秒错误数
包输入率 每秒输出的以太网数据包数目
读入内存页速率 物理内存中每秒读入内存页的数目
写出内存页速率 每秒从物理内存中写到页文件中的内存页数
目或者从物理内存中删掉的内存页数目
内存页交换速率 每秒写入内存页和从物理内存中读出页的个数
进程入交换率 交换区输入的进程数目
进程出交换率 交换区输出的进程数目
系统CPU利用率 系统的CPU占用率（%）
用户CPU利用率 用户模式下的CPU占用率（%）
磁盘阻塞 磁盘每秒阻塞的字节数
标签：cache ntile jvm 四次握手 情况 系统负载 最大的 监控 一起
原文地址：https://www.cnblogs.com/laoshuai/p/13131142.html
