USE 方法

用于检查所有资源的使用率（Utilization）、饱和度（Saturation），以及所有硬件资源的错误（Error）

资源: 硬件资源(服务器所有元器件)、软件资源(文件描述符、连接跟踪数、套接字大小、中间件连接数)

使用率:在规定时间间隔内，资源用于服务工作的时间百分比。例如，50%意味着，平均下来，一半的线程在忙于请求的工作。

饱和度:在一定时间间隔内，请求队列的平均长度。这显示出等待工作线程的有多少个请求。

错误:因某种原因，请求被拒绝或失败事件的个数 错误率只能是0.01% 大于该指标则不符合标准。

硬件资源分析-cpu

上下文切换的区别：

进程上下文切换

线程上下文切换 ：

同一个进程中，线程上下文切换，只需要保存，线程所私有资源

不同进程中，线程上下文切换， 先保存线程的私有资源和进程的资源

中断切换

cpu性能分析 -top

从top的输出可以看到cpu的使用率，平均负载等信息

load average: 0.00, 0.05, 0.11：1分钟, 5分钟, 15分钟 系统瓶颈负载值（cpu + io 使用率）

cpu性能分析 -vmstat

从vmstat 可以得到 上下文切换次数（cs），中断次数（in）。 proc 的 r 显示多少进程在等待，b 显示多少进程在不可中断的休眠

cpu性能分析 -pidstat

从pidstat 可以得到cpu使用率， 自愿上下文切换和非自愿上下文切换，可以定位具体的pid

• -u 用于查看cpu的数据
• -w 看cpu的上下文数据
• UID PID
• cswch/s 自愿上下文切换次数
• nvcswch/s 非自愿上下文切换次数

硬件资源分析-内存

常用指标：

已用内存 已使用的内存

剩余内存 未使用的内存

缓存：用来缓存从磁盘读取的数据，加快下次访问的速度

缓冲区：用来缓存将要写入磁盘的数据

内存分析的思路：

1. 用free或top，查看系统整体的内存使用情况
2. 再用vmstat和pidstat，查看一段时间的趋势，从而判断内存问题的类型
3. 最后进行详细的分析，比如java的就会出现OOM （会在响应日志打印）

OOM问题定位

使用jstat命令dump日志 或者使用arthas命令threaddump日志，在使用mat工具分析

内存泄露：StackOverflowError 内存的资源不及时释放，一直占用，导致可用的内存资源越来越少。（内存不够用）

内存溢出：OutOfMemorvError内存泄漏持续到一定时间，可用的空间就会越来越少，下一次程序需要申请比较大的空间时，发现，申请空间不足，已经超过最大可用空间

硬件资源分析-磁盘

磁盘的4个核心指标

使用率:是磁盘处理I/O请求的百分比，过高的使用率，说明磁盘I/0存在性能问题

IOPS:每秒的I/O请求数

吞吐量:描述的I/O请求大小

响应时间:发出I/O请求到收到响应的时间间隔

磁盘分析 - 思路

1. 先用iostat发现磁盘I/o性能瓶颈
2. 再使用pidstat，定位导致瓶颈的进程 io bi/bo
3. 通过vmstat 分析进程的I/o行为，是读取 (bi)还是写(bo)，读数据多时 buffer数据大，写操作时cache 数据大
4. 最后结合应用程序的原理，分析I/o的来源

硬件资源分析-网络

步骤：

1. 在数据链路层，从网络接口的吞吐量，丢包，错误以及中断和网络分析
2. 从网络层，可以从路由的角度分析
3. 在传输层，可以从tcp，udp的协议原理出发，从连接数，吞吐量，延迟进行分析
4. 在应用层，从应用层协议，tps，套接字等分析

优化方案：

win源端口: 去掉keepalive， 改注册表： MaxUserPort 65535、 TcpTimedWaitDelay 30

linux源端口：去掉keepalive，修改最大端口数（sysctl -w net.ipv4.ip_local_port_range="1024 65535"; sysctl -p ，ulimit -n 16000）

目标地址：

修改配置文件中 ulimit -n 16000 ulimit -u 65535 nofile文件，nproc进程

相关问题

cpu使用率很高，需要怎么定位问题？

1. 使用top命令查看指标中是us用户态还是ys系统态指标高。
2. 再使用vmstat 查看 proc 的 r 显示多少进程在等待，b 显示多少进程在不可中断的休眠，上下切换等指标
3. 再使用pidstat 查看是cswch/s 自愿上下文还是nvcswch/s非自愿上下文，定位到具体pid

服务器很卡但是资源利用率不高，需要如何定位

使用top命令查看wa 指标（大量cpu 时间用于等待IO ）

再使用iostat 确定是那一块等待导致的指标高

内存泄露需要怎么定位

使用jmap，arthas dump内存信息，再使用mat 分析具体代码

性能测试前期正常，后期报错，怎么分析?

1. 看报错信息
2. 看系统负载是否恢复正常再开始测试
3. 判断源端口是否够用
4. 根据报错信息，具体分析

tps上不去，可能的原因

• 网络带宽
• IO 问题
• 连接池配置过小 应用连接池、数据库连接池 默认151
• 资源回收问题导致的内存问题 gc、堆栈配置
• 数据库的配置过小
• linux ulimit配置文件未修改
• 通信连接机制： http websocket（性能大于http，包封装比http简单，有效数据更高）
• 硬件 问题
• 脚本本身， beanshell 定时器断言，等组件耗性能
• 压力机 配置问题
• 业务逻辑 复杂的业务耗时
• 系统架构