基本流程接口准备--Jmeter配置--运行记录数据--汇总报告1.接口准备考虑因素核心链路、复杂业务、混合场景1核心链路原则遵循二八定律——20%的接口承担了80%的流量。怎么找这些接口看日志如果有Nginx或应用日志统计一下访问频次TOP10的接口问业务运营、产品最清楚哪些功能是用户天天点的自己分析登录、首页、搜索、详情、下单、支付通常是高频区2复杂业务场景复杂查询多表关联、聚合计算、大范围搜索比如历史订单查询批量操作批量导出、批量审核耗内存、耗IO文件处理上传、下载、图片处理耗带宽、耗CPU定时任务整点跑的任务比如结算、对账3混合场景不要只压单个接口要模拟真实用户行为30% 用户浏览首页25% 用户搜索商品20% 用户查看详情15% 用户加购10% 用户下单4不压的接口第三方依赖发短信、发邮件、调用外部支付除非Mock掉写操作且无清理机制直接写数据库且难以删除的数据管理类接口删除数据、修改配置太危险2.Jmeter配置1接口信息根据压测需要的接口设置线程信息并跑通。这些在其他文章内有详细说明此处不展开写。加不加思考时间直接决定了压测是真实场景还是极限压力测试。怎么加思考时间2监听器一些监听器需要先安装 JMeter Plugins Manager 插件管理再在插件管理里安装 Basic Graphs 插件。添加监听器 聚合报告、 jpgc-Transactions per Second、jpgc-Response Times Over Time、jpgc-Response Codes per Second 或 jpgc-Errors per Second聚合报告查看 响应时间TR平均/95线、错误率、吞吐量QPSjpgc-Transactions per Second每秒事务/请求数 TPS走势图jpgc-Response Times Over Time响应时间随时间变化毫秒jpgc-Response Codes per Second 或 jpgc-Errors per Second每秒错误数/错误率趋势3线程组设置根据测试计划配置线程组数据。例如并发档位跑多长时间为什么10、20轻负载5分钟看系统正常时的基线数据50、80中负载5分钟看压力上升时的变化趋势100高负载3分钟找拐点保安全不求极限第一轮线程数10Ramp-Up时间10秒让10个线程在10秒内逐步启动循环次数✓ 勾选永远调度器✓ 勾选调度器持续时间300秒 ← 这就是你问的每轮5分钟启动延迟0注意调度器持续时间需要勾选不然线程会一直跑。4压测数据和实际场景的关联压测里的 TPS 线上真实的 QPS压测里的 RT 线上用户真实感受到的卡顿3.运行记录数据核心原则记录压力下的数据不是空闲数据记录每轮的数据不是只看最终结果记录变化趋势不是孤立数字。1记录模板填写说明CPU%取值方式取压测期间的平均 CPU 使用率或峰值使用率推荐两种记录方式平均空闲率反推CPU% 100 - id空闲率平均值例压测时id稳定在 60% → CPU 使用率 100 - 60 40%直接取进程平均关注核心服务进程如 Java、MySQL的%CPU平均值内存使用% 取值方式取压测期间应用进程的物理内存使用率% MEM平均值或系统整体内存使用率系统层面used / total * 100%从free -h或top的 Mem 行计算进程层面核心服务如 Java%MEM列的平均值填写示例若 Java 进程内存占比稳定在 25%填25%若系统整体内存用了 40%填40%磁盘 IO取值方式用top的waiowait或iostat的%util表示wa方式直接填wa平均值如wa2%%util方式填磁盘繁忙度如%util15%填写示例若wa稳定在 3% → 填wa3%若%util稳定在 10% → 填%util10%若 I/O 无压力 → 填无瓶颈或wa5%关键建议CPU% 优先记录系统整体方便判断是否达到硬件瓶颈磁盘 IO 用wa最直观无需安装工具top直接可见适合快速评估所有指标取「压测稳定阶段的平均值」避免刚启动或结束时的波动数据干扰2用到的命令top命令返回内容解析详见7.top命令数据解读。3运行前记录基线数据服务器空闲状态、应用空闲状态4运行中要盯着这些指标的实时变化记录压测稳定期的平均值5运行结束每一轮压测刚结束的瞬间JMeter停止或你手动停止时立刻记录业务层数据从JMeter拿--不会变服务器资源数据从系统拿--会变填写运行中压测稳定期的平均值中间件数据如果能拿到--会变填写运行中压测稳定期的平均值6拐点怎么看看3张图三个同时变坏就是明确拐点。一边加压一边实时看指标找到拐点立刻停。4.问题汇总和瓶颈分析总结1压测数据解读一看错二看涨三看资源谁跑满四找拐点定极限一看错错误率是否为 0二看涨QPS/TPS 是不是线性涨三看资源CPU / 内存 / IO 谁先到上限四找拐点性能开始变差的那个并发点第一步先看「业务健康度」最优先错误率是否为 0%响应时间TR平均 TR是否在业务可接受范围比如 20ms95 线 TR是否远高于平均 TR说明有长尾请求用户体验差第二步看「性能增长趋势」判断是否线性对比不同并发下的QPS/TPS线性增长并发翻倍 → QPS/TPS 也接近翻倍 → 系统还有富余资源增长放缓并发增加 → QPS/TPS 只涨一点点 → 系统开始触达瓶颈不再增长并发增加 → QPS/TPS 几乎不变 → 系统已达极限第三步定位「资源瓶颈」核心步骤看 CPU / 内存 / 磁盘 IO 三个维度逐个排除第四步找「性能拐点」确定系统极限拐点就是「性能开始明显变差」的那个并发点表现QPS/TPS 增长突然放缓平均 TR/95 线 TR 明显跳涨CPU / 内存 / IO 任一资源跑满操作把多轮数据画成折线图并发→QPS、并发→TR、并发→CPU%三条线里最先出现陡峭变化的地方就是拐点。2TPS 上不去RT 很高2TPS 不涨RT 平稳但错误率上来了3RT 慢慢涨最后雪崩4并发一高直接大量报错5错误率错误率允许多少没有统一答案完全看业务场景、SLA、压测目标。5.总结报告汇总表把各轮数据整理成一张大表变化趋势随着并发增加TPS的变化曲线随着并发增加响应时间的变化曲线资源使用率的变化曲线拐点识别哪一轮开始出现性能下降瓶颈分析CPU先满内存先满磁盘先满结论建议系统建议支撑的最大并发数扩容建议需要多少台机器代码/配置优化建议# 压测总结报告## 测试环境- 应用服务器4核8G- 数据库2核4G- JMeter发压机3台## 测试场景- 接口下单接口- 持续时间每轮5分钟- 并发梯度10、20、50、80、100## 数据汇总| 并发 | TPS | 平均RT | 95线RT | 错误率 | CPU% | 磁盘%util | 瓶颈点 ||------|-----|--------|--------|--------|------|-----------|--------|| 10 | 850 | 45ms | 78ms | 0% | 23% | 12% | 无 || 20 | 1620 | 52ms | 95ms | 0% | 38% | 28% | 无 || 50 | 3800 | 78ms | 156ms | 0.1% | 67% | 65% | CPU接近阈值 || 80 | 5200 | 235ms | 680ms | 3% | 92% | 95% | CPU、磁盘双瓶颈 |## 结论- **系统稳定支撑能力**50并发以内- **性能拐点**80并发时TPS不再线性增长响应时间急剧上升- **主要瓶颈**磁盘IO%util 95%其次是CPU- **优化建议**1. 优化日志写入减少磁盘IO2. 数据库连接池从50调到2003. 扩容建议当前配置建议支撑50并发目标100并发需升级到8核16G6.压测监控命令速查表分类命令核心用途补充说明便于理解和使用系统整体监控top实时监控CPU、内存、进程等核心资源默认按CPU使用率排序按q键退出监控htop实时监控界面更直观、操作更便捷需提前安装yum install htopCentOS/ apt install htopUbuntuuptime快速查看系统运行时间、在线用户数、系统负载输出格式运行时间 在线用户数 1/5/15分钟系统负载负载值越低越好mpstat -P ALL 1统计所有CPU核心的使用率每秒刷新一次-P ALL 显示全部CPU核心1表示刷新间隔单位秒可替换为其他数值free -h查看内存整体使用情况总容量、已用、剩余-h 以人性化单位KB/MB/GB显示避免换算麻烦vmstat 1全面查看系统状态CPU、内存、磁盘I/O、进程1表示每秒刷新重点关注r就绪进程数、si/so内存交换非0则可能内存不足磁盘监控iostat -x 1实时监控磁盘I/O详情排查磁盘瓶颈重点关注%util磁盘使用率接近100%则磁盘满载、awaitI/O等待时间越低越好df -h查看各磁盘分区的使用情况清晰显示分区总容量、已用空间、剩余空间及使用率避免磁盘满导致压测失败网络监控ss -tulnp查看端口监听状态及对应进程参数说明ttcp协议、uudp协议、l监听状态、n数字显示端口、p显示对应进程sar -n DEV 1实时监控网络流量进出带宽、包数重点关注rxpck/s接收包数、txpck/s发送包数判断网络是否拥堵netstat -ant | awk {print $6} | sort | uniq -c统计网络连接状态排查连接异常堆积可查看ESTABLISHED正常连接、TIME_WAIT等待关闭等状态的数量异常时需排查端口或服务tcpdump -i any port 8080指定端口抓包排查网络请求异常8080可替换为目标压测端口按CtrlC停止抓包需提前安装tcpdump进程级监控top -p PID查看指定进程的资源占用CPU、内存PID需替换为目标进程ID可通过top命令先查询高占用进程的PIDps -mp PID -o THREAD,tid,time查看指定进程的线程数、线程ID及运行时间用于排查线程泄露、线程占用过高问题辅助定位CPU高占用原因lsof -p PID | wc -l统计指定进程打开的文件数排查文件句柄泄露超出系统限制会导致进程异常、压测失败pmap -x PID查看指定进程的内存详情物理内存、虚拟内存重点关注RSS物理内存占用、Swap交换内存占用非0则内存不足压测工具命令jmeter -n -t test.jmx -l result.jtl -e -o reportJmeter后台无界面压测生成可视化报告test.jmx压测脚本路径result.jtl压测结果文件report可视化报告目录需提前创建wrk -t 8 -c 1000 -d 60s http://xxxwrk高并发压测模拟多线程多连接请求-t线程数、-c并发连接数、-d压测时长http://xxx替换为目标压测地址ab -n 10000 -c 100 http://xxx/ab简单高效压测适合快速验证接口性能-n总请求数、-c并发数轻量便捷适合快速压测验证siege -c 100 -r 100 http://xxxsiege模拟真实用户请求支持多URL压测-c并发数、-r每个并发的请求次数可搭配URL列表文件使用一键排查组合top → ps -mp PID -o THREAD,tid,time快速排查CPU使用率高的进程及对应线程第一步用top找到高CPU PID第二步查看该进程下的线程占用情况iostat -x 1 → iotop排查磁盘I/O使用率高的进程iotop需提前安装可直接显示I/O占用最高的进程快速定位磁盘瓶颈ss -tulnp | grep 端口排查指定端口是否被占用、对应进程将“端口”替换为目标压测端口如8080、9090快速定位端口占用问题7.TOP命令数据解读第一行任务行TasksTasks: 179 total, 1 running, 178 sleeping, 0 stopped, 0 zombietotal系统总进程数179 个running正在运行的进程数1 个即当前的top命令sleeping休眠 / 等待的进程数178 个stopped被暂停的进程数0 个zombie僵尸进程数0 个正常第二行CPU 行% Cpu (s)%Cpu(s): 0.3 us, 0.9 sy, 0.0 ni, 98.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stus用户态 CPU 占比0.3%业务进程占用sy内核态 CPU 占比0.9%系统调度 / 内核操作ni调整过优先级的用户进程 CPU 占比0.0%id空闲 CPU 占比98.8%当前 CPU 非常空闲wa等待 I/O 的 CPU 占比0.0%无 I/O 阻塞hi硬件中断 CPU 占比0.0%si软件中断 CPU 占比0.0%st虚拟化环境被偷走的 CPU 占比0.0%第三行内存行KiB MemKiB Mem : 16247384 total, 9434812 free, 4069016 used, 2743556 buff/cachetotal总物理内存约 15.5GBfree完全空闲内存约 9GBused已分配使用内存约 3.9GBbuff/cache用于缓存 / 缓冲的内存约 2.6GB可被回收第四行交换分区行KiB SwapKiB Swap: 524284 total, 524284 free, 0 used. 11848188 avail Memtotal交换分区总大小约 512MBfree空闲交换分区全部空闲used已用交换分区0无内存溢出avail Mem可用内存估算约 11.3GB包含可回收缓存表格进程列表表头字段压测时重点关注指标注意按q退出。判断磁盘是否是瓶颈
Jmeter实战--压测 基本流程
基本流程接口准备--Jmeter配置--运行记录数据--汇总报告1.接口准备考虑因素核心链路、复杂业务、混合场景1核心链路原则遵循二八定律——20%的接口承担了80%的流量。怎么找这些接口看日志如果有Nginx或应用日志统计一下访问频次TOP10的接口问业务运营、产品最清楚哪些功能是用户天天点的自己分析登录、首页、搜索、详情、下单、支付通常是高频区2复杂业务场景复杂查询多表关联、聚合计算、大范围搜索比如历史订单查询批量操作批量导出、批量审核耗内存、耗IO文件处理上传、下载、图片处理耗带宽、耗CPU定时任务整点跑的任务比如结算、对账3混合场景不要只压单个接口要模拟真实用户行为30% 用户浏览首页25% 用户搜索商品20% 用户查看详情15% 用户加购10% 用户下单4不压的接口第三方依赖发短信、发邮件、调用外部支付除非Mock掉写操作且无清理机制直接写数据库且难以删除的数据管理类接口删除数据、修改配置太危险2.Jmeter配置1接口信息根据压测需要的接口设置线程信息并跑通。这些在其他文章内有详细说明此处不展开写。加不加思考时间直接决定了压测是真实场景还是极限压力测试。怎么加思考时间2监听器一些监听器需要先安装 JMeter Plugins Manager 插件管理再在插件管理里安装 Basic Graphs 插件。添加监听器 聚合报告、 jpgc-Transactions per Second、jpgc-Response Times Over Time、jpgc-Response Codes per Second 或 jpgc-Errors per Second聚合报告查看 响应时间TR平均/95线、错误率、吞吐量QPSjpgc-Transactions per Second每秒事务/请求数 TPS走势图jpgc-Response Times Over Time响应时间随时间变化毫秒jpgc-Response Codes per Second 或 jpgc-Errors per Second每秒错误数/错误率趋势3线程组设置根据测试计划配置线程组数据。例如并发档位跑多长时间为什么10、20轻负载5分钟看系统正常时的基线数据50、80中负载5分钟看压力上升时的变化趋势100高负载3分钟找拐点保安全不求极限第一轮线程数10Ramp-Up时间10秒让10个线程在10秒内逐步启动循环次数✓ 勾选永远调度器✓ 勾选调度器持续时间300秒 ← 这就是你问的每轮5分钟启动延迟0注意调度器持续时间需要勾选不然线程会一直跑。4压测数据和实际场景的关联压测里的 TPS 线上真实的 QPS压测里的 RT 线上用户真实感受到的卡顿3.运行记录数据核心原则记录压力下的数据不是空闲数据记录每轮的数据不是只看最终结果记录变化趋势不是孤立数字。1记录模板填写说明CPU%取值方式取压测期间的平均 CPU 使用率或峰值使用率推荐两种记录方式平均空闲率反推CPU% 100 - id空闲率平均值例压测时id稳定在 60% → CPU 使用率 100 - 60 40%直接取进程平均关注核心服务进程如 Java、MySQL的%CPU平均值内存使用% 取值方式取压测期间应用进程的物理内存使用率% MEM平均值或系统整体内存使用率系统层面used / total * 100%从free -h或top的 Mem 行计算进程层面核心服务如 Java%MEM列的平均值填写示例若 Java 进程内存占比稳定在 25%填25%若系统整体内存用了 40%填40%磁盘 IO取值方式用top的waiowait或iostat的%util表示wa方式直接填wa平均值如wa2%%util方式填磁盘繁忙度如%util15%填写示例若wa稳定在 3% → 填wa3%若%util稳定在 10% → 填%util10%若 I/O 无压力 → 填无瓶颈或wa5%关键建议CPU% 优先记录系统整体方便判断是否达到硬件瓶颈磁盘 IO 用wa最直观无需安装工具top直接可见适合快速评估所有指标取「压测稳定阶段的平均值」避免刚启动或结束时的波动数据干扰2用到的命令top命令返回内容解析详见7.top命令数据解读。3运行前记录基线数据服务器空闲状态、应用空闲状态4运行中要盯着这些指标的实时变化记录压测稳定期的平均值5运行结束每一轮压测刚结束的瞬间JMeter停止或你手动停止时立刻记录业务层数据从JMeter拿--不会变服务器资源数据从系统拿--会变填写运行中压测稳定期的平均值中间件数据如果能拿到--会变填写运行中压测稳定期的平均值6拐点怎么看看3张图三个同时变坏就是明确拐点。一边加压一边实时看指标找到拐点立刻停。4.问题汇总和瓶颈分析总结1压测数据解读一看错二看涨三看资源谁跑满四找拐点定极限一看错错误率是否为 0二看涨QPS/TPS 是不是线性涨三看资源CPU / 内存 / IO 谁先到上限四找拐点性能开始变差的那个并发点第一步先看「业务健康度」最优先错误率是否为 0%响应时间TR平均 TR是否在业务可接受范围比如 20ms95 线 TR是否远高于平均 TR说明有长尾请求用户体验差第二步看「性能增长趋势」判断是否线性对比不同并发下的QPS/TPS线性增长并发翻倍 → QPS/TPS 也接近翻倍 → 系统还有富余资源增长放缓并发增加 → QPS/TPS 只涨一点点 → 系统开始触达瓶颈不再增长并发增加 → QPS/TPS 几乎不变 → 系统已达极限第三步定位「资源瓶颈」核心步骤看 CPU / 内存 / 磁盘 IO 三个维度逐个排除第四步找「性能拐点」确定系统极限拐点就是「性能开始明显变差」的那个并发点表现QPS/TPS 增长突然放缓平均 TR/95 线 TR 明显跳涨CPU / 内存 / IO 任一资源跑满操作把多轮数据画成折线图并发→QPS、并发→TR、并发→CPU%三条线里最先出现陡峭变化的地方就是拐点。2TPS 上不去RT 很高2TPS 不涨RT 平稳但错误率上来了3RT 慢慢涨最后雪崩4并发一高直接大量报错5错误率错误率允许多少没有统一答案完全看业务场景、SLA、压测目标。5.总结报告汇总表把各轮数据整理成一张大表变化趋势随着并发增加TPS的变化曲线随着并发增加响应时间的变化曲线资源使用率的变化曲线拐点识别哪一轮开始出现性能下降瓶颈分析CPU先满内存先满磁盘先满结论建议系统建议支撑的最大并发数扩容建议需要多少台机器代码/配置优化建议# 压测总结报告## 测试环境- 应用服务器4核8G- 数据库2核4G- JMeter发压机3台## 测试场景- 接口下单接口- 持续时间每轮5分钟- 并发梯度10、20、50、80、100## 数据汇总| 并发 | TPS | 平均RT | 95线RT | 错误率 | CPU% | 磁盘%util | 瓶颈点 ||------|-----|--------|--------|--------|------|-----------|--------|| 10 | 850 | 45ms | 78ms | 0% | 23% | 12% | 无 || 20 | 1620 | 52ms | 95ms | 0% | 38% | 28% | 无 || 50 | 3800 | 78ms | 156ms | 0.1% | 67% | 65% | CPU接近阈值 || 80 | 5200 | 235ms | 680ms | 3% | 92% | 95% | CPU、磁盘双瓶颈 |## 结论- **系统稳定支撑能力**50并发以内- **性能拐点**80并发时TPS不再线性增长响应时间急剧上升- **主要瓶颈**磁盘IO%util 95%其次是CPU- **优化建议**1. 优化日志写入减少磁盘IO2. 数据库连接池从50调到2003. 扩容建议当前配置建议支撑50并发目标100并发需升级到8核16G6.压测监控命令速查表分类命令核心用途补充说明便于理解和使用系统整体监控top实时监控CPU、内存、进程等核心资源默认按CPU使用率排序按q键退出监控htop实时监控界面更直观、操作更便捷需提前安装yum install htopCentOS/ apt install htopUbuntuuptime快速查看系统运行时间、在线用户数、系统负载输出格式运行时间 在线用户数 1/5/15分钟系统负载负载值越低越好mpstat -P ALL 1统计所有CPU核心的使用率每秒刷新一次-P ALL 显示全部CPU核心1表示刷新间隔单位秒可替换为其他数值free -h查看内存整体使用情况总容量、已用、剩余-h 以人性化单位KB/MB/GB显示避免换算麻烦vmstat 1全面查看系统状态CPU、内存、磁盘I/O、进程1表示每秒刷新重点关注r就绪进程数、si/so内存交换非0则可能内存不足磁盘监控iostat -x 1实时监控磁盘I/O详情排查磁盘瓶颈重点关注%util磁盘使用率接近100%则磁盘满载、awaitI/O等待时间越低越好df -h查看各磁盘分区的使用情况清晰显示分区总容量、已用空间、剩余空间及使用率避免磁盘满导致压测失败网络监控ss -tulnp查看端口监听状态及对应进程参数说明ttcp协议、uudp协议、l监听状态、n数字显示端口、p显示对应进程sar -n DEV 1实时监控网络流量进出带宽、包数重点关注rxpck/s接收包数、txpck/s发送包数判断网络是否拥堵netstat -ant | awk {print $6} | sort | uniq -c统计网络连接状态排查连接异常堆积可查看ESTABLISHED正常连接、TIME_WAIT等待关闭等状态的数量异常时需排查端口或服务tcpdump -i any port 8080指定端口抓包排查网络请求异常8080可替换为目标压测端口按CtrlC停止抓包需提前安装tcpdump进程级监控top -p PID查看指定进程的资源占用CPU、内存PID需替换为目标进程ID可通过top命令先查询高占用进程的PIDps -mp PID -o THREAD,tid,time查看指定进程的线程数、线程ID及运行时间用于排查线程泄露、线程占用过高问题辅助定位CPU高占用原因lsof -p PID | wc -l统计指定进程打开的文件数排查文件句柄泄露超出系统限制会导致进程异常、压测失败pmap -x PID查看指定进程的内存详情物理内存、虚拟内存重点关注RSS物理内存占用、Swap交换内存占用非0则内存不足压测工具命令jmeter -n -t test.jmx -l result.jtl -e -o reportJmeter后台无界面压测生成可视化报告test.jmx压测脚本路径result.jtl压测结果文件report可视化报告目录需提前创建wrk -t 8 -c 1000 -d 60s http://xxxwrk高并发压测模拟多线程多连接请求-t线程数、-c并发连接数、-d压测时长http://xxx替换为目标压测地址ab -n 10000 -c 100 http://xxx/ab简单高效压测适合快速验证接口性能-n总请求数、-c并发数轻量便捷适合快速压测验证siege -c 100 -r 100 http://xxxsiege模拟真实用户请求支持多URL压测-c并发数、-r每个并发的请求次数可搭配URL列表文件使用一键排查组合top → ps -mp PID -o THREAD,tid,time快速排查CPU使用率高的进程及对应线程第一步用top找到高CPU PID第二步查看该进程下的线程占用情况iostat -x 1 → iotop排查磁盘I/O使用率高的进程iotop需提前安装可直接显示I/O占用最高的进程快速定位磁盘瓶颈ss -tulnp | grep 端口排查指定端口是否被占用、对应进程将“端口”替换为目标压测端口如8080、9090快速定位端口占用问题7.TOP命令数据解读第一行任务行TasksTasks: 179 total, 1 running, 178 sleeping, 0 stopped, 0 zombietotal系统总进程数179 个running正在运行的进程数1 个即当前的top命令sleeping休眠 / 等待的进程数178 个stopped被暂停的进程数0 个zombie僵尸进程数0 个正常第二行CPU 行% Cpu (s)%Cpu(s): 0.3 us, 0.9 sy, 0.0 ni, 98.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stus用户态 CPU 占比0.3%业务进程占用sy内核态 CPU 占比0.9%系统调度 / 内核操作ni调整过优先级的用户进程 CPU 占比0.0%id空闲 CPU 占比98.8%当前 CPU 非常空闲wa等待 I/O 的 CPU 占比0.0%无 I/O 阻塞hi硬件中断 CPU 占比0.0%si软件中断 CPU 占比0.0%st虚拟化环境被偷走的 CPU 占比0.0%第三行内存行KiB MemKiB Mem : 16247384 total, 9434812 free, 4069016 used, 2743556 buff/cachetotal总物理内存约 15.5GBfree完全空闲内存约 9GBused已分配使用内存约 3.9GBbuff/cache用于缓存 / 缓冲的内存约 2.6GB可被回收第四行交换分区行KiB SwapKiB Swap: 524284 total, 524284 free, 0 used. 11848188 avail Memtotal交换分区总大小约 512MBfree空闲交换分区全部空闲used已用交换分区0无内存溢出avail Mem可用内存估算约 11.3GB包含可回收缓存表格进程列表表头字段压测时重点关注指标注意按q退出。判断磁盘是否是瓶颈
