1. 为什么在Linux服务器上线前必须做这五类压力测试
刚接手某公司新部署的云服务器集群时，我第一件事不是配环境、不是跑服务，而是花整整两天时间，把CPU、内存、IO、网络、硬盘这五块全拉出来“练一遍”。结果第三天凌晨，监控告警炸了——数据库连接池耗尽，但服务器负载却只有0.3。排查三小时才发现，是磁盘IOPS在高并发写入时突降70%，而默认监控根本没覆盖这个维度。这件事让我彻底放弃“系统装好就等于稳了”的幻想。Linux下真正的稳定性，从来不是看top里那几个数字漂不漂亮，而是看它在极限压测下是否还守得住底线。这五类测试不是可选项，而是上线前的强制安检：CPU测试验证计算资源调度是否健康；内存测试揪出OOM Killer误杀隐患；IO测试暴露存储栈瓶颈（从文件系统到NVMe驱动）；网络测试检验TCP栈参数与网卡中断亲和性；硬盘读写速度测试则直接决定数据库、日志、缓存等所有依赖存储的服务生死线。标题里提到的三个系统资源监控工具——vmstat、iostat、sar——它们不是用来“看看而已”的装饰品，而是你压测时的眼睛和听诊器：vmstat告诉你内存页交换是否失控，iostat揭示IO等待队列是否已排起长队，sar则用历史采样帮你定位那个“只在凌晨2点发作”的诡异抖动。如果你还在靠htop和free -h判断服务器健康，那相当于用体温计去诊断心脏病——量程不对，精度不够，更关键的是，它根本不会告诉你“什么时候会出事”。
2. 压力测试设计逻辑与工具选型依据
2.1 为什么不用stress-ng做全部？——分层施压的底层逻辑
很多新手一上来就apt install stress-ng，然后stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 1G --timeout 60s一把梭。实测下来，这种“大杂烩”式压测有三大硬伤：第一，它把CPU、内存、IO混在一起压，当系统卡顿时，你根本分不清是CPU调度失灵、内存回收太慢，还是磁盘响应延迟飙升；第二，stress-ng的IO子模块（如--hdd）本质是顺序写大文件，完全模拟不了数据库那种随机小IO+元数据操作的混合负载；第三，它无法控制网络层压力，而现代微服务架构里，网络延迟和丢包率对整体SLA的影响，往往比CPU占用率更致命。所以我的方案是严格分层：用sysbench专攻CPU与内存（因其可精确控制线程数、内存访问模式、缓存行大小）；用fio接管IO与硬盘测试（因其支持定义IO引擎、队列深度、随机/顺序比例、读写混合比）；用iperf3独立打网络（因其能分别测试TCP吞吐与UDP丢包，还能指定TCP窗口大小与MSS）；最后用stress-ng仅作为辅助验证——比如在IO压测后，用stress-ng --cpu 1 --timeout 10s快速确认CPU是否被IO抢占导致调度异常。这种拆解不是为了炫技，而是为了拿到可归因的结论。就像修车，你得先确定是火花塞问题、油路堵塞，还是ECU故障，而不是把发动机整个泡水里再捞出来看哪个零件锈了。
2.2 监控工具为何锁定vmstat/iostat/sar？——它们不可替代的观测维度
标题里点名的三个工具，网上教程常把它们并列成“基础监控三件套”，但实际使用中，它们解决的是完全不同的观测盲区：
vmstat的核心价值在于内存与进程调度的耦合分析。它的r（运行队列长度）和b（阻塞进程数）字段，配合si（swap in）和so（swap out），能直接回答一个关键问题：“当前负载升高，是因为CPU真忙，还是因为进程在等IO或内存换页？”比如当r持续>4且b也>2，同时si/so为0，说明CPU确实过载；但如果r高而b更高，且wa（IO等待）>30%，那问题根源就在存储层，而非CPU本身。iostat的不可替代性在于IO请求的微观解剖。await（平均IO等待时间）和svctm（平均服务时间）的差值，就是IO请求在队列里排队的时间。当await远大于svctm（比如await=80ms而svctm=5ms），说明磁盘队列已严重积压，此时再看%util（设备利用率）接近100%就非常危险——这不是“磁盘很忙”，而是“请求已排到门外”。而iostat -x输出的r_await/w_await、r/s/w/s、rkB/s/wkB/s，能让你一眼看出是读密集型（如CDN节点）还是写密集型（如日志收集器）瓶颈。sar的终极优势是时间维度上的回溯能力。vmstat和iostat都是实时快照，而sar -u 1 60能每秒采样CPU，连续60秒生成完整曲线；sar -b 2 30则记录每2秒的IO统计，30次后自动保存到/var/log/sysstat/。这意味着压测结束后，你可以用sar -f /var/log/sysstat/saXX | grep '02:15'精准定位到故障发生前30秒的每一帧状态，而不是靠记忆去猜“大概那时候CPU飙高了”。某次线上事故复盘，正是靠sar -r（内存）和sar -n DEV（网络）的交叉时间戳，发现OOM Killer触发前17秒，eth0的rx_packets突降90%，最终定位到网卡驱动bug。
提示：这三个工具都属于
sysstat包，安装只需apt install sysstat（Debian/Ubuntu）或yum install sysstat（CentOS/RHEL）。注意启动systemctl enable sysstat并systemctl start sysstat，否则sar的历史数据将为空。
2.3 硬盘测试为何必须区分“顺序读写”与“随机读写”？
很多人测硬盘只跑dd if=/dev/zero of=/test bs=1M count=1024 oflag=direct，得出“写入速度800MB/s”的结论就收工。这就像用百米冲刺成绩评估越野车性能——完全错位。企业级应用的真实IO模式，90%以上是随机小IO：
- 数据库（MySQL/PostgreSQL）：单次查询可能触发多次4KB随机读（索引页、数据页、日志页）；
- 容器镜像加载：拉取一个镜像需并发读取数千个分散的小文件；
- 虚拟机磁盘：每个VM的虚拟磁盘文件在宿主机上表现为大量随机IO。
fio的威力正在于此。它用--rw=randread模拟数据库读负载，用--rw=randwrite模拟日志写入，用--bs=4k匹配主流文件系统块大小，用--iodepth=32模拟高并发场景下的队列深度。实测一块标称“500MB/s顺序写”的NVMe盘，在fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --iodepth=32 --size=1G --runtime=60 --time_based下，随机写IOPS可能只有12000，远低于顺序写的300000。这个差距，才是决定你数据库QPS上限的真实天花板。
3. 五类压力测试的完整实操流程与参数详解
3.1 CPU压力测试：不只是让核心满载，更要验证调度公平性
CPU测试的目标不是“把%us打到100%”，而是验证在多任务竞争下，关键进程能否获得足够CPU时间片。我常用sysbench的CPU模块，因其可精确控制计算强度：
# 1. 安装sysbench（Ubuntu/Debian） apt update && apt install -y sysbench # 2. 执行CPU压测：模拟16线程，每线程执行素数计算至10000 sysbench cpu --threads=16 --cpu-max-prime=10000 run关键参数解析：
--threads=16：启动16个工作线程，对应16个逻辑CPU核心。若服务器是8核16线程（超线程），此值设为16能充分压测调度器；--cpu-max-prime=10000：每个线程计算从1到10000的所有素数。数值越大，单次计算耗时越长，CPU占用越稳定。设为10000时，单线程计算约耗时2.3秒，避免因计算过快导致线程频繁切换；run：执行测试（prepare用于准备，cleanup用于清理，CPU测试无需）。
压测中同步监控：
# 在另一个终端，每秒刷新一次vmstat，重点关注r（运行队列）、%us（用户态CPU）、%sy（内核态CPU） vmstat 1 # 同时用pidstat观察sysbench进程的CPU亲和性 pidstat -t -p $(pgrep sysbench) 1实操心得：当vmstat显示r值持续大于CPU核心数+2（如16核机器r>18），且%sy占比超过30%，说明内核调度开销过大，需检查是否启用了intel_idle.max_cstate=1（禁用深层C-State）或调整/proc/sys/kernel/sched_min_granularity_ns。某次在KVM虚拟机中压测，r值飙升但%us仅60%，最终发现是宿主机CPU资源争抢，而非Guest OS问题。
3.2 内存压力测试：直击OOM Killer与Swap陷阱
内存测试的核心矛盾是：既要制造足够压力触发内存回收，又不能让OOM Killer直接杀死关键进程。sysbench的内存模块比stress-ng --vm更可控：
# 1. 创建2GB内存测试文件（避免首次分配时的延迟干扰） sysbench memory --memory-total-size=2G prepare # 2. 执行测试：16线程，每次操作1MB，总操作10000次 sysbench memory --threads=16 --memory-block-size=1M --memory-total-size=2G --memory-oper=read run参数深挖：
--memory-block-size=1M：每次内存操作的块大小。设为1MB能有效绕过CPU缓存，真实反映内存带宽；--memory-oper=read：指定操作类型为读（也可用write或none）。读操作主要消耗内存带宽，写操作则触发页面分配与脏页回写；--memory-total-size=2G：总测试内存大小，应小于系统可用内存（free -g中的available值），留出至少2GB给系统进程。
压测中必盯的监控项：
# 实时查看内存页回收状态（重点关注pgmajfault：主缺页次数） watch -n1 'cat /proc/vmstat | grep -E "pgpgin|pgpgout|pgmajfault|pgpgin"' # 检查swap使用（一旦so>0，说明已开始swap，测试失败） vmstat 1 | awk 'NR==3 {print "swap-in:" $6 " swap-out:" $7}' # 查看OOM Killer日志（压测后立即执行） dmesg -T | grep -i "killed process"注意：若
vmstat中so（swap out）持续>0，或dmesg出现Out of memory: Kill process，说明内存压力过大。此时应降低--memory-total-size，或检查/proc/sys/vm/swappiness（建议生产环境设为1，而非默认60）。
3.3 IO与硬盘读写速度测试：fio的12种实战配置
fio是IO测试的瑞士军刀，其配置文件（.fio）可精确描述任何IO场景。以下是我日常使用的12种核心配置，按企业应用优先级排序：
场景1：数据库随机读IOPS（OLTP核心指标）
# db_randread.fio [global] ioengine=libaio direct=1 runtime=60 time_based group_reporting [randread] name="DB Random Read" filename=/test/db_test rw=randread bs=4k iodepth=16 numjobs=4bs=4k：匹配InnoDB页大小；iodepth=16：模拟数据库连接池大小（如max_connections=100，按6:1估算IO队列深度≈16）；numjobs=4：4个并发进程，总IOPS = 单job IOPS × 4。
场景2：日志顺序写吞吐（如Kafka、ES）
# log_seqwrite.fio [global] ioengine=libaio direct=1 runtime=60 time_based group_reporting [seqwrite] name="Log Sequential Write" filename=/test/log_test rw=write bs=128k iodepth=64 numjobs=2bs=128k：日志写入通常批量提交，128KB是常见优化值；iodepth=64：高吞吐场景需深队列，但需结合/sys/block/nvme0n1/queue/nr_requests（默认128）调整。
场景3：容器镜像加载（随机读+元数据）
# container_load.fio [global] ioengine=libaio direct=1 runtime=60 time_based group_reporting [container_read] name="Container Load" filename=/test/container_test rw=randread bs=16k iodepth=32 numjobs=8bs=16k：Docker镜像层文件大小多在16KB~64KB区间；numjobs=8：模拟8个容器并发启动。
执行与解读：
# 运行测试 fio db_randread.fio # 关键输出解读（截取） # iops : min=11234, max=12890, avg=12056, stdev=421 # lat (usec) : 2=0.01%, 4=0.02%, 10=0.15%, 20=1.23%, 50=25.67%, 100=42.33% # lat (usec) : 250=28.45%, 500=1.89%, 750=0.22%, 1000=0.03% # lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%avg=12056：平均IOPS为12056，即每秒12056次4KB随机读；lat (usec)：延迟分布，50=25.67%表示25.67%的请求在50微秒内完成，100=42.33%表示累计68%的请求在100微秒内完成。企业级NVMe盘的P99延迟应<200μs，SATA SSD则常>1ms。
实操心得：测试前务必用
hdparm -I /dev/nvme0n1 | grep "Nominal Media"确认磁盘是否启用TRIM（Nominal Media Rotation Rate: Solid State Device），未启用TRIM的SSD在长期写入后IOPS会衰减30%以上。某次测试一块旧SSD，随机写IOPS从初始8000跌至2000，重置后恢复，证实是写放大导致。
3.4 网络压力测试：iperf3的TCP与UDP双模验证
网络测试必须区分TCP（可靠传输）与UDP（实时流媒体），因二者瓶颈点完全不同：
TCP吞吐测试（验证带宽与TCP栈）
# 服务端（监听3389端口，不限制窗口大小） iperf3 -s -p 3389 # 客户端（4线程，并发传输，报告每秒速率） iperf3 -c 192.168.1.100 -p 3389 -t 60 -P 4 -i 1-P 4：4个并行TCP流，突破单流带宽限制（如TCP窗口×RTT）；-i 1：每秒输出一次实时速率，便于观察波动。
关键指标：若单流速率<900Mbps（千兆网卡理论值），需检查：
ethtool eth0 | grep "Speed"确认链路速率为1000Mb/s；ss -i | grep :3389查看TCP窗口大小（wscale:7表示窗口缩放因子7，理论窗口=64KB×128=8MB）；cat /proc/sys/net/ipv4/tcp_rmem确认接收窗口最小值≥256KB。
UDP丢包测试（验证实时性）
# 客户端以1Gbps速率发送UDP包（强制丢包率计算） iperf3 -c 192.168.1.100 -u -b 1G -t 60 -i 1-u：启用UDP模式；-b 1G：目标带宽1Gbps，iperf3会动态调整发包速率。
解读输出：
[ ID] Interval Transfer Bitrate Total Datagrams [ 4] 0.00-1.00 sec 1.25 MBytes 10.5 Mbits/sec 1600 [ 4] 1.00-2.00 sec 1.25 MBytes 10.5 Mbits/sec 1600 ... [ 4] 59.00-60.00 sec 1.25 MBytes 10.5 Mbits/sec 1600 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 4] 0.00-60.00 sec 125 MBytes 17.5 Mbits/sec 0.124 ms 0/160000 (0%)Jitter 0.124 ms：抖动极低，适合VoIP；Lost/Total 0/160000：0丢包，网络稳定。
注意：UDP测试中若丢包率>0.1%，需检查网卡中断合并（
ethtool -c eth0 rx-usecs 50）或启用RSS（Receive Side Scaling）分散CPU负载。
3.5 综合监控：vmstat/iostat/sar的黄金组合拳
压测不是“开两个终端一边跑一边看”，而是构建闭环监控链。我的标准操作是：
步骤1：预设sar历史采样
# 开启sar每秒采样CPU、内存、IO、网络 sar -u 1 3600 > /tmp/sar_cpu.log & # 1小时CPU sar -r 1 3600 > /tmp/sar_mem.log & # 1小时内存 sar -b 1 3600 > /tmp/sar_io.log & # 1小时IO sar -n DEV 1 3600 > /tmp/sar_net.log & # 1小时网络步骤2：压测中实时盯屏（tmux分屏）
- 左上：
vmstat 1（看r,b,wa,si/so） - 右上：
iostat -x 1（看await,svctm,%util,r/s,w/s） - 左下：
pidstat -u 1（看各进程CPU占用） - 右下：
iftop -P 3389（若测网络，看端口3389流量）
步骤3：压测后交叉分析例如，当iostat显示await=120ms且%util=98%，而vmstat中wa=45%，sar -r显示kbmemused稳定在12GB（无波动），则可100%断定瓶颈在磁盘IO，而非内存或CPU。
4. 常见问题与独家排查技巧实录
4.1 “fio测试IOPS很高，但业务却卡顿”——IO路径的七层陷阱
这是最典型的认知偏差。fio的高IOPS只证明“磁盘硬件快”，但业务卡顿往往死在IO路径的某个环节。我整理了七层排查清单，按出现频率排序：
| 层级 | 问题现象 | 快速验证命令 | 根本原因 | 解决方案 |
|---|---|---|---|---|
| 1. 文件系统层 | fio --filename=/mnt/ext4/test快，--filename=/mnt/xfs/test慢 | xfs_info /mnt/xfsvsdumpe2fs -h /dev/sdb1 | XFS未启用allocsize=64k，ext4未调优stride=128 | mkfs.xfs -l size=128m -d agcount=32 /dev/sdb |
| 2. 块设备层 | iostat中svctm正常（<5ms），但await飙升 | cat /sys/block/nvme0n1/queue/scheduler | 默认mq-deadline调度器在高并发下不如none（NOOP） | echo none > /sys/block/nvme0n1/queue/scheduler |
| 3. 驱动层 | dmesg报nvme 0000:01:00.0: controller is down | lspci -vv -s 01:00.0 | grep -A10 "Kernel driver" | NVMe驱动版本过旧，不支持PCIe 4.0功耗管理 | 升级内核至5.15+，或加内核参数nvme_core.default_ps_max_latency_us=0 |
| 4. 存储栈层 | iotop显示jbd2/sdb-8进程占CPU 90% | ps aux | grep jbd2 | ext4日志（journal）写入成为瓶颈 | mount -o remount,data=writeback /mnt/ext4（慎用，牺牲一致性） |
| 5. 内存层 | vmstat中pgpgin/pgpgout极高，si/so=0 | `cat /proc/meminfo | grep -E "PageIn | PageOut"` | 页面回收频繁，但未触发swap（因swappiness=1） |
| 6. 应用层 | strace -p <pid> -e trace=io_submit,io_getevents | strace -p 12345 -e trace=io_submit,io_getevents | 应用未正确使用异步IO，io_submit后立即io_getevents阻塞 | 改用io_uring接口，或增加libaio的io_context数量 |
| 7. 硬件层 | smartctl -a /dev/nvme0n1 | grep "Percentage Used" | smartctl -a /dev/nvme0n1 | grep "Percentage Used" | SSD磨损均衡耗尽，Percentage Used=100% | 更换SSD，启用fstrim定期TRIM |
实操心得：某次排查数据库慢查询，
fio随机读IOPS达15000，但pt-query-digest显示SELECT平均耗时2s。最终用perf record -e block:block_rq_issue,block:block_rq_complete -a sleep 30抓取块层事件，发现block_rq_complete延迟峰值达800ms，而block_rq_issue仅2ms，证实是NVMe控制器固件bug，升级固件后解决。
4.2 “sar历史数据为空”——sysstat服务的三个隐藏开关
sar数据为空是新手最高频问题，根源不在安装，而在三个服务开关：
sysstat服务未启用
systemctl status sysstat # 若显示inactive，执行 systemctl enable sysstat && systemctl start sysstat/etc/default/sysstat中ENABLED被设为false
# Ubuntu/Debian路径，CentOS为/etc/sysconfig/sysstat sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat systemctl restart sysstatcron任务被禁用
sysstat依赖/etc/cron.d/sysstat每10分钟执行/usr/lib/sysstat/sa1采集数据。检查：ls -l /etc/cron.d/sysstat # 确保存在且权限644 cat /etc/cron.d/sysstat # 应含：*/10 * * * * root /usr/lib/sysstat/sa1 1 1
提示：
sa1脚本会调用sadc（system activity data collector），其配置在/etc/sysstat/sysstat中。若需提高采样精度，可修改HISTORY=28（保留28天数据）和COMPRESSAFTER=7（7天后压缩）。
4.3 “vmstat中wa值高，但iostat显示%util很低”——IO等待的真相
这是最迷惑人的现象，表面矛盾实则揭示了IO的本质：wa（CPU等待IO时间）高，说明CPU在空转等IO完成；%util（设备利用率）低，说明磁盘本身没忙。唯一解释是——IO请求根本没发到磁盘，卡在了中间层。
典型场景与排查：
场景1：RAID卡电池未就绪
iostat -x中await极高（>1000ms），svctm也高，%util低。检查：megacli -AdpBbuCmd -GetBbuStatus -aALL \| grep "Battery State"
若为Battery State: Not Ready，则RAID写缓存被禁用，所有写请求直通磁盘，性能暴跌。场景2：LVM缓存层失效
使用lvconvert --type cache创建的LVM缓存，若缓存设备故障，iostat会显示底层磁盘%util低，但await飙升。检查：lvs -o +cache_used_block_size,cache_total_block_size
若cache_used_block_size=0，说明缓存已失效。场景3：内核IO调度器饥饿
mq-deadline调度器在极端负载下，可能因fifo_batch参数过小，导致某些IO请求长期得不到服务。检查：cat /sys/block/nvme0n1/queue/iosched/fifo_batch（默认16）临时修复：echo 64 > /sys/block/nvme0n1/queue/iosched/fifo_batch
4.4 压测后系统变慢——那些被忽略的“压测后遗症”
压测不是按下Ctrl+C就结束，很多性能问题源于压测残留：
问题1：内存碎片化
fio或sysbench memory大量分配/释放内存后，cat /proc/buddyinfo显示order=9（4MB块）为0，order=0（4KB）充足，但大块内存无法拼凑。解决：echo 1 > /proc/sys/vm/compact_memory（触发内存规整）问题2：页缓存污染
fio顺序写测试后，free -h显示buff/cache高达20GB，挤占应用内存。解决：sync && echo 3 > /proc/sys/vm/drop_caches（清空page cache、dentries、inodes）问题3：网络连接状态堆积
iperf3TCP测试后，netstat -s \| grep "segments retransmited"持续增长，说明TIME_WAIT连接未及时回收。解决：调整内核参数echo 'net.ipv4.tcp_fin_timeout = 30' >> /etc/sysctl.conf echo 'net.ipv4.tcp_tw_reuse = 1' >> /etc/sysctl.conf sysctl -p
我的压测checklist最后一步永远是：
reboot。不是因为必须，而是因为重启能100%清除所有压测状态，确保下次测试基线干净。某次为省事跳过重启，结果第二天业务高峰时，vmstat中r值莫名比平时高2，排查两小时才发现是fio测试残留的io_context未释放。
5. 监控工具的进阶用法与避坑指南
5.1 vmstat的隐藏字段：从“看热闹”到“看门道”
vmstat默认输出的15个字段中，90%的人只看前5个（procs、memory、swap、io、system、cpu）。但真正定位问题的，是后面几个冷门字段：
cs（context switch）：上下文切换次数/秒。若cs > 100000且r > CPU核心数，说明进程调度过于频繁，可能是过多短生命周期进程（如PHP-FPM的pm.max_children设得过大）；in（interrupts）：每秒中断次数。若in > 50000且%sy > 40%，需检查网卡中断是否集中在一个CPU核心（cat /proc/interrupts \| grep eth0），应启用smp_affinity绑定；fr（pages freed）：每秒释放的页数。若fr持续>1000，而sr（scanned）为0，说明kswapd内核线程未启动，内存回收由直接回收（direct reclaim）承担，延迟极高；cy（stolen time）：仅在虚拟机中有效，表示CPU时间被宿主机偷走。若cy > 5%，说明宿主机CPU过载，需向云厂商申请提升vCPU配额。
实操技巧：用vmstat -w 1（wide mode）可显示所有字段，但更高效的是自定义输出：
# 只关注关键字段：运行队列、IO等待、上下文切换、中断、用户/系统CPU vmstat 1 | awk 'NR==3 {printf "%s %s %s %s %s %s\n", $1,$2,$15,$16,$17,$18}'5.2 iostat的-x参数：读懂磁盘的“心电图”
iostat -x输出的扩展字段，是诊断IO问题的金钥匙：
r_await/w_await：读/写请求平均等待时间（含队列等待+服务时间）。若r_await > 10ms，而w_await < 1ms，说明读密集型应用（如Web Server）遇到瓶颈；rareq-sz/wareq-sz：平均读/写请求大小（KB）。若rareq-sz=4.00且w_await=0.20，说明是纯4KB随机读；若rareq-sz=128.00，则是128KB顺序读；svctm：平均服务时间（磁盘实际处理时间）。此值应稳定，若忽高忽低（如从0.5ms跳到50ms），说明磁盘固件异常或物理损坏；aqu-sz：平均请求队列长度。aqu-sz = await × IOPS / 1000，若aqu-sz > 10且%util=100%，说明队列已饱和。
避坑指南：iostat默认以“设备名”（如nvme0n1）为单位，但同一NVMe盘可能有多个命名空间（nvme0n1p1,nvme0n1p2）。务必用lsblk确认测试分区对应的实际设备名，否则监控对象错误。
5.3 sar的“时间机器”：如何用历史数据定位幽灵故障
sar最强大的功能是回溯。某次凌晨3点数据库慢，但当时无人值守。我用以下命令还原现场
