jmeter定时器：https://blog.csdn.net/u013258415/article/details/78321288
性能测试的概念和公式：https://www.cnblogs.com/April-Chou-HelloWorld/p/8780384.html
压力测试：https://blog.csdn.net/weixin_52295158/article/details/110576404
压力测试
压力测试分两种场景：一种是单场景，压一个接口的；第二种是混合场景，多个有关联的接口。压测时间，一般场景都运行10-15分钟。如果是疲劳测试，可以压一天或一周，根据实际情况来定。
压测任务需求的确认
压测前要明确压测功能和压测指标，一般需要确定的几个问题：
固定接口参数进行压测还是进行接口参数随机化压测？
要求支持多少并发数？
TPS（每秒钟处理事务数）目标多少？响应时间要达到多少？
压服务器名称还是压服务器IP，一般都是压测指定的服务器
压测设置
线程数：并发数量，能跑多少量。具体说是一次存在多少用户同时访问
Rame-Up Period(in seconds):表示JMeter每隔多少秒发动并发。理解成准备时长：设置虚拟用户数需要多长时间全部启动。如果线程数是20，准备时长为10，那么需要10秒钟启动20个数量，也就是每秒钟启动2个线程。
循环次数：这个设置不会改变并发数，可以延长并发时间。总请求数=线程数*循环次数
调度器：设置压测的启动时间、结束时间、持续时间和启动延迟时间。
压测结果查看
运行完后，聚合报告会显示压测的结果。主要观察Samples、Average、error、Throughput。
Samples:表示一共发出的请求数
Average：平均响应时间，默认情况下是单个Request的平均响应时间（ms）
Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因
Throughput:简称tps,吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps越高说明服务器处理能力越好。
压测结果的分析
有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；
Throughput吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；
压测结束，·登陆相应的web服务器查看CPU等性能指标，进行数据的分析;
最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。
最大的并发数：最大的并发数和最大的tps是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu、网络和cpu都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题。
影响性能考虑点包括：数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面。
jmeter在linux下进行压力测试
jmeter 在linux安装
简单说下，就是要先安装jdk,同时再配置环境变量，最后再上传jmeter压缩的安装包，在linux下解压完安装包就可以使用了。推荐博客：http://blog.csdn.net/zhemeteor/article/details/51315874
jmeter在linux运行
进入jmeter下的bin目录下运行脚本，未配置jmeter环境变量的条件下，运行的命令：
==========================================================================
PS：下面是性能测试的主要概念和计算公式，记录下：
一．系统吞度量要素：
一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。
单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间： 一般取平均响应时间
（很多人经常会把并发数和TPS理解混淆）
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
QPS（TPS）= 并发数/平均响应时间
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
决定系统响应时间要素
我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。
系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间；
关键路径是有CPU运算、IO、外部系统响应等等组成。
二．系统吞吐量评估：
我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。
而通常境况下，我们面对需求，我们评估出来的出来QPS、并发数之外，还有另外一个维度：日PV。
通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。
通常的技术方法：
1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）
2. 通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS和PV关系比例也不一样。
A)淘宝
淘宝流量图：
淘宝的TPS和PV之间的关系通常为 最高TPS：PV大约为 1 : 11*3600 （相当于按最高TPS访问11个小时，这个是商品详情的场景，不同的应用场景会有一些不同）
B) B2B中文站
B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1 : 8个小时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个比例相差很大，可能是因为爬虫暂的比例较高的原因导致。
在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=100*11*3600=396万
这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。
无论有无思考时间（T_think），测试所得的TPS值和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：
TPS=U_concurrent / (T_response+T_think)。
并发数、QPS、平均响应时间三者之间关系
来源：http://www.cnblogs.com/jackei/
软件性能测试的基本概念和计算公式
一、软件性能的关注点
对一个软件做性能测试时需要关注那些性能呢？
我们想想在软件设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角色各自关注的性能点是什么，作为一个软件性能测试工程师，我们又该关注什么？
首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。
对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。
用户关注的是用户操作的相应时间。
其次，我们站在管理员的角度考虑需要关注的性能点。
1、 相应时间
2、 服务器资源使用情况是否合理
3、 应用服务器和数据库资源使用是否合理
4、 系统能否实现扩展
5、 系统最多支持多少用户访问、系统最大业务处理量是多少
6、 系统性能可能存在的瓶颈在哪里
7、 更换那些设备可以提高性能
8、 系统能否支持7×24小时的业务访问
再次，站在开发（设计）人员角度去考虑。
1、 架构设计是否合理
2、 数据库设计是否合理
3、 代码是否存在性能方面的问题
4、 系统中是否有不合理的内存使用方式
5、 系统中是否存在不合理的线程同步方式
6、 系统中是否存在不合理的资源竞争
那么站在性能测试工程师的角度，我们要关注什么呢？
一句话，我们要关注以上所有的性能点。
二、软件性能的几个主要术语
1、响应时间：对请求作出响应所需要的时间
网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=N1+N2+N3+N4+A1+A3+A2
2、并发用户数的计算公式
系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是5000个，那么这个数量，就是系统用户数。
同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间
平均并发用户数的计算：C=nL / T
其中C是平均的并发用户数，n是平均每天访问用户数（login session），L是一天内用户从登录到退出的平均时间（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）
并发用户数峰值计算：C^约等于C + 3*根号C
其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。
3、吞吐量的计算公式
指单位时间内系统处理用户的请求数
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量
从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R /
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
4、性能计数器
是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。
5、思考时间的计算公式
Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。
在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R = T / TS
下面给出一个计算思考时间的一般步骤：
A、首先计算出系统的并发用户数
C=nL / T F=R×C
B、统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、统计出平均每个用户发出的请求数量
R=u*C*T/VU
D、根据公式计算出思考时间
TS=T/R
===================================================
1.解释什么是jmeter?
jmeter是一款java开源工具，用于性能负载测试。它旨在分析和衡量web应用程序和各种服务的性能和负载功能行为。
2.说明jmeter的工作原理？
jmeter就像一群将请求发送到目标服务器的用户一样。它收集来自目标服务器的响应以及其他统计数据，这些统计数据通过图形或表格显示应用程序或服务器的性能。
3.说明可以在哪里使用函数和变量？
变量和函数可以写入任何测试组件的任何字段。
4.提到jmeter中的正则表达式是什么？
根据模式（patterns），使用正则表达式搜索和操作文本。jmeter可用于解释在整个jmeter测试计划中使用的正则表达式或模式的形式。
5.解释什么是采样器（Samplers）和线程组（Thread group）?
线程组：对于任何测试计划，线程组元件都是JMeter的开始部分。这是JMeter的重要元件，你可以在其中设置多个用户和时间来加载线程组中给出的所有用户。
采样器：采样器生成一个或多个采样结果；这些采样结果具有许多属性，例如经过时间、数据大小等。采样器允许JMeter通过采样器将特定类型的请求发送到服务器，线程组决定需要发出的请求类型。一些有用的采样器包括HTTP请求、FTP请求、JDBC请求等等。
6、使用JMeter构建的测试计划是否依赖于操作系统？
通常，测试计划以XML格式保存，因此与任何特定的操作系统都没有关系。它可以在JMeter可以运行的任何操作系统上运行。
7、提到JMeter中处理器的类型是什么？
JMeter中的处理器类型为：①预处理器；②后处理器。
8、解释什么是预置处理器元件？列出一些预处理器元件？
预置处理器是在采样器执行之前发生的事情。为了在执行采样请求之前对其进行配置，或者用于更新未从响应文本中提取的变量，需要使用预处理器元件。
一些预处理器元件是：
- HTTP URL重写修饰符
- HTTP用户参数修饰符
- HTML链接解析器
- BeanShell PreProcessor
9、是否提到测试元件的执行顺序？
测试计划元件的执行顺序为：
配置元件 -> 前置处理器 -> 计时器 -> 取样器 -> 后置处理器 -> 断言 -> 监听器
10、正则表达式中的“包含”和“匹配”表示什么？
在正则表达式中，contains表示正则表达式与目标的至少一部分匹配。匹配表示正则表达式匹配整个目标。如“alphabet”与“al.*t”匹配。
11、解释什么是配置元件？
配置元件与采样器并行工作。要设置默认值和变量以供采样器以后使用，可以使用配置元件。在合并范围的开始，将先处理这些元件，然后再处理同一合并范围中的任何采样器。
12、说明JMeter中的计时器是什么，计时器的类型是什么？
默认情况下，JMeter线程将连续发送请求而不会暂停。为了在请求之间暂停，使用了计时器。使用的一些计时器包括恒定计时器，高斯随机计时器，同步计时器，均匀随机计时器等。
13、解释什么是测试片段？
测试片段也是一种元件，例如“线程组”元件。唯一的区别是，除非模块控制器或包含控制器引用了测试片段，否则不会实现测试片段。
14、解释什么是JMeter中的断言？断言的类型有哪些？
断言有助于验证被测服务器是否返回了预期结果。
JMeter中一些常用的断言是：
- 响应断言
- 持续时间断言
- 大小断言（Size Assertion）
- XML断言
- HTML断言
15、说明如何减少JMeter中的资源需求？
①使用非GUI模式执行测试，如 jmeter –n –t test.jmx –l test.jtl
②在加载期间，测试不使用“查看结果树”或“查看表中的结果”监听器，仅在脚本编写阶段使用它们；
③不要使用功能模式；
④与其使用大量相似的采样器，不如在循环中使用相同的采样器，并使用变量来改变采样；
16、解释如何在JMeter中执行尖峰测试（Spike testing）？
通过同步，可以实现计时器JMeter尖峰测试。同步计时器将阻塞线程，直到阻塞了特定数量的线程，然后将它们全部释放，从而产生了巨大的瞬时负载。
小贴士：尖峰测试 也可以称为冲击测试，反复冲击服务器。指的是在某一瞬间或者多个频次下用户数和压力陡然增加的场景。
17、解释如何在JMeter中捕获身份验证窗口的脚本？
通常，可以通过录制来捕获脚本：
首先，必须在Testplan（测试计划）中使用 Threadgroup，然后在 Workbench（工作台） 中使用HTTP代理服务器；
之后，在“全局设置”框中设置端口号（如8911），然后在 IE高级选项>连接>局域网设置中 开启 代理设置，并将地址修改为localhost，端口改为8911。
然后，HTTP代理服务器中选择 目标控制器 Testplan>Threadgroup，然后启动HTTP代理服务器并运行应用进行登录。
18）列出几个JMeter监听器？
一些JMeter监听器是：
- 集合报告
- 汇总报告
- 查看结果树
- 用表格查看结果
- 图形结果
- BeanShell Listener
- 摘要报告等
19、什么是分布式负载测试？如何实现？
分布式负载测试是整个系统可以用来模拟大量用户负载的过程。通过使用主从配置，JMeter可以进行分布式负载测试。
20、在JMeter中是否有必要显式调用嵌入式资源？
你可以消除所有嵌入式资源的显式调用。请求底部有一个复选框，显示“检索嵌入式资源（retrieve embedded resources.）”。它会捕获所有CSS、JPG等。这是在Web应用中查找资源和断开链接的绝妙方法。
21、解释计时器（Timer）在JMeter中的作用是什么？
在计时器的帮助下，JMeter可以延迟线程发出的每个请求之间的时间。它可以解决服务器的过载问题。
22、解释什么是后置处理器？
要在发出请求后执行任何操作，则使用后处理器。例如，如果JMeter向Web服务器发送HTTP请求，并且如果你希望JMeter在Web服务器显示错误时停止发送请求，那么你将使用后处理器执行此操作。
23、JMeter为性能测试提供什么好处？
JMeter提供性能测试方面的优势，例如：
- 它可以用于测试静态资源和动态资源的性能；
- 它可用于测试网站最大并发用户数，从而分析定位网站瓶颈；
- 它提供了性能报告的图形化分析；
===================================================================
使用工具：Jmeter（版本apache-jmeter-2.13）
安装前提：JDK的安装。
主要对GUI操作界面的讲解
(http://jmeter-plugins.org/downloads/all/为jmeter控件下载的地址)
第一章 录制
学习中，没有对录制进行花费多少时间，可用的计划基本都是自己写的。录制可参考网址http://www.cnblogs.com/TankXiao/p/4064289.html
补充工具BlazeMeter
第二章 工具介绍
主界面
JMeter的主界面主要分为状态栏、菜单栏、工具栏、树形标签栏和内容栏
标题栏（含状态栏）：主要显示计划信息及JMeter版本。
菜单栏：全部的功能的都包含在菜单栏中。
工具栏：工具栏中的按钮在菜单栏都可以找到，工具栏就相当于菜单栏常用功能的快捷按钮。
计划的树形标签栏：树形标签栏通常用来显示测试用例（计划）相关的标签。
内容栏：配合树形标签栏显示，树形标签中点击哪个标签，内容栏中就显示相应的内容和操作。
如下图所示
菜单栏
以下都是简介，具体应用到的时候，可具体说明的。
1. 文件：
关闭：关闭当前打开的JMX文件 。
打开：打开一个JMX文件。
Templates 模板：对常用的功能使用指导。主要有录制、JDBC测试、webserver测试等等，分为基本步骤和详细截图。 如果点用户链接，则会链接到apache jmeter 网站查看详细的步骤和截图指导。
合并：会将多个JMX合并为一个 。
保存测试计划：仅保存测试计划 工作台中添加的内容不会被保存。
保存测试计划为：将测试计划另存。
另存为：可以对工作台和测试计划或者测试例另存为JMX 注意另存为是点哪个位置，存的就是哪个内容。
save as Test fragment：存为一个测试片段，只有线程组、测试计划、工作台不能 保存为一个测试片段。
Revert：还原，将现在的jmx还原为已经保存过的JMX
2. 编辑：
仅介绍部分
Duplicate: 直接复制一份选择的对象到当前菜单下。
Reset Gui: 重置选择对象的GUI内容。
Save Node As Image: 将菜单的配置GUI保存为图片。
Save Screen As Image： 将整个jmeter界面保存为图片。
Toggle: 类似于java中设置断点的意思。
3. 搜索：
Search: 搜索所有配置中匹配的项，匹配成功显示为红色。
Reset Search： 重置搜索，清除搜索结果。
4. 运行：
启动： 启动运行测试计划
Start no pauses: 无停顿启动运行测试计划 1，可以忽略定时器 2，再启动时运行更快
远程启动/停止： 指定一个远程agent运行/停止测试计划。
远程全部启动/停止: 让所有远程agent运行/停止测试。
停止： 停止执行测试计划。
关闭: 关闭测试计划。
Remote Shutdown： 关闭一个指定远程agent。
Remote Shutdown All: 关闭所有远程agent。
远程退出： 指定一个远程agent退出执行。
远程退出全部: 所有远程agent退出执行。
清除： 清除选择菜单的执行结果。
清除全部: 清除所有菜单的执行结果。
5. 选项：
函数助手对话框： 在编写脚本的时候，使用函数助手可以协助生成指定的代码。
外观： jmeter界面样式。
Toolbar: 工具选项，选中可以显示常用工具栏快捷按钮。
Log Viewer： 日志查看器，选中后可以在右下方查看运行日志。
SSL管理器: 导入外置的SSL管理器，用于更好的管理证书, JMeter代理服务器不支持记录 SSL(https)。
选择语言： 选择界面的语言，目前支持中文、英文、法语、德语等等。中文版很多翻译不全，
可以直接使用英文版的。
Collapse All: 展开所有菜单。
Expand All： 折叠所有菜单
6. 帮助：
What’s this node?： 当鼠标放在某个菜单的时候显示其含义。
Enable debug： 开启调试。
Disable debug: 取消调试。
Create a heap dump： 创建堆转储。这是创建当JVM崩溃的堆转储。这个文件可以用堆分析工具（如JHAT），以确定根本原因进行分析。
======================================监控分析的linux命令==================================================
链接https://blog.csdn.net/qq_35590198/article/details/81356598?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control
vmstat命令是最常见的Linux/Unix监控工具，可以展现给定时间间隔的服务器的状态值,包括服务器的CPU使用率，内存使用，虚拟内存交换情况,IO读写情况 一般vmstat工具的使用是通过两个数字参数来完成的，第一个参数是采样的时间间隔数，单位是秒，第二个参数是采样的次数，如: [root@EPG-RH ~]# vmstat 2 1 #2表示每个两秒采集一次服务器状态，1表示只采集一次
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 0 3498472 315836 3819540 0 0 0 1 2 0 0 0 100 0 ----------------
参数解析：
r 表示运行队列(就是说多少个进程真的分配到CPU)，当这个值超过了CPU数目，就会出现CPU瓶颈了。这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。
b 表示阻塞的进程（进程阻塞）
swpd 虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器
free 空闲的物理内存的大小
buff Linux/Unix系统是用来存储，目录里面有什么内容，权限等的缓存
cache cache直接用来记忆我们打开的文件,给文件做缓冲这里是Linux/Unix的聪明之处，把空闲的物理内存的一部分拿来做文件和目录的缓存，是为了提高 程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用
si 每秒从磁盘读入虚拟内存的大小，如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉
so 每秒虚拟内存写入磁盘的大小，如果这个值大于0，同上。
bi 块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte，在处理拷贝大量数据(2-3T)的机器上可以达到140000/s，磁盘写入速度差不多140M每秒
bo 块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。
in 每秒CPU的中断次数，包括时间中断
cs 每秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。
us 用户CPU时间，在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
sy 系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
id 空闲 CPU时间，一般来说，id + us + sy = 100,一般我认为id是空闲CPU使用率，
us是用户CPU使用率，
sy是系统CPU使用率。
wt 等待IO CPU时间。
=============================top命令=====================================
top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。下面详细介绍它的使用方法。top是一个动态显示过程,即可以通过用户按键来不断刷新当前状态.如果在前台执行该命令,它将独占前台,直到用户终止该程序为止.比较准确的说,top命令提供了实时的对系统处理器的状态监视.它将显示系统中CPU最“敏感”的任务列表.该命令可以按CPU使用.内存使用和执行时间对任务进行排序；而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定.
1．命令格式：
top [参数]
2．命令功能：
显示当前系统正在执行的进程的相关信息，包括进程ID、内存占用率、CPU占用率等
3．命令参数：
-b 批处理
-c 显示完整的治命令
-I 忽略失效过程
-s 保密模式
-S 累积模式
-i<时间> 设置间隔时间
-u<用户名> 指定用户名
-p<进程号> 指定进程
-n<次数> 循环显示的次数
4．使用实例：
实例1：显示进程信息
命令：
top
输出：
[root@TG1704 log]# top top - 14:06:23 up 70 days, 16:44, 2 users, load average: 1.25, 1.32, 1.35 Tasks: 206 total, 1 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.9%us, 3.4%sy, 0.0%ni, 90.4%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 32949016k total, 14411180k used, 18537836k free, 169884k buffers Swap: 32764556k total, 0k used, 32764556k free, 3612636k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28894 root 22 0 1501m 405m 10m S 52.2 1.3 2534:16 java 18249 root 18 0 3201m 1.9g 11m S 35.9 6.0 569:39.41 java 2808 root 25 0 3333m 1.0g 11m S 24.3 3.1 526:51.85 java 25668 root 23 0 3180m 704m 11m S 14.0 2.2 360:44.53 java 574 root 25 0 3168m 611m 10m S 12.6 1.9 556:59.63 java 1599 root 20 0 3237m 1.9g 11m S 12.3 6.2 262:01.14 java 1008 root 21 0 3147m 842m 10m S 0.3 2.6 4:31.08 java 13823 root 23 0 3031m 2.1g 10m S 0.3 6.8 176:57.34 java 28218 root 15 0 12760 1168 808 R 0.3 0.0 0:01.43 top 29062 root 20 0 1241m 227m 10m S 0.3 0.7 2:07.32 java 1 root 15 0 10368 684 572 S 0.0 0.0 1:30.85 init 2 root RT -5 0 0 0 S 0.0 0.0 0:01.01 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 5 root RT -5 0 0 0 S 0.0 0.0 0:00.80 migration/1 6 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1 7 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1 8 root RT -5 0 0 0 S 0.0 0.0 0:20.59 migration/2 9 root 34 19 0 0 0 S 0.0 0.0 0:00.09 ksoftirqd/2 10 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/2 11 root RT -5 0 0 0 S 0.0 0.0 0:23.66 migration/3 12 root 34 19 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/3 13 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/3 14 root RT -5 0 0 0 S 0.0 0.0 0:20.29 migration/4 15 root 34 19 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/4 16 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/4 17 root RT -5 0 0 0 S 0.0 0.0 0:23.07 migration/5 18 root 34 19 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/5 19 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/5 20 root RT -5 0 0 0 S 0.0 0.0 0:17.16 migration/6 21 root 34 19 0 0 0 S 0.0 0.0 0:00.05 ksoftirqd/6 22 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/6 23 root RT -5 0 0 0 S 0.0 0.0 0:58.28 migration/7
说明：
统计信息区：
前五行是当前系统情况整体的统计信息区。下面我们看每一行信息的具体意义。
第一行，任务队列信息，同 uptime 命令的执行结果，具体参数说明情况如下：
14:06:23 — 当前系统时间
up 70 days, 16:44 — 系统已经运行了70天16小时44分钟（在这期间系统没有重启过的吆！）
2 users — 当前有2个用户登录系统
load average: 1.15, 1.42, 1.44 — load average后面的三个数分别是1分钟、5分钟、15分钟的负载情况。
load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了。
第二行，Tasks — 任务（进程），具体信息说明如下：
系统现在共有206个进程，其中处于运行中的有1个，205个在休眠（sleep），stoped状态的有0个，zombie状态（僵尸）的有0个。
第三行，cpu状态信息，具体属性说明如下：
5.9%us — 用户空间占用CPU的百分比。
3.4% sy — 内核空间占用CPU的百分比。
0.0% ni — 改变过优先级的进程占用CPU的百分比
90.4% id — 空闲CPU百分比
0.0% wa — IO等待占用CPU的百分比
0.0% hi — 硬中断（Hardware IRQ）占用CPU的百分比
0.2% si — 软中断（Software Interrupts）占用CPU的百分比
备注：在这里CPU的使用比率和windows概念不同，需要理解linux系统用户空间和内核空间的相关知识！
第四行,内存状态，具体信息如下：
32949016k total — 物理内存总量（32GB）
14411180k used — 使用中的内存总量（14GB）
18537836k free — 空闲内存总量（18GB）
169884k buffers — 缓存的内存量 （169M）
第五行，swap交换分区信息，具体信息说明如下：
32764556k total — 交换区总量（32GB）
0k used — 使用的交换区总量（0K）
32764556k free — 空闲交换区总量（32GB）
3612636k cached — 缓冲的交换区总量（3.6GB）
备注：
第四行中使用中的内存总量（used）指的是现在系统内核控制的内存数，空闲内存总量（free）是内核还未纳入其管控范围的数量。纳入内核管理的内存不见得都在使用中，还包括过去使用过的现在可以被重复利用的内存，内核并不把这些可被重新使用的内存交还到free中去，因此在linux上free内存会越来越少，但不用为此担心。
如果出于习惯去计算可用内存数，这里有个近似的计算公式：第四行的free + 第四行的buffers + 第五行的cached，按这个公式此台服务器的可用内存：18537836k +169884k +3612636k = 22GB左右。
对于内存监控，在top里我们要时刻监控第五行swap交换分区的used，如果这个数值在不断的变化，说明内核在不断进行内存和swap的数据交换，这是真正的内存不够用了。
第六行，空行。
第七行以下：各进程（任务）的状态监控，项目列信息说明如下：
PID — 进程id
USER — 进程所有者
PR — 进程优先级
NI — nice值。负值表示高优先级，正值表示低优先级
VIRT — 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES — 进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR — 共享内存大小，单位kb
S — 进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
%CPU — 上次更新到现在的CPU时间占用百分比
%MEM — 进程使用的物理内存百分比
TIME+ — 进程使用的CPU时间总计，单位1/100秒
COMMAND — 进程名称（命令名/命令行）
其他使用技巧：
1.多U多核CPU监控
在top基本视图中，按键盘数字“1”，可监控每个逻辑CPU的状况：
观察上图，服务器有16个逻辑CPU，实际上是4个物理CPU。再按数字键1，就会返回到top基本视图界面。
2.高亮显示当前运行进程
敲击键盘“b”（打开/关闭加亮效果），top的视图变化如下：
我们发现进程id为2570的“top”进程被加亮了，top进程就是视图第二行显示的唯一的运行态（runing）的那个进程，可以通过敲击“y”键关闭或打开运行态进程的加亮效果。
3.进程字段排序
默认进入top时，各进程是按照CPU的占用量来排序的，在下图中进程ID为28894的java进程排在第一（cpu占用142%），进程ID为574的java进程排在第二（cpu占用16%）。
敲击键盘“x”（打开/关闭排序列的加亮效果），top的视图变化如下：
可以看到，top默认的排序列是“%CPU”。
4. 通过”shift + >”或”shift + <”可以向右或左改变排序列
下图是按一次”shift + >”的效果图,视图现在已经按照%MEM来排序。
实例2：显示 完整命令
命令：
top -c
输出：
实例3：以批处理模式显示程序信息
命令：
top -b
实例4：以累积模式显示程序信息
命令：
top -S
实例5：设置信息更新次数
命令：
top -n 2
表示更新两次后终止更新显示
实例6：设置信息更新时间
命令：
top -d 3
说明：
表示更新周期为3秒
实例7：显示指定的进程信息
命令：
top -p 574
输出：
说明：
5.top交互命令
在top 命令执行过程中可以使用的一些交互命令。这些命令都是单字母的，如果在命令行中使用了s 选项， 其中一些命令可能会被屏蔽。
h 显示帮助画面，给出一些简短的命令总结说明
k 终止一个进程。
i 忽略闲置和僵死进程。这是一个开关式命令。
q 退出程序
r 重新安排一个进程的优先级别
S 切换到累计模式
s 改变两次刷新之间的延迟时间（单位为s），如果有小数，就换算成m s。输入0值则系统将不断刷新，默认值是5 s
f或者F 从当前显示中添加或者删除项目
o或者O 改变显示项目的顺序
l 切换显示平均负载和启动时间信息
m 切换显示内存信息
t 切换显示进程和CPU状态信息
c 切换显示命令名称和完整命令行
M 根据驻留内存大小进行排序
P 根据CPU使用百分比大小进行排序
T 根据时间/累计时间进行排序
W 将当前设置写入~/.toprc文件中
===============free 显示内存使用情况=============
free命令可以显示Linux系统中空闲的、已用的物理内存及swap内存,及被内核使用的buffer。在Linux系统监控的工具中，free命令是最经常使用的命令之一。
1．命令格式：
free [参数]
2．命令功能：
free 命令显示系统使用和空闲的内存情况，包括物理内存、交互区内存(swap)和内核缓冲区内存。共享内存将被忽略
3．命令参数：
-b 以Byte为单位显示内存使用情况。
-k 以KB为单位显示内存使用情况。
-m 以MB为单位显示内存使用情况。
-g 以GB为单位显示内存使用情况。
-o 不显示缓冲区调节列。
-s<间隔秒数> 持续观察内存使用状况。
-t 显示内存总和列。
-V 显示版本信息。
4．使用实例：
实例1：显示内存使用情况
命令：
free
free -g
free -m
输出：
[root@SF1150 service]# free
total used free shared buffers cached
Mem: 32940112 30841684 2098428 0 4545340 11363424
-/+ buffers/cache: 14932920 18007192
Swap: 32764556 1944984 30819572
[root@SF1150 service]# free -g
total used free shared buffers cached
Mem: 31 29 2 0 4 10
-/+ buffers/cache: 14 17
Swap: 31 1 29
[root@SF1150 service]# free -m
total used free shared buffers cached
Mem: 32168 30119 2048 0 4438 11097
-/+ buffers/cache: 14583 17584
Swap: 31996 1899 30097
说明：
下面是对这些数值的解释：
total:总计物理内存的大小。
used:已使用多大。
free:可用有多少。
Shared:多个进程共享的内存总额。
Buffers/cached:磁盘缓存的大小。
第三行(-/+ buffers/cached):
used:已使用多大。
free:可用有多少。
第四行是交换分区SWAP的，也就是我们通常所说的虚拟内存。
区别：第二行(mem)的used/free与第三行(-/+ buffers/cache) used/free的区别。 这两个的区别在于使用的角度来看，第一行是从OS的角度来看，因为对于OS，buffers/cached 都是属于被使用，所以他的可用内存是2098428KB,已用内存是30841684KB,其中包括，内核（OS）使用+Application(X, oracle,etc)使用的+buffers+cached.
第三行所指的是从应用程序角度来看，对于应用程序来说，buffers/cached 是等于可用的，因为buffer/cached是为了提高文件读取的性能，当应用程序需在用到内存的时候，buffer/cached会很快地被回收。
所以从应用程序的角度来说，可用内存=系统free memory+buffers+cached。
如本机情况的可用内存为：
18007156=2098428KB+4545340KB+11363424KB
接下来解释什么时候内存会被交换，以及按什么方交换。
当可用内存少于额定值的时候，就会开会进行交换.如何看额定值：
命令：
cat /proc/meminfo
输出：
[root@SF1150 service]# cat /proc/meminfo MemTotal: 32940112 kB MemFree: 2096700 kB Buffers: 4545340 kB Cached: 11364056 kB SwapCached: 1896080 kB Active: 22739776 kB Inactive: 7427836 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 32940112 kB LowFree: 2096700 kB SwapTotal: 32764556 kB SwapFree: 30819572 kB Dirty: 164 kB Writeback: 0 kB AnonPages: 14153592 kB Mapped: 20748 kB Slab: 590232 kB PageTables: 34200 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 49234612 kB Committed_AS: 23247544 kB VmallocTotal: 34359738367 kB VmallocUsed: 278840 kB VmallocChunk: 34359459371 kB HugePages_Total: 0HugePages_Free: 0HugePages_Rsvd: 0Hugepagesize: 2048 kB
交换将通过三个途径来减少系统中使用的物理页面的个数：
1.减少缓冲与页面cache的大小，
2.将系统V类型的内存页面交换出去，
3.换出或者丢弃页面。(Application 占用的内存页，也就是物理内存不足）。
事实上，少量地使用swap是不会影响到系统性能的。
那buffers和cached都是缓存，两者有什么区别呢？
为了提高磁盘存取效率, Linux做了一些精心的设计, 除了对dentry进行缓存(用于VFS,加速文件路径名到inode的转换), 还采取了两种主要Cache方式：Buffer Cache和Page Cache。前者针对磁盘块的读写，后者针对文件inode的读写。这些Cache有效缩短了 I/O系统调用(比如read,write,getdents)的时间。
磁盘的操作有逻辑级（文件系统）和物理级（磁盘块），这两种Cache就是分别缓存逻辑和物理级数据的。
Page cache实际上是针对文件系统的，是文件的缓存，在文件层面上的数据会缓存到page cache。文件的逻辑层需要映射到实际的物理磁盘，这种映射关系由文件系统来完成。当page cache的数据需要刷新时，page cache中的数据交给buffer cache，因为Buffer Cache就是缓存磁盘块的。但是这种处理在2.6版本的内核之后就变的很简单了，没有真正意义上的cache操作。
Buffer cache是针对磁盘块的缓存，也就是在没有文件系统的情况下，直接对磁盘进行操作的数据会缓存到buffer cache中，例如，文件系统的元数据都会缓存到buffer cache中。
简单说来，page cache用来缓存文件数据，buffer cache用来缓存磁盘数据。在有文件系统的情况下，对文件操作，那么数据会缓存到page cache，如果直接采用dd等工具对磁盘进行读写，那么数据会缓存到buffer cache。
所以我们看linux,只要不用swap的交换空间,就不用担心自己的内存太少.如果常常swap用很多,可能你就要考虑加物理内存了.这也是linux看内存是否够用的标准.
如果是应用服务器的话，一般只看第二行，+buffers/cache,即对应用程序来说free的内存太少了，也是该考虑优化程序或加内存了。
实例2：以总和的形式显示内存的使用信息
命令：
free -t
输出：
[root@SF1150 service]# free -t
total used free shared buffers cached
Mem: 32940112 30845024 2095088 0 4545340 11364324
-/+ buffers/cache: 14935360 18004752Swap: 32764556 1944984 30819572
Total: 65704668 32790008 32914660
[root@SF1150 service]#
实例3：周期性的查询内存使用信息
命令：
free -s 10
输出：
[root@SF1150 service]# free -s 10
total used free shared buffers cached
Mem: 32940112 30844528 2095584 0 4545340 11364380
-/+ buffers/cache: 14934808 18005304Swap: 32764556 1944984 30819572
total used free shared buffers cached
Mem: 32940112 30843932 2096180 0 4545340 11364388
-/+ buffers/cache: 14934204 18005908Swap: 32764556 1944984 30819572
说明：
每10s 执行一次命令