案例1：某次压力测试，同样并发TPS,但前期性能良好，后期数据库CPU飙升

压测会产生大量级的数据，数据增长会带来性能的损耗
压测数据不合理，导致统一设备关联多个用户，服务端不做限制的in查询
不合理分页，未做页数limit,导致将数据库新增数据全部查询

案例2：响应时间过长，什么原因怎么分析？
  一般响应时间过长有下面几个原因：
（1）服务器硬件资源cpu，内存，磁盘达到瓶颈，可以使用监控命令排查
（2）网络问题导致，比如丢包，带宽不够等等
（3）线程出现死锁，阻塞等问题可以用jstack查看
（4）中间件比如mq消息队列拥堵排队等
（5）数据库层面sql不够优化，没有索引，联合索引失效等，数据库连接数不够。

案例3：压力测试中TPS一直上不去
这个原因比较多，压测整个链路上任何一个环节有瓶颈或者问题都有可能导致
 首先是压力机压力不够，比如用我们笔记本基本压不到那么高TPS，所以我们公司有自己的压测平台，分布式集群压测。
（1）网络带宽，单位时间内网络传输数据量过大，超过带宽处理能力
（2）数据库连接数太少，最大连接数不够
（3）Cpu，内存，磁盘硬件资源达到瓶颈
（4）中间件redis也有可能存在瓶颈比如缓存穿透，缓存过期等等
（5）存在大量线程阻塞，线程死锁等
（6）中间件消息队列拥堵  

案例4:数据库CPU高
问题现象：后台指令发送满负荷工作时，数据库CPU高。
问题原因：后台指令发送线程每次对全量查询结果排序，结果集很大，然后取一条记录；索引区分度不高，满负荷执行时；查询频率很高；压测显示，并行发送指令的后台线程越多，数据库CPU越高，效率越低。
解决方法：
去掉ORDER BY，增加索引后，效果不明显。因为结果集大和查询频繁两个问题没有解决，因此考虑使用设计新的方案。
新方案：设计指令发送线程池，生产者线程每台任务服务器只有一个线程，负责查询待发送指令，每次查询50条指令。每条指令包装成一个Runnable对象，放进ThreadPoolExecutor线程池，线程池大小参数设置为100或200。每当线程池满时，生产者停止生产指令，休息15秒后继续。消费者线程即线程池里的线程，参数设置为4，8或12（和不同指令类型的指令数据量成正比）。
改进后的方案，数据库CPU降到10%一下，发送效率单机提升6倍，且可线性扩展任务服务器。

案例5：内存溢出（堆溢出、栈溢出、持久代溢出）
解决思路：

1、调整堆内存参数，一般是增加堆内存
2、减少批处理数据量

案例5：
线程死锁：容量（压力）测试压测一段时间后，报连接超时
解决思路：
1、造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误
2、找到死锁的线程，分析对应的代码

案例6：压测TPS曲线剧烈下降或抖动
问题现象：50并发压测，TPS曲线正常应该是平缓的，波动不大，如果突然出现剧烈下降，并且短时间内无法恢复，则可能存在问题。
问题原因：一般是由于前置或bp的jvm进行垃圾回收，或者日志记录磁盘满导致的。
解决方法：如果不是特别剧烈的波动或者TPS曲线下降后长时间不反弹，则可以忽略该问题。否则，需要分析曲线下降的时刻，系统当时正在发生的事情。可以通过top命令监控当时CPU占用比价高的线程，也可以kill -3 pid杀javacore来查看线程堆栈。

案例7：CPU高
问题现象：50并发压测，监控工具显示bp、前置CPU占用90%以上。
问题原因：业务处理中存在大量CPU计算操作。
解决方法：采用更高效的算法、数据结构替换原来消耗CPU的代码，或者采用新的设计绕过瓶颈代码，比如查找数据的逻辑，可以把List改为Map，以空间换时间；比如用Json报文替换XML报文，提高传输、解析和打印日志的效率。
导致Cpu计算资源高消耗的代码：报文格式转换、加解密、正则表达式、低效的循环、低效的正则表达式。
排查方法：
压测进行时，使用jvisualvm工具远程连接应用，点抽样器àCPU，点快照生成线程快照。采样一段时间后，抽样器会显示各个方法占用cpu时间，可以针对CPU时间占用高的方法进行优化。
使用tprofiler，jprofiler，OracleDeveloperStudio12.6-linux-x86工具分别分析消耗CPU时间长的方法，以上工具分析结果可能有些差别。针对CPU计算耗时最长的方法进行优化。

案例8：内存泄漏
问题现象：JVM内存耗尽，后台日志抛出OutOfMemeryError异常 ；
问题原因：内存溢出问题可能的原因比较多，可能是全局的List、Map等对象不断被扩大，也可能是程序不慎将大量数据读到内存里；可能是循环操作导致，也可能后台线程定时触发加载数据导致。
解决方法：对于ibmjdk纯java应用，在jvm启动时设置-XX:+HeapDumpOnOutOfMemory Error参数，会在内存溢出时生成heapdump文件。使用ha456.jar工具打开heapdump文件，分析大对象是如何产生的。
当然，在heapdump中对象类型可能只是List这种结构，看不出具体哪个业务代码创建的对象。此时要分析所有的全局对象，列出可疑的List或Map对象，排查其溢出原因。
全局对象、引用的初始化、修改要慎重。建议应用梳理所有可能存放全局对象的代码，统一管控

案例9：打开了太多文件
问题现象：采用合理的并发数压测，交易失败，或后台日志报错：To many open files。
问题原因：
读取配置文件或者业务数据文件后，未关闭文件流；
/etc/security/limits.conf中***打开文件数配置过小。
解决方法：
使用lsof –p pid 命令查看进程打开的文件，如果大部分文件都是同一类型的文件，说明可能未关闭文件流。找到打开文件的代码，关闭文件流即可。
如果不存在未关闭文件流的问题，且业务本身就需要处理大量文件，则修改/etc/security/limits.conf文件如下内容：
* hard nproc 10240
* soft nproc 10240

案例10：
线程阻塞在日志记录上
问题现象：系统响应时间长、通过javacore查看很多线程阻塞在打印日志上。
问题原因：log4j1.x版本较低，性能较差；大报文日志多次输出。
解决方法：
减少无效日志、删除无用日志，减少大日志输出。
升级log4j组件到log4j2，参考log4j2官方文档，配置合理的日志缓冲区，采用高效的Appenders，比如RollingRandomAccessFile。但log4j2仍然采用同步日志，不采用异步日志。因为网银系统日志量较大，异步日志队列很快就满了，如果单条日志存在大报文，还有可能导致内存溢出，因此不适合采用异步日志。如果日志量少（压测产生日志的速度，低于日志写入文件的速度），则可以使用异步日志，大幅提高性能。如果日志量较大，则不建议使用异步日志。
排查方法：
JVM启动参数中增加-XX:+HeapDumpOnCtrlBreak，压测进行时，kill -3 pid 杀几个javacore，使用jca457.jar工具打开并分析。推荐使用该工具，因为该工具可以对所有线程状态进行统计，并生成饼状图，方便查看。
压测进行时，使用jvisualvm获取jvm快照，分析线程堆栈。

案例11、多线程并发问题
问题现象：采用合理的并发数压测，系统出现逻辑错误、交易失败或异常报错。经查是由于对象中变量被异常修改导致。
问题原因：系统中全局对象中的类变量或全局对象，被多个线程修改。
解决方法：排查系统中所有持有全局对象或类变量的代码，检查其全局变量是否可能被多个线程并行修改。
修改方法：
将全局变量转成方法内的局部变量；
对全局变量进行同步控制比如syncronized代码块，或者java.util.concurrent锁
排查方法：并发问题很可能是由全局变量或者对象导致，准确识别全局变量，通过阅读代码找问题。建议应用梳理所有可能存放全局对象的代码，统一管控，或者把所有全局对象放到一个类中，方便管理
案例12：
JMeter Address 占用的问题（jmeter地址占用问题）
搜索之后发现需要在regedit中添加注册表项MaxUserPort，TcpTimedWaitDelay重启一下就可以解决了。
解决方法：
打开注册表：ctrl+r 输入regedit
进入注册表，路径为：\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
新建DWORD值，（十进制）设置为30秒。名称:TcpTimedWaitDe,值:30
新建DWORD值，（十进制）最大连接数65534。名称:MaxUserPort,值:65534

修改完成后重启生效

二、面试题
1、性能问题的六个特征：
（1）、持续缓慢：
（2）、随着时间推进越来越慢、
（3）、随着负载增加越来越慢、
（4）、零星挂起或异常错误、
（5）、可预见的锁定、
（6）、突然混乱、

2、性能瓶颈
性能瓶颈定义：导致系统TPS低、响应时间长、资源（CPU、内存、网络）占用高等问题的
（1）、找到性能瓶颈
瓶颈的类型：
a、网络瓶颈，如带宽，流量等形成的网络环境
b、应用服务瓶颈，如中间件的基本配置，CACHE等
c、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
d、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
e、应用程序本身瓶颈，
关键程序模块。提升该程序模块的性能，可以大幅度改善性能。
常见的性能瓶颈原因包括：数据库慢查询SQL、日志打印、xml大报文解析和格式转换、复杂业务逻辑、锁竞争等。
（2）、如何找到性能瓶颈
使用jmeter或LoadRunner给每个接口的增加事务，记录其响应时间和TPS，最慢的那个接口往往是瓶颈；
分析慢交易的日志，查看是哪个操作耗时最长；
分析数据库快照，看是否有执行较慢或者全表扫描的SQL；
通过Javacore查看线程正在执行的代码，是大部分阻塞在IO上，还是大部分在进行计算。针对不同的问题，使用不同的分析工具。详细内容可以看下一章节。
（3）、针对性能瓶颈进行合理优化
性能优化原则：
先优化瓶颈问题；
方案简单，尽量不引入更多复杂性，尽量不降低业务体验；
满足系统性能要求即可，不引入新的bug。

3、如何定位性能问题？
A. 查看系统日志，日志是定位问题的不二法宝，如果日志记录的全面，很容易通过日志发现问题。
比如，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，我们就可以顺藤摸瓜，很快定位到导致内存溢出的问题在哪里。
B. 利用性能监控工具，比如：JAVA开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。
利用Spotlight可以监控数据库使用情况。
我们需要关注的性能点有：CPU负载，内存使用率，网络I/O等
C. 工具和日志只是手段，除此之外，还需要设计合理的性能测试场景
具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等
好的测试场景，能更加快速的发现瓶颈，定位瓶颈
D. 了解系统参数配置，可以进行后期的性能调优

4、简要说明性能测试流程？
（1） .分析性能需求。 选择用户最常用的场景进行测试，例如登录、搜索和订购。 确定绩效指标。 例如，事务通过率为100%，TOP99%为5秒，最多同时用户1000人，CPU和内存使用率低于70%。
（2）制定性能测试计划，明确测试时间(一般在功能稳定后，如第一次测试后进行)、测试环境和测试工具
（3）编写新能测试用例
（4）建立性能测试环境，准备性能测试数据
（5） 编写性能测试脚本
（6）性能测试脚本优化。 设置检查点、参数化、关联、聚合点、事务，调整思考时间，删除冗长的脚本
（7）设计测试场景，运行测试脚本，监控服务器，
（8）分析测试结果，收集并开发相关日志提单
（9）回归性能测试
（10）写测试报告
（11）性能调优

5、如何确定系统的最大负载？
通过负载测试，增加用户数量。 随着用户数量的增加，各项性能指标也相应变化。 当性能拐点出现时，例如，当用户达到某个订单时，如果响应时间突然增加，则该拐点的对应用户数可以是该系统可以装载的最大用户数。

6、你的系统哪里(哪些功能)进行了性能测试？
我们选择了用户最常用的功能进行了测试，包括登录、搜索和提交订单

7、你们的同时用户数是怎么确定的？
1 )上线一段时间，根据收集到的用户访问数据进行估计
2 )根据需求决定(高峰时间段、注册用户数、1次响应时间等

8、你们的性能测试在什么环境下进行？
独立的性能测试环境进行测试

9、你们的性能测试什么时候进行？
基准测试：功能测试后，在系统稳定时进行。
负载测试：夜深，系统无人使用时

10、如何分析性能测试结果？
首先看事物的通过率，然后分析其他性能指标。 例如，如果测试结果不可靠，如响应时间、事务通过率、CPU等指标是否满足需求，请分析并纠正异常原因，然后重新测试

11、如何识别系统瓶颈？
通过TPS指标分析，TPS是在系统单位时间内处理的事务数量。 观察当前随着用户数量的增加，系统每秒能处理的事务数是否也会增加

12、如何判断系统性能是变好了还是变坏了？
通过基准比较性能指标。

13、你们的性能测试需求来自哪里？
(1) :客户提供需求
(2 )运维需求
(3 )开发提供需求

14.
具有验证码功能。 你怎么做性能测试？
1 )临时屏蔽验证码，完成性能测试后恢复
2 )使用万能的验证码

15.如何加强性能脚本？
如何加强脚本？

1 )参数化
2 )相关
3 )添加事务
4 )添加断言
5 )增加集合点
6 )增加思考时间

知识点：
（1）一个业务有且仅有一个请求连接，那么TPS=QPS=HPS的，而在一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询的次数，用HPS来衡量服务器单击请求
（2）测试的时候就会通过这些指标(HPS,TPS,QPS)的数据来衡量系统的系统，指标越高说明系统性能越好，在一般情况下，各个行业的指标范围有着比较大的差异：
金融行业:1000TPS~50000TPS
保险行业:100TPS~100000TPS
制造业：10TPS~5000TPS
互联网大型网站:10000TPS~1000000TPS
互联网其他:1000TPS~50000TPS
（3）性能调优：
1、硬件上的调优：
一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）、应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）。
2、应用软件上的性能瓶颈：
一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。
例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。
注意：注JDBC连接池连： 连接池的作用：连接池是将已经创建好的连接保存在池中，当有请求来时，直接使用已经创建好的连接对数据库进行访
问。这样省略了创建连接和销毁连接的过程。这样性能上得到了提高。
基本原理是这样的：
（1）建立数据库连接池对象（服务器启动）。
（2）按照事先指定的参数创建初始数量的数据库连接（即：空闲连接数）。
（3）对于一个数据库访问请求，直接从连接池中得到一个连接。如果数据库连接池对象中没有空闲的连接，且连接数没有达到最大（即：最大活跃
连接数），创建一个新的数据库连接。
（4）存取数据库。
（5）关闭数据库，释放所有数据库连接（此时的关闭数据库连接，并非真正关闭，而是将其放入空闲队列中。如实际空闲连接数大于初始空闲连接
数则释放连接）。
（6）释放数据库连接池对象（服务器停止、维护期间，释放数据库连接池对象，并释放所有连接）。
3、应用程序上的性能瓶颈：
一般指的是开发人员新开发出来的应用程序。
例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户方位时性能低下而造成的瓶颈。
4、操作系统上的性能瓶颈：
一般指的是windows、UNIX、Linux等操作系统。
例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大
大增加，这时认为操作系统上出现性能瓶颈。

5、网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。
例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的
交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应
（4）性能指标：
软件性能指标
1、响应时间(RT)
响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间。
响应时间=发起请求网络传输时间+服务器处理时间+返回响应网络传输时间

2、平均响应时间、百分位响应时间
平均响应时间指的是所有请求平均花费的时间，如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms。那么平均响应时间为 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。
百分位数（ Percentile - Wikipedia ）是一个统计学名词。以响应时间为例， 99% 的百分位响应时间 ，指的是 99% 的请求响应时间，都处在这个值以下。
　　拿上面的响应时间来说，其整体平均响应时间虽然为 2.98ms，但 99% 的百分位响应时间却是 100ms。
　　相对于平均响应时间来说，百分位响应时间通常更能反映服务的整体效率。现实世界中用的较多的是 98% 的百分位响应时间，比如 GitHub System Status 中就有一条 98TH PERC. WEB RESPONSE TIME 曲线。
平均响应时间： 所有请求的平均响应时间，取的平均值
95%percentile ： 统计学术语，如果将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为：一组n个观测值按数值大小排列。如，处于p%位置的值称第p百分位数。
例如有100个请求， 每个请求的响应时间分别是 1-100 平均分布
平均响应时间： 1-100 的平均值，即 50.5 
95% percentile ： 按从小到大排序，累计第95百分位，也就是 95 （即样本里95% 的数据都不高于这个值）

3、并发用户数 （最大并发数，最佳并发数）
并发
狭义：指同一时间点，执行相同请求的操作（秒杀）  ======集合点
广义：同一时间点，向服务器发起的请求（更多用于真正的性能测试）
并发数
并发数是指系统同时能处理的请求数量，这个也是反应系统的负载能力

并发用户数
同一时间点，执行请求的用户数
系统用户数：所有注册用户
在线用户数：在线用户，可能发起请求，可能没有发起请求
并发用户数（Jmeter中的线程数）：在线，发起请求用户
如，10个人发起了20个请求

最佳并发用户数：当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待
最大并发用户数：系统的负载一直持续，有些用户在处理而有的用户在自己最大的等待时间内等待的时候我们需要保证
1、最佳并发用户数需大于系统的平均负载
2、系统的最大并发用户数要大于系统需要承受的峰值负载

4,TPS和HPS的区别
TPS（Transaction per second） 是估算应用系统性能的重要依据。其意义是应用系统每秒钟处理完成的交易数量。
一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。 系统整体处理能力取决于处理能力最低模块的TPS 值。依据经验，应用系统的处理能力一般要求在10-100左右。不同应用系统的TPS有着十分大的差别，一般需要通过性能测试进行准确估算。
HPS（Hits per Second）是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和。 它一般和TPS成正比关系，是B/S系统中非常重要的性能指标之一。
throughput：分为网络吞吐量和事务吞吐量，当作为事务吞吐量时，采用TPS来衡量。
当作为网络吞吐量时（LR分析器中的throughput统计图是网络吞吐量），与HPS有一定的联系，但是不是必然的正比关系。
当然在发送的报文或请求的大小一定的情况下，HPS越高，Throughput也相应的越大。
一般情况下，发送报文或请求较大时的HPS会比发送报文或请求较小时的HPS小，但较大报文或请求的Throughput不一定比较小报文或请求的Throughput小
点击数HPS (每秒点击次数)：是指发起请求时, 服务端对请求进行响应的页面资源对应的请求数量.
注意:
1. 日常操作中, 对页面的点击动作不是这里说的点击数
2. 该指标只在 Web 项目中需要注意

5、吞吐量  、吞吐率
吞吐量：单位时间内处理的请求数量（事务/s）（衡量网络）
吞吐量是指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。 
QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。注，网络没有瓶颈的时候，服务器每秒处理的事物数应该等于吞吐量数值
跟吞吐量有关的几个重要是：并发数、响应时间。
QPS（TPS），并发数、响应时间它们三者之间的关系是：
QPS（TPS）= 并发数/平均响应时间
吞吐率：单位时间内通过的数据的平均速率（kB/s）
如，请求数据多少k，这个数据在网络中需要传输的时间

6、事务
指一个客户机向服务器发送请求然后服务器做出反应的过程。
Jmeter中默认一个接口请求就是一个事务。
Jmeter中也支持多个接口整体作为一个事务。

7、TPS/QPS(每秒事务数) (重点）
TPS：服务器每秒处理的事物数（衡量服务器处理能力的综合体现+最主要指标）
TPS是单位时间内处理事务的数量,从代码角度来说,一段代码或多段代码可以组成一个事务.单位时间内完成的事务数越多,服务器的性能越好
QPS：每秒查询率（如登录，可能会查询是否用户已存在，是否已登录，密码是否正确等）
TPS和QPS的区别?
TPS(transaction per second)是单位时间内处理事务的数量，QPS(query per second)是单位时间内请求的数量。TPS代表一个事务的处理，可以包含了多次请求。很多公司用QPS作为接口吞吐量的指标，也有很多公司使用TPS作为标准，两者都能表现出系统的吞吐量的大小，TPS的一次事务代表一次用户操作到服务器返回结果，QPS的一次请求代表一个接口的一次请求到服务器返回结果。当一次用户操作只包含一个请求接口时，TPS和QPS没有区别。当用户的一次操作包含了多个服务请求时，这个时候TPS作为这次用户操作的性能指标就更具有代表性了。
个人理解如下：
1、Tps即每秒处理事务数，包括了
1）用户请求服务器
2）服务器自己的内部处理
3）服务器返回给用户
这三个过程，每秒能够完成N个这三个过程，Tps也就是N；
2、Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。
例如：访问一个页面会请求服务器3次，一次访问，产生一个“T”，产生3个“Q”

8、点击率、点击量
“吞吐率”图和“点击率”图的区别：
“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。
点击数：是衡量Web服务器处理能力的一个重要指标。它的统计是客户端向Web服务器发了多少次HTTP请求计算的。通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
9、错误率
定义: 错误率指系统在负载情况下，失败交易的概率。
错误率 ＝ (失败交易数/交易总数)*100%
注意:
1. 大多系统都会要求无限接近于 100% 成功率, 因此, 错误率一般都非常低
2. 相对稳定的系统产生的错误率又称超时率(由网络传输导致的)
10、资源的利用率（包含cpu、内存、磁盘I/O等）：
定义: 系统资源(CPU/内存/磁盘/网络)使用占比(使用量/总量*100%)
利用率指标:(没有特殊要求情况下)
1. CPU 不超过 75%-85%
2. 内存不超过 80%
3. 硬盘不超过 90%(容量占有率/读写时间比)

CPU进行判断和处理，能反应系统的繁忙程度，一般分系统CPU与用户CPU
Load Average：指一段时间内，CPU正在处理和等待CPU处理的任务，即CPU使用队列的长度统计信息
Memory：数据从内存上读取要比从磁盘上读取的速度要快，而内存经常出现内存泄露或内存溢出的现象
队列：队列较长，说明处理能力达到了极限或者遇到阻塞
IO：与磁盘交互
网络：重点关注网络流量，看是否存在网络带宽瓶颈
注：一般要求资源利用率不超过80%

硬件性能：
cpu
内存
磁盘（disk  I/O）
网络(NETWORK   I/0)
1、CPU
定义：
CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。
参考标准
CPU 利用率要低于业界警戒值范围之内，即小于或者等于75%;
CPU sys%小于或者等于30%;
CPU wait%小于或者等于5%；
2、内存
定义：
内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大
参考标准
现在的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内存是否有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。
3、磁盘
定义：
定义和解释：磁盘吞吐量简称为Disk Throughput，是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。
参考标准
磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于70%。
4、网络
定义：
网络吞吐量简称为Network Throughput，是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。
参考标准
网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。

CPU对数据进行判断以及逻辑处理，本身不能存储数据；这时cpu从内存取数据进行逻辑计算，如果内存没有数据，才会从硬盘读数据到内存，再对数据进行处理
就像人吃饭一样，cpu就是人，内存就是碗，硬盘就是饭锅！
当cpu进程等待，会造成内存开销的增加，内存不够用的时候会用到虚拟内存，导致虚拟内存的增加，这时磁盘IO开销就会增加，系统态sy%提升，cpu开销增加；内存里数据不够用，才用磁盘中取数据。