本文目录：
- 1、有没有可以在LINUX下用的来测试硬件性能的工具
- 2、Linux里面uptime命令作用是什么？
- 3、性能测试工具 wrk 使用教程
- 4、Renix Perf IP网络性能测试工具及测试用例参数详解
有没有可以在LINUX下用的来测试硬件性能的工具
网上下载鲁大师。检测显卡。cpu。内存。再下载个cpu-z。这两个软件都是现在比较好用，准确的检测软件。
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’)
– 没有被停止(例如：等待终止)
《内容来自老男孩老师的课堂笔记》
性能测试工具 wrk 使用教程
被面试官经常问到之前开发的系统接口 QPS 能达到多少，经常给不出一个数值，支支吾吾，导致整体面试效果降低？
原因基本是一些公司中，做完功能测试就完了，压根不会有性能测试这一步，或者说并发量较少，没有必要进行性能测试，亦或者，交给测试人员后，只要整体问题不大，测试报告一般也是不会再给后端人员看的，这就导致我们在面试的时候，场面一度尴尬 ！！！
其实，不单单是针对面试，作为一名后端开发者，我们在完成一个接口开发后，在交给测试工程师之前，经常也会想知道，自己写的这个接口的性能如何呢？吞吐量能达到多少？QPS（Query per second 每秒处理完的请求数） 能达到多少呢？
这个时候，我们就需要借助一些常用的性能测试工具，如 Apache ab, Apache JMeter (互联网公司用的较多)，LoadRunner 等。
我们今天主要说一说轻量级性能测试工具 wrk 。
一、什么是 wrk
二、 wrk 的优势劣势
三、wrk 安装
四、如何使用
五、总结
六、参考文档
七、赠送面试学习福利资源
摘自官方 GitHub 上的英文介绍：
翻译一下：
wrk 是一款针对 Http 协议的基准测试工具，它能够在单机多核 CPU 的条件下，使用系统自带的高性能 I/O 机制，如 epoll，kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载。
在说 wrk 的优势之前，瞅一下 wrk 的 GitHub Star 数，也能侧面反映下它的可靠性：
Wow ! 截止笔者截图为止, Star 数已经达到了 19742 !!!
再来说说 wrk 的优势：
wrk 目前仅支持单机压测，后续也不太可能支持多机器对目标机压测，因为它本身的定位，并不是用来取代 JMeter, LoadRunner 等专业的测试工具，wrk 提供的功能，对我们后端开发人员来说，应付日常接口性能验证还是比较友好的。
wrk 只能被安装在类 Unix 系统上，所以我们需要一个 Linux 或者 MacOS 环境。Windows 10 安装需要开启自带的 Ubuntu 子系统。
依次执行如下命令：
依次执行如下命令：
Mac 系统也可以通过先编译的方式来安装，但是更推荐使用 brew 的方式来安装, 步骤如下：
Windown 10 需要在 Windows 功能 里勾选 适用于 Linux 的 Windows 子系统 , 然后通过 bash 命令切换到 Ubuntu 子系统。接下来，参考 3.1.1 Ubuntu 的操作系通中，安装 wrk 的步骤。
命令行中输入命令：
输出如上信息，说明安装成功了！
安装成功了，要如何使用呢？
这条命令表示，利用 wrk 对 发起压力测试，线程数为 12，模拟 400 个并发请求，持续 30 秒。
除了上面简单示例中使用到的子命令参数， wrk 还有其他更丰富的功能，命令行中输入 wrk –help , 可以看到支持以下子命令：
翻译一下：
执行压测命令:
执行上面的压测命令，30 秒压测过后，生成如下压测报告：
我们来具体说一说，报告中各项指标都代表什么意思：
可以看到，压测报告还是非常直观的！
您可能有疑问了，你这种进行 GET 请求还凑合，我想进行 POST 请求咋办？而且我想每次的请求参数都不一样，用来模拟用户使用的实际场景，又要怎么弄呢？
对于这种需求，我们可以通过编写 Lua 脚本的方式，在运行压测命令时，通过参数 –script 来指定 Lua 脚本，来满足个性化需求。
wrk 支持在三个阶段对压测进行个性化，分别是启动阶段、运行阶段和结束阶段。每个测试线程，都拥有独立的Lua 运行环境。
启动阶段:
在脚本文件中实现 setup 方法，wrk 就会在测试线程已经初始化，但还没有启动的时候调用该方法。wrk会为每一个测试线程调用一次 setup 方法，并传入代表测试线程的对象 thread 作为参数。setup 方法中可操作该 thread 对象，获取信息、存储信息、甚至关闭该线程。
运行阶段：
结束阶段：
done() 方法在整个测试过程中只会被调用一次，我们可以从给定的参数中，获取压测结果，生成定制化的测试报告。
自定义 Lua 脚本中可访问的变量以及方法：
变量：wrk
以上定义了一个 table 类型的全局变量，修改该 wrk 变量，会影响所有请求。
方法：
上面三个方法解释如下：
调用 POST 接口：
注意: wrk 是个全局变量，这里对其做了修改，使得所有请求都使用 POST 的方式，并指定了 body 和 Content-Type头。
自定义每次请求的参数：
在 request 方法中，随机生成 1~10000000 之间的 uid，并动态生成请求 URL.
每次请求前，延迟 10ms:
请求的接口需要先进行认证，获取 token 后，才能发起请求，咋办？
上面的脚本表示，在 token 为空的情况下，先请求 /auth 接口来认证，获取 token, 拿到 token 以后，将 token 放置到请求头中，再请求真正需要压测的 /test 接口。
压测支持 HTTP pipeline 的服务：
通过在 init 方法中将三个 HTTP请求拼接在一起，实现每次发送三个请求，以使用 HTTP pipeline。
本文中，我们学习了轻量级性能测试工具 wrk, 如何安装，以及具体的使用方法，包括通过 Lua 脚本来个性化定制请求等。希望读完本文，能对您有所帮助哦！
Renix Perf IP网络性能测试工具及测试用例参数详解
1.1基于软件的网络及应用服务性能测试工具
双臂测试
单臂测试
1.2通过测试端点产生网络流量对网络性能进行测量
TCP、UDP、PING
语音、视频、HTTP、FTP、MAIL、组播
1.3测试端点软件可以免费安装部署
局域网公网
2.1控制端（TestConsole）
●安装于Windows7(64位）
●4核CPU，8GB内存以上
150GB硬盘
2.2测试端点（TestPoint）
●软件测试端点支持Linux、Windows、Android、VxWorks、各种国产OS
●硬件测试端点
3.1专有硬件盒子
3.2支持的OS
Windows；Linux；Android；国产OS
3.3支持的CPU架构x86；PCPU；ARM；MIPS；Alpha
3.4网络接口 以太网；WiFi；3G、4G、5G
真实的协议栈，有状态的Layer3-7应用流量的产生和分析
测试端点支持计算平台广泛，支持高效的客户定制化开发
支持大数据量存储，超长时间的不间断测试
Windows控制端、SQL及NoSQL数据存储
运行于64位 Windows测试管理测试端点资源；测试端点映射；测试用例测试报告
TestPoint输入测试控制端IP运行后注册到测试控制端显示每个TestPoint主机名、IP等信息
创建逻辑（虚拟）测试端点
将测试端点资源中测试端点映射到逻辑测试端点
测试资源与测试配置解耦合
测试配置可分享
无真实测试端点可预先做测试配置
更换测试端点后，无需重新再配置
定义测试用例名称与测试时长用例依次串行方式执行
测试链路配置协议，测试端点1和测试端点2，以及协议参数
1.1通过PC或者手机的WLAN接口包围无线CPE，TestPoint产生流量执行CPE性能测试，
1.2常见测试项目：
无线基准性能测试
无线衰减测试
天线方向性测试
无线信道测试
信道竞争测试
无线并发测试
无线远近距离测试
稳定性测试
环境适应性测试
2.1 在虚拟化平台的VM中部署TestPoint，测试vSwitch的交换性能
2.2常见测试指标：吞吐量；时延；丢失率；乱序
3.1在服务器不同类型OS中部署TestPoint，通过多对一的方式测试服务器网络性能
3.2常见测试指标：吞吐量TCP业务交易速率\交易时间UDP业务交易速率\交易时间
在网络端到端两头部署TestPoint，通过一对一的方式测试网络的承载指标常见测试指标：TCP\UDP吞吐量；单向延迟；抖动；乱序
【linux性能测试工具】的内容来源于互联网，如引用不当，请联系我们修改。
