linux的压力测试命令,Linux压测

Linux里面uptime命令作用是什么？

[root@oldboy ~]# uptime

11:45:25 up 5 days, 13:20, 3 users, load average: 0.00, 0.01, 0.05

uptime内容显示的内容一次是系统时间，开机到现在的天数，用户登录数，以及平均负载。

核心是平均负载，其实就是【单位时间内的活跃进程数】。

2颗，单颗4核CPU为例：

1分钟：10.00 #CPU处理进程1分钟的繁忙程度，忙碌1分钟。

5分钟：8.01 #CPU处理进程5分钟的繁忙程度，忙碌了5分钟

15分钟：5.05 #CPU处理进程15分钟的繁忙程度，忙碌持续15分钟，15分钟内平均值5.

uptime:故障恢复了。

1分钟：1.00 #CPU处理进程1分钟的繁忙程度，忙碌1分钟。

5分钟：8.01 #CPU处理进程5分钟的繁忙程度，忙碌了5分钟

15分钟：5.05 #CPU处理进程15分钟的繁忙程度，忙碌持续15分钟，15分钟内平均值5.

==============================================

总结：15分钟负载值12，是高是低呢

负载数值/总的核心数=1 #开始慢的临界点，实际上1*70%==关注的临界点。

12/8=1.2 大于1就说明有问题。

负载不要超过5，是临界点。

2颗单颗4核CPU，共8核，负载就是8*70%=5左右。

需要关注负载的值：总的核心数*70%=关注的点

==================要掌握的============================

1.平均负载是运行队列中活跃的进程数。

2.平均负载，1,5,15分钟内的负载。

3.需要关注负载的值：总的核心数*70%=关注的点

4.辅助top,ps,uptime,sar,mpstat,pidstat,iostat，排查问题。

5.strace跟踪进程系统调用。

6.记住几个案例（面试讲故事）。

面试官问：

你在工作中遇到过哪些生产故障，是怎么解决的？

最好和数据库相关（负载高），和web相关（PHP进程100%,JAVA内存泄漏）

==================要掌握的============================

***6.平均负载案例分析实战\***

下面，我们以三个示例分别来看这三种情况，并用 stress、mpstat、pidstat 等工具，找出平均负载升高的根源。

stress 是 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。

mpstat 是多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。

pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

#如果出现无法使用mpstat、pidstat命令查看%wait指标建议更新下软件包

yum install sysstats -y

yum install stress -y

stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s

***场景一：CPU 密集型进程\***

1.首先，我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：

[root@oldboy ~]# stress --cpu 1 --timeout 600

2.接着，在第二个终端运行 uptime 查看平均负载的变化情况

# 使用watch -d 参数表示高亮显示变化的区域(注意负载会持续升高)

[root@oldboy ~]# watch -d uptime

*3.最后，在第三个终端运行 mpstat 查看 CPU 使用率的变化情况*

# -P ALL 表示监控所有CPU，后面数字5 表示间隔5秒后输出一组数据

[root@oldboy ~]# mpstat -P ALL 5

#单核CPU,所以只有一个all和0

4.从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.00，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？可以使用 pidstat 来查询


# 间隔5秒输出一组数据

[root@oldboy ~]# pidstat -u 5 1

#从这里可以明显看到，stress进程的CPU使用率为100%。

- 模拟cpu负载高 `stress --cpu 1 --timeout 100`

- 通过uptime或w 查看 `watch -d uptime`

- 查看整体状态mpstat -P ALL 1 查看每个cpu核心使用率

- 精确到进程： pidstat 1

****场景二：I/O 密集型进程\****

1.首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync

[root@oldboy ~]# stress --io 1 --timeout 600s #利用sync()

stress --hdd 8 --hdd-bytes 1g # hd harkdisk 创建进程去进程写

*2.然后在第二个终端运行 uptime 查看平均负载的变化情况：*

[root@oldboy ~]# watch -d uptime

18:43:51 up 2 days, 4:27, 3 users, load average: 1.12, 0.65, 0.00

*3.最后第三个终端运行 mpstat 查看 CPU 使用率的变化情况：*

# 显示所有 CPU 的指标，并在间隔 5 秒输出一组数据

[root@oldboy ~]# mpstat -P ALL 5

#会发现cpu的与内核打交道的sys占用非常高

*4.那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询*

# 间隔5秒后输出一组数据，-u 表示CPU指标

[root@oldboy ~]# pidstat -u 5 1

#可以发现，还是 stress 进程导致的。

- 通过stress 模拟大量进程读写 `stress --hdd 4 `

- 通过w/uptime查看系统负载信息 `watch -d uptime`

- 通过top/mpstat 排查 `mpstat -P ALL 1 或 top 按1`

- 确定是iowati `iostat 1查看整体磁盘读写情况 或iotop -o 查看具体哪个进程读写`

- 根据对应的进程,进行相关处理.

***场景三：大量进程的场景 高并发场景 \***

*当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。*

*1.首先，我们还是使用 stress，但这次模拟的是 4 个进程*

[root@oldboy ~]# stress -c 4 --timeout 600

*2.由于系统只有 1 个 CPU，明显比 4 个进程要少得多，因而，系统的 CPU 处于严重过载状态*

*3.然后，再运行 pidstat 来看一下进程的情况：*

# 间隔5秒后输出一组数据

[root@oldboy ~]# pidstat -u 5 1

*可以看出，4 个进程在争抢 1 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。*

****分析完这三个案例，我再来归纳一下平均负载与CPU\****

***平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：

平均负载高有可能是 CPU 密集型进程导致的；

平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；

当发现负载高的时候，你可以使用 mpstat、pidstat 等工具，辅助分析负载的来源****

**系统负载的计算和意义**

进程以及子进程和线程产生的计算指令都会让cpu执行,产生请求的这些进程组成"运行队列",等待cpu执行,这个队列就是系统负载, 系统负载是所有cpu的运行队列的总和.

[root@oldboyedu ~]# w

20:25:48 up 95 days, 9:06, 1 user, load average: 2.92, 0.00, 0.00

//假设当前计算机有4个核心的cpu,当前的负载是2.92

cpu1 cpu2 cpu3 cpu4

2.94/4(个cpu核心) = 73%的cpu资源被使用,剩下27%的cpu计算资源是空想的

//假设当前的计算有2个核心的cpu,当前的负载是2.92

2.92/2 = 146% 已经验证超过了cpu的处理能力

7. 日常故障排查流程(含日志)

- w/uptime, 查看负载

- ps aux/top 看看 cpu百分比, io wait或者是内存占用的高? (三高 cpu,io,内存)

- top检查具体是哪个进程,找出可疑进程

- 追踪这个进程使用情况,做什么的?

- 看看对应**日志**是否有异常

- 系统日志: /var/log/messages(系统通用日志) /var/log/secure(用户登录情况)

- 服务软件的日志

***3.那平均负载为多少时合理\***

*最理想的状态是每个 CPU核心 上都刚好运行着一个进程，这样每个 CPU 都得到了充分利用。所以在评判平均负载时，首先你要知道系统有几个 CPU核心，这可以通过 top 命令获取，或`grep 'model name' /proc/cpuinfo`*

系统平均负载被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中：

- 它没有在等待I/O操作的结果

- 它没有主动进入等待状态(也就是没有调用'wait')

- 没有被停止(例如：等待终止)

《内容来自老男孩老师的课堂笔记》

相关问答

Q1: 测试开发技术(二)——压力测试

        上一篇文章里说过，目前互联网公司的测试开发岗位分两类。多数的一类是既要负责业务测试、自动化测试，同时也要去开发测试框架、效率工具来辅助业务测试。这类测试开发的岗位（主要指后端的岗位）一般多少都要接触压力测试。

        压力测试、性能测试、负载测试、稳定性测试在网络上有很多文章介绍概念和区别，通常在项目过程中不会区分那么多，实际项目中都是以目标为导向，通常实际项目中都会说，压测一下看下性能，所以这里就不管详细的概念和区别了。为了好理解，我们这里统一叫压测，并以得到性能数据为性能测试，以观察稳定性为稳定性测试。

        性能测试和稳定性测试的相同之处在于都是使用压测工具来进行。但目标不同，性能测试是通过压力测试得到系统的极限性能或者和上一版本的性能对比数据。而稳定性测试则是通过压力测试提供稳定或者变化的持续流量，来观察系统持续运行的情况下是否存在异常。

        正常情况下，一般系统先做性能测试，拿到极限性能或者性能对比数据（对于非1.0项目，性能数据一般需要和上一个版本对比）之后，再通过安全的流量持续压测更长时间，来完成稳定性的验证。

        下面我们就具体介绍一下怎么做性能测试和稳定性测试。

        性能测试的第一步要确定目标，就是为什么要做性能测试，要达到什么样的目标或者效果。比如某个首次上线的系统，性能测试主要是为了得到系统的极限性能数据；再比如，系统优化，更换了RPC协议或者消息队列，性能测试就是为了量化此次系统优化在性能上优化的效果。另外，也不是所有的项目都需要性能测试，比如一个内部系统，用户数和流量本身就很少，而且在未来一段时间也不会有增量，这就基本不需要性能测试。

        如果是从无到有的1.0项目，因为项目还没有上线，所以只能评经验来预估线上的流量数据；但如果是非1.0项目，就可以收集当前的线上数据。具体收集的数据如下（仅供参考，要按照实际情况来调整）：1）被测系统或模块各类请求流量比例；2）系统或模块目前平均、峰值、最小 qps；3）线上部署方式和规模；4）被测系统或模块依赖能承受的QPS或者容量。

        确定目标和收集完线上现有数据之后，需要根据目标和现有数据确定压测方案，比如，每个阶段通过多大并发或者流量来压测、分几个阶段、每个阶段多长时间、以及压测过程中需要观察和记录哪些数据等。

        同时，也要准备压测环境，压测的环境要尽可能的和线上一致，如果达不到，就做等比缩放。比如，一个系统有A、B两个模块组成，线上A部署了20台机器，B部署了5台机器，那么压测就可以A部署4台，B部署1台。机器和实例的数量只是一个方面，同时也要考虑机器的性能（CPU盒数、内存、磁盘、网卡等），还要考虑依赖方（如DB、缓存、消息队列等）的部署。部署压测环境的核心思路就是要用这套环境反应出线上环境的真实情况。

        要进行压力测试就一定要有压测工具，一般来说压测http或者其他开源协议可以在网上找到现成的工具，比如jmater之类的。但如果场景比较特殊，或者使用的是公司或项目的私有协议，就只能使用公司内部的工具或者自己动手开发了。

        选择好压测工具就要构造压测数据了。构造压测数据主要分两点：

        第一点是要构造压测环境系统中的数据。因为线上系统内部一定是有一定数据的，我们要尽量模拟线上就要在系统中添加相应的数据。

        另一点就是要准备压测的请求数据。这点跟选择的压测工具有关，一般来说分2种：

        1）数据词典， 压测的请求提前准备好，存入文件、DB或缓存里，数据量较大的时候一般需要写程序生成。

        2）实时生成，这种是压测工具在压测的时候根据配置规则来实时随机生成请求。

        准备工作一切就绪，下一步就开始做压测的执行。这时候主要就是根据压测方案的从低到高去调整压测工具的并发数或请求数，来对目标系统或模块进行压测。

        压测时，要观察CPU、内存、网络IO、磁盘空间、被压目标日志、依赖系统或者模块的状态等数，也要记录不同并发下目标系统或者模块处理请求的QPS和响应时间。同时也要注意有没有内存泄漏、句柄泄漏、系统崩溃等问题。

        实际上部分数据在记录的过程中就可以初步整理出来。这里要针对上一步记录的数据，进行汇总，主要要产出在不同并发下，上面提到的数据都是什么情况。需要根据数据判断出极限性能，找到这种部署情况下瓶颈在哪，以及是什么原因造成的，为后续扩容提供依据。有些情况还需要跟以前的数据做对比，看性能提升或者下降的程度是不是符合预期。最后，把这些信息综合汇总、分析之后，产出性能测试的报告。

        通常性能测试之后拿到了性能数据之后，都会在安全的并发或者流量下持续压测更长的时间来确保服务的稳定性。比如，笔者通常测试性能的时候，每轮可能压测半小时到一小时（在刚开始并发或者流量较小的时候可能会更短），在得到期限性能之后，会控制极限性能时80%-%90的流量或者并发去压测更长的时间，这个时间一般会比较长，而且多数情况下会在晚上下班前启动，然后第二天到公司来看结果。

        除了长时间通过安全流量来验证外，有些时候在特殊场景下，也需要验证在安全流量范围内，流量急曾或者急降的情况下，稳定性是否有影响。或者，验证在一定流量下，模拟某个依赖或者系统内部的模块出现问题，执行相应预案时，对系统整体的影响是否符合预期。

        当然，稳定性很多情况是异常，但更多的异常会在异常测试里去做，这里的稳定性测试是指在一定流量压力下的稳定性测试，其他的就不做讨论了。

        上面介绍了压力测试里，性能测试和稳定性测试要做什么，那具体怎么做呢？下面我们就通过一个实例来简单介绍一下。

      一个消息推送的系统，推送的消息就是我们日常手机APP的通知消息。这个消息通知的系统有三个接口，分别是单播（指定推送给某个人）、组播（推送给一个组，组里可能有多个人）、广播（推送给APP所有用户）。现在这个系统做了一个重构，更新了内部交互的RPC协议，所以要压一下，跟之前的性能数据做个对比。另外，系统重构前，线上集群极限性能为30000 QPS。

        下面，我们就按照前面的步骤，来简单介绍一下具体怎么做。

      目标就是要得到重构后的系统性能数据，并和原有的做对比，原有的极限性能已知，大概在30000 QPS左右。

        收集线上数据，比如说我们收集到单播、组播、广播的请求比例为5：78：1；组内人数大概在300-1000；发送的消息字符数在30-100这个区间。

        压测方案要先确定部署方案，比如这个系统向上是20台机器（或者实例），压测采用2台机器（等比缩放）。压测机器是线上的1/10，所以我们的目标性能就是3000qps。那么我们压测的方案就可以如下设置：

        第一轮，2个并发，5-10分钟，主要目的是为了先验证环境和压测工具没有问题；

        第二轮，根据上一轮并发数和机器资源（CPU、内存、IO）的情况，调整并发到极限的一半多一些（比如，之前是2个并发，CPU占用10%左右，内存、IO占用都很小，那么就以CPU的占用作为参考来计算，1个并发大概占用5%，那我们就可以吧并发调到10-12，目标CPU占用是50-60%）。这其实才真正开始压测，如果没问题，就开始逐步加压；

        第三轮，开始逐步增加，按照实际情况一次增加2-5个并发，直到性能达到瓶颈。

        这里是假设压测工具通过调整并发数来操作压力，主要需要看下并发对系统CPU、内存、IO的影响，根据压测时机器的资源占用信息来判断增加多少并发。

        确定好方案，就需要部署压测环境了，这里要注意，尽量使用跟线上一致配置的机器。

        压测工具要根据实际业务做选择，必要的时候需要自己开发，工具开发后面如果有机会在其他的文章里介绍，这里就不多介绍了。我们这个例子因为是系统更换内部协议，对外接口不变，所以可以使用原有压测工具。

        下面就是要构造数据：

        首先，要构造系统内部的数据，比如用户信息、设备信息、组信息，这里既要根据线上的收集到的信息来构造，比如用户数、组的数量、组内用户数等。这类如果方便的话可以直接在DB里插入，或者掉相应的系统API来准备。

        然后就是压测的请求数据，比如说压测工具是用数据词典来压测，那么这里我们就通过脚本，来生成压测请求数据。这里要注意线上收集到的各个接口的占比，即5：78：1。压测的时候按照这个比例来提供流量。

        准备工作完成，开始做压测。

        这时候要先吧各类数据观察准备好，一般现在的互联网大厂都有图形化的工具来看，如果没有也可以通过linux的一些命令来看。常用的命令有top\ps\vmstat， 这里推荐使用top来查看实时的资源情况，使用vmstat的来定时输出当资源情况（vmstat -t 1 就是每秒输出一次）。

        准备好了观测，那就启动压测工具，按照方案压测。压测方案上面已经介绍，这里就不重复了。

        假如我们并发加到20个的时候，CPU占用达到85%左右，处理请求达到3600qps，其他资源占用都不足机器的一半；并发加到22个的时候，CPU占用达到95-100，处理请求是3700qps；并发加到24，CPU打满，处理请求3800QPS，并且出现错误日志。这时候就可以停止压测了。

      数据整理，我们首先要整理一个表格或者图标，我们这里用表格：

       这个表格就是压测产出的最核心的数据，由于CPU是明显的性能瓶颈，表格里就不体现其他资源了，如果其他资源使用率也比较高，也要放到这个表格里，又或者瓶颈在外部依赖，也要体现出来。通过这个数据可以看出，3700QPS就是系统处理的极限，安全的流量在3600QPS。这时候就可以用17-20的并发数，长时间压测压测一下，看看系统整体的稳定性。

      那么性能报告怎么写呢？下面就给出一个比较简单的性能报告样例。

        标题：消息推送RPC协议升级性能测试报告

        一、项目背景

                这里写项目背景和目标

        二、压测环境

                线上20台物理机，压测环境使用2台物理机，配置与线上一致，具体如下：

                XX核，XXG内存，万兆网卡，硬盘 400G * 6 SSD

                DB：XX主XX从XX备

        三、压测方案和数据

1. 请求比例

      单播：组播：广播 =  5：78：1

2. 压测过程数据

      3.  资源占用图

    可以把QPS和CPU占用使用工具（比如excel）生成一个折线图，另外，可以把其他资源数占用的数据图片贴一下。

        四、结论

        压测过程中，压力达到3700qp时，内存与IO正常，CPU占用达到98%，无错误日志。压力达到3800qps时CPU打满，且5分钟后开始出现错误日志。因此系统在2台物理机部署极限性能为3700qps，性能瓶颈在CPU，预计线上20台机器极限性能为37000qps.

        系统RPC协议升级前20台机器30000qps，升级后预计能达到37000qps，性能整体提升23%，符合预期。

        上面就是一个比较简单的报告，真实项目中瓶颈不一定是CPU，可能是其他资源，也可能是依赖的系统或者模块，这些都需要观察和分析压测中的数据来得出。

        压力测试是后端测试和测试开发人员的必备技能，这篇文章只是根据笔者的经验针对压力测试进行的总结，不能覆盖所有压测场景，仅给大家做个参考。更多的是需要我们根据系统的实际情况去探索和实践。

Q2: 如何在linux操作系统上做接口压力测试

介绍个http_load压力测试工具,http_load，类似的工具还有webbench、ab、Siege。

1、下载

官方网站：

复制代码

代码如下:

cd /root

wget

tar xzf http_load-12mar2006.tar.gz

2、安装

复制代码

代码如下:

cd http_load-12mar2006

make

执行完make,会在当前目录生成一个http_load二进制文件。

3、使用方法

复制代码

代码如下:

root@www:~/http_load-12mar2006# ./http_load --help

usage: ./http_load [-checksum] [-throttle] [-proxy host:port] [-verbose] [-timeout secs] [-sip sip_file]

-parallel N | -rate N [-jitter]

-fetches N | -seconds N

url_file

One start specifier, either -parallel or -rate, is required.

One end specifier, either -fetches or -seconds, is required.

主要参数说明:

-parallel 简写-p ：含义是并发的用户进程数。

-rate 简写-r ：含义是每秒的访问频率

-fetches 简写-f ：含义是总计的访问次数

-seconds简写-s ：含义是总计的访问时间

选择参数时，-parallel和-rate选其中一个，-fetches和-seconds选其中一个。

示例：

http_load -parallel 50 -s 10 urls.txt

这段命令行是同时使用50个进程，随机访问urls.txt中的网址列表，总共访问10秒。

http_load -rate 50 -f 5000 urls.txt

每秒请求50次，总共请求5000次停止。

4、基本的返回值

（1）．49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds

说明在上面的测试中运行了49个请求，最大的并发进程数是2，总计传输的数据是289884bytes，运行的时间是10.0148秒

（2）．5916 mean bytes/connection

说明每一连接平均传输的数据量289884/49=5916

（3）．4.89274 fetches/sec, 28945.5 bytes/sec

说明每秒的响应请求为4.89274，每秒传递的数据为28945.5 bytes/sec

（4）．msecs/connect: 28.8932 mean, 44.243 max, 24.488 min

说明每连接的平均响应时间是28.8932 msecs，最大的响应时间44.243 msecs，最小的响应时间24.488 msecs

（5）．msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min

（6）.HTTP response codes: code 200 -- 49

说明打开响应页面的类型，如果403的类型过多，那可能要注意是否系统遇到了瓶颈。

特殊说明：这里，我们一般会关注到的指标是fetches/sec、msecs/connect

他们分别对应的常用性能指标参数Qpt-每秒响应用户数和response time，每连接响应用户时间。测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析，我们还需要对服务器的cpu、men进行分析，才能得出结论

5、如果你需要测试https，你必须将 Makefile中

复制代码

代码如下:

# CONFIGURE: If you want to compile in support for https, uncomment these

# definitions. You will need to have already built OpenSSL, available at

# a href="";/a Make sure the SSL_TREE definition points to the

# tree with your OpenSSL installation - depending on how you installed it,

# it may be in /usr/local instead of /usr/local/ssl.

SSL_TREE = /usr

SSL_DEFS = -DUSE_SSL

SSL_INC = -I$(SSL_TREE)/include

SSL_LIBS = -L$(SSL_TREE)/lib -lssl -lcrypto

由于使用到openssl，你必须安装openssl和相应的开发环境

复制代码

代码如下:

apt-get install openssl

apt-get install libssl-dev/p pfind -name ssl.h

/usr/include/openssl/ssl.h