Linux 性能优化实战定位问题一步步排查 CPU / 内存 / 磁盘 / 网络作为刚接触 Linux 运维和系统编程的本科生我第一次被派去排查服务器变慢时是手足无措的——不知道先看什么、用什么命令、看出来的数字什么意思。这篇博客把我踩坑后整理出来的排查思路和常用工具讲清楚遇到性能问题先做什么、再看什么、最后怎么定位。这篇博客你能收获什么建立先测量、再优化的正确思路不再凭感觉瞎猜掌握一套通用的性能排查方法论USE 方法 60 秒检查法会用uptime/top/vmstat/mpstat/iostat/free/ss/sar等核心命令看懂 CPU、内存、磁盘、网络四大类指标分别代表什么问题走完一个完整的服务器变慢排查实战案例适用人群会用 Linux 基本命令ls/cd/ps但没做过性能排查的同学课程设计、社团服务器、个人云服务器出了问题不知道怎么查的同学准备面试被问系统卡了怎么排查的同学准备一台 Linux 环境本机装个 Linux 虚拟机或者买/租一台便宜的云服务器都行下面大部分命令自带mpstat/iostat/sar属于sysstat包需单独安装# Debian / Ubuntusudoaptinstallsysstat# CentOS / RHELsudoyuminstallsysstat1. 先改变思路性能优化 先测量再优化最容易踩的坑是一上来就优化。比如听说改某个内核参数能提速就立刻改结果系统更不稳定了。性能优化的正确姿势永远是先回答三个问题1. 系统真的慢吗 2. 慢在哪 3. 怎么改翻译成一句话没有数据就没有优化。盲目的优化只是撞大运。所以本文的路线是先教你怎么看数据工具再教你怎么读数据指标含义最后给你一套排查流程实战。2. 一套通用的方法论USE 方法 60 秒检查法2.1 USE 方法三个字母走天下这是性能领域大佬 Brendan Gregg著有《性能之巅》提出的方法专门用来回答系统哪里是瓶颈。对系统里的每一种资源CPU、内存、磁盘、网络都问三个问题字母含义通俗解释怎么判断出问题Utilization利用率资源有多忙CPU 忙到 100%Saturation饱和度忙不过来了活儿在排队运行队列排长队、内存开始交换Errors错误有没有出错磁盘报错、网卡丢包一句话记忆先看资源忙不忙再看是不是忙到排队最后看有没有报错。排队的Saturation通常比忙碌Utilization更能说明瓶颈。2.2 60 秒检查法先拍快照再下结论Netflix 性能团队推荐了一个60 秒快速体检流程——登录服务器后用一组基础命令快速掌握全局再决定往哪个方向深挖。第 1 步看整体 → uptime、top 第 2 步分资源看 → vmstatCPU/内存、iostat磁盘、free内存、ss/sar网络 第 3 步锁定进程 → pidstat、ps 第 4 步深入根因 → 分析业务代码、系统日志核心原则从宏观到微观从现象到本质。千万别一上来就strace、翻日志——先搞清楚哪条线先失控范围才会越来越窄。3. 第一课看整体——uptime 和 top3.1 uptime系统负载的体温计uptime输出示例15:30:10 up52days,3:14,2users, load average:1.20,0.85,0.62重点是最后的load average它代表1 分钟、5 分钟、15 分钟的平均负载。负载 正在运行 正在等待 CPU 的进程数近似单核 CPU负载 1.0 ≈ 满载负载长期超过 1.0说明 CPU 忙不过来了多核机器按核数折算4 核 CPU负载到 4.0 才等于满载速查现象含义1 分钟负载 5/15 分钟负载负载正在上升刚发生或正在发生问题15 分钟负载 核数系统持续过载不是瞬时抖动负载高但 CPU 使用率不高可能卡在磁盘 I/O 或锁等待见第 6 节3.2 top实时全局仪表盘top这是最有用的入门命令按1可以展开每个 CPU 核心。重点看前五行top - 15:31:02 up 52 days, 2 users, load average: 1.20, 0.85, 0.62 %Cpu(s): 12.5 us, 3.2 sy, 0.0 ni, 82.6 id, 1.5 wa, 0.0 hi, 0.2 si, 0.0 st MiB Mem : 15872.0 total, 2048.0 free, 8192.0 used, 5632.0 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used%Cpu(s) 各列的含义必记字段含义信号us用户态 CPU 使用率应用自己在干活正常的主要消耗sy系统态 CPU 使用率内核在干活系统调用、中断等过高需警惕id空闲率越大越空闲wa等待 I/O 的时间很高 → 磁盘或网络是瓶颈这是关键信号st被虚拟化偷走的时间云服务器被其他租户抢占可联系云厂商Mem 行重点看used和availablefree 命令里而不是free——因为buff/cache是内核缓存可以随时回收不是被占用了。记住wa高问题在磁盘us高问题在你的程序sy高问题在内核或系统调用。4. CPU 排查vmstat / mpstat / pidstat当怀疑 CPU 有问题时用下面三个命令由粗到细。4.1 vmstat一屏看全局vmstat1每秒刷新一次按CtrlC退出。输出示例procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 102400 204800 524288 0 0 12 15 800 1000 30 20 40 10 0重点看这几列列含义判断r正在运行/等待 CPU 的进程数运行队列长期大于 CPU 核数→ CPU 饱和b阻塞在 I/O 上的进程数持续大于 0 → 磁盘 I/O 有问题us/sy用户态 / 系统态 CPU同 topwa等待 I/O 的 CPU持续偏高 → 磁盘瓶颈si/so从磁盘换入 / 换出内存长期不为 0 → 内存不足见第 5 节4.2 mpstat看是不是单个核爆了mpstat-PALL1如果一个多核服务器整体负载不高但某个核%usr接近 100%说明单个核心成了热点常见于单线程应用。这样就能避免被整体看起来正常骗过去。4.3 pidstat锁定具体进程pidstat1输出每个进程的 CPU 占用配合top里的高占用 PID可以精准定位是谁在吃 CPU。pidstat-pPID1# 只看某个进程pidstat-t1# 按线程看排查多线程应用CPU 排查小结vmstat看整体 →mpstat看核心 →pidstat定位进程。us高先怀疑应用sy高怀疑系统调用wa高直接跳到磁盘排查。5. 内存排查free / vmstat5.1 free看内存到底够不够free-h输出示例total used free shared buff/cache available Mem: 15Gi 8.0Gi 2.0Gi 300Mi 5.5Gi 7.3Gi Swap: 2.0Gi 0.0Gi 2.0Gi新手最容易误解的一点used高 ≠ 内存不够。buff/cache是 Linux 拿空闲内存做的磁盘缓存是为了加速读取随时可以被回收给程序用判断内存是否紧张看available真正可用的内存而不是free只有available接近 0同时开始大量使用Swap才是真的内存不足5.2 vmstat 的 si/so内存告急的信号回到vmstat 1siswap in从磁盘换入内存soswap out从内存换出到磁盘如果si/so持续不为 0说明内存真的不够了系统正在频繁倒腾数据到磁盘这是很伤性能的。此时思路应该是加内存、或排查哪个进程内存泄漏。# 顺便看看哪些进程吃内存最多top-o%MEM# 按内存占用排序psaux--sort-%mem|head6. 磁盘 I/O 排查iostat / iotop / df当top里的wa很高时问题基本就在磁盘。6.1 iostat磁盘有多忙iostat-xz1输出示例每设备一行Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util sda 20.0 30.0 1024.0 2048.0 0.0 0.0 0.0 0.0 12.0 15.0 0.50 51.2 68.2 8.00 40.0新手看两个指标指标含义信号%util设备忙的时间占比接近100%→ 磁盘快成瓶颈await平均 I/O 等待时间毫秒明显变大 → 磁盘响应慢注意SSD / 云盘瞬时能力很强%util100% 不一定代表慢要结合await一起看。6.2 iotop谁在疯狂读写sudoiotop实时显示每个进程的磁盘读写速度用来锁定是哪个进程在狂写磁盘比如日志刷太频繁、数据库没开缓冲。6.3 df / du磁盘是不是满了df-h# 看各分区使用率满了会引发各种诡异问题du-sh/var/log/*|sort-rh|head# 找大文件优先查日志磁盘满会导致程序无法写日志、数据库无法落盘表现经常是莫名卡死。排查性能问题前先确认磁盘没满。7. 网络排查ss / sar / ping7.1 ss连接状态一览ss-antp替代老旧的netstat列出所有 TCP 连接及其状态。重点看异常状态状态含义风险SYN_RECV连接请求堆积可能被攻击SYN Flood或服务处理不过来TIME-WAIT连接关闭等待过多会占满端口需调优ESTAB异常多活跃连接过多可能连接泄漏ss-s# 统计摘要一眼看各状态数量7.2 sar看网卡流量和丢包sar-nDEV1# 每秒看网卡收发流量sar-nEDEV1# 看网卡错误和丢包errors / drops如果rxkB/s/txkB/s接近网卡带宽上限就是带宽打满出现大量drop说明网卡或内核队列处理不过来。7.3 延迟排查ping-c4目标IP# 看基础延迟和丢包ping-c4-s1400目标IP# 用大包测排查 MTU 问题8. 实战案例服务器突然变慢怎么办把前面所有知识串成一个完整流程。场景你管理的服务器最近响应很慢用户开始抱怨。第 1 步拍快照看整体60 秒内uptimetop发现load average: 8.50, 6.20, 3.10 # 负载持续上升且远超核数 %Cpu(s): 5.0 us, 2.0 sy, 0.0 ni, 10.0 id, 82.0 wa, ...关键信号wa高达 82%说明 CPU 大量时间在等磁盘 I/O——瓶颈很可能在磁盘而不是 CPU。第 2 步确认瓶颈类型iostat-xz1vmstat1看到某块盘%util长期 100%、await飙升同时vmstat的b阻塞进程持续不为 0。实锤磁盘 I/O 瓶颈。第 3 步锁定元凶进程iotop# 看谁在狂读写pidstat-d1# 按进程看磁盘读写发现某个应用在疯狂写日志或者数据库在频繁刷盘。第 4 步分析根因并解决常见根因与对策根因对策日志刷太频繁 / 日志过大调日志级别、加日志轮转logrotate数据库未合理用缓冲 / 慢查询多优化 SQL、加大 buffer、加索引单盘性能不足换 SSD、加缓存层、多盘负载均衡代码反复读写大文件优化代码减少不必要的 I/O第 5 步验证uptimetop# 再看负载是否回落、wa 是否下降优化完一定要回到同一批命令复测用数据确认问题解决了而不是感觉好多了。9. 常见优化手段先确认瓶颈再动手再次强调先定位瓶颈再优化。在不知道瓶颈在哪的情况下调参等于蒙眼修车。9.1 几个常见的内核参数改前先备份、先小范围试验参数作用何时考虑调vm.swappiness控制系统多愿意用 Swap内存充足但频繁换页时可从默认值调低如 10fs.file-max/ulimit -n文件描述符上限服务报 “too many open files” 时TCP 相关net.ipv4.tcp_tw_reuse等加速 TIME-WAIT 连接回收ss -s显示 TIME-WAIT 过多时# 临时修改重启失效sudosysctlvm.swappiness10# 永久修改写入 /etc/sysctl.conf 后执行sudosysctl-p9.2 更重要的优化其实是这些代码层面减少无效 I/O、避免不必要的锁、用缓存架构层面加缓存Redis、读写分离、水平扩容资源层面升级配置、换 SSD、加内存对入门阶段来说先学会测量把慢的原因找对比急着调参数重要得多。10. 进阶方向下次想看更深的入门掌握上面这些工具后如果还想深入可以了解这几个方向本篇不展开perfLinux 自带的性能剖析工具可以看 CPU 时间都花在哪个函数上perf top、perf record/report火焰图Flame Graph把 CPU 栈采样可视化一眼看出热点函数eBPF / bpftrace现代内核观测技术可以在不修改程序的情况下动态追踪内核 4.4 支持strace追踪进程的系统调用排查程序卡在哪个系统调用上11. 总结一张图 一套命令性能问题 │ ▼ 第 1 步 看整体 ──► uptime(负载) / top(wa、us、Mem) │ ▼ 第 2 步 分资源 ──► CPU: vmstat / mpstat / pidstat │ 内存: free -h / vmstat(si/so) │ 磁盘: iostat / iotop / df │ 网络: ss / sar / ping │ ▼ 第 3 步 锁进程 ──► pidstat / iotop / top 排序 │ ▼ 第 4 步 找根因 ──► 日志 / 业务代码 / 配置 │ ▼ 第 5 步 优化验证 ─► 改完用同一批命令复测三句话记住本文核心先测量再优化——没有数据就没有优化别凭感觉乱调参数。看指标有规律——wa高看磁盘、us高看应用、si/so高看内存、drop高看网络。排查有套路——先整体后局部先定位瓶颈再动手改完必须复测验证。性能优化不是玄学而是一套测量 → 定位 → 优化 → 验证的可重复流程。把上面的工具用熟你已经能解决大多数服务器变慢的问题了。如果这篇博客对你有帮助欢迎点赞收藏也欢迎在评论区聊聊你遇到过最诡异的性能问题参考资料Brendan Gregg《性能之巅》及 USE 方法 — https://www.brendangregg.com/usemethod.htmlNetflixLinux Performance Analysis in 60,000 Milliseconds — https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55常用工具官方文档man uptime/man top/man vmstat/man iostat/man free/man ss/man sar Linux 性能优化入门
Linux 性能优化实战定位问题一步步排查 CPU / 内存 / 磁盘 / 网络作为刚接触 Linux 运维和系统编程的本科生我第一次被派去排查服务器变慢时是手足无措的——不知道先看什么、用什么命令、看出来的数字什么意思。这篇博客把我踩坑后整理出来的排查思路和常用工具讲清楚遇到性能问题先做什么、再看什么、最后怎么定位。这篇博客你能收获什么建立先测量、再优化的正确思路不再凭感觉瞎猜掌握一套通用的性能排查方法论USE 方法 60 秒检查法会用uptime/top/vmstat/mpstat/iostat/free/ss/sar等核心命令看懂 CPU、内存、磁盘、网络四大类指标分别代表什么问题走完一个完整的服务器变慢排查实战案例适用人群会用 Linux 基本命令ls/cd/ps但没做过性能排查的同学课程设计、社团服务器、个人云服务器出了问题不知道怎么查的同学准备面试被问系统卡了怎么排查的同学准备一台 Linux 环境本机装个 Linux 虚拟机或者买/租一台便宜的云服务器都行下面大部分命令自带mpstat/iostat/sar属于sysstat包需单独安装# Debian / Ubuntusudoaptinstallsysstat# CentOS / RHELsudoyuminstallsysstat1. 先改变思路性能优化 先测量再优化最容易踩的坑是一上来就优化。比如听说改某个内核参数能提速就立刻改结果系统更不稳定了。性能优化的正确姿势永远是先回答三个问题1. 系统真的慢吗 2. 慢在哪 3. 怎么改翻译成一句话没有数据就没有优化。盲目的优化只是撞大运。所以本文的路线是先教你怎么看数据工具再教你怎么读数据指标含义最后给你一套排查流程实战。2. 一套通用的方法论USE 方法 60 秒检查法2.1 USE 方法三个字母走天下这是性能领域大佬 Brendan Gregg著有《性能之巅》提出的方法专门用来回答系统哪里是瓶颈。对系统里的每一种资源CPU、内存、磁盘、网络都问三个问题字母含义通俗解释怎么判断出问题Utilization利用率资源有多忙CPU 忙到 100%Saturation饱和度忙不过来了活儿在排队运行队列排长队、内存开始交换Errors错误有没有出错磁盘报错、网卡丢包一句话记忆先看资源忙不忙再看是不是忙到排队最后看有没有报错。排队的Saturation通常比忙碌Utilization更能说明瓶颈。2.2 60 秒检查法先拍快照再下结论Netflix 性能团队推荐了一个60 秒快速体检流程——登录服务器后用一组基础命令快速掌握全局再决定往哪个方向深挖。第 1 步看整体 → uptime、top 第 2 步分资源看 → vmstatCPU/内存、iostat磁盘、free内存、ss/sar网络 第 3 步锁定进程 → pidstat、ps 第 4 步深入根因 → 分析业务代码、系统日志核心原则从宏观到微观从现象到本质。千万别一上来就strace、翻日志——先搞清楚哪条线先失控范围才会越来越窄。3. 第一课看整体——uptime 和 top3.1 uptime系统负载的体温计uptime输出示例15:30:10 up52days,3:14,2users, load average:1.20,0.85,0.62重点是最后的load average它代表1 分钟、5 分钟、15 分钟的平均负载。负载 正在运行 正在等待 CPU 的进程数近似单核 CPU负载 1.0 ≈ 满载负载长期超过 1.0说明 CPU 忙不过来了多核机器按核数折算4 核 CPU负载到 4.0 才等于满载速查现象含义1 分钟负载 5/15 分钟负载负载正在上升刚发生或正在发生问题15 分钟负载 核数系统持续过载不是瞬时抖动负载高但 CPU 使用率不高可能卡在磁盘 I/O 或锁等待见第 6 节3.2 top实时全局仪表盘top这是最有用的入门命令按1可以展开每个 CPU 核心。重点看前五行top - 15:31:02 up 52 days, 2 users, load average: 1.20, 0.85, 0.62 %Cpu(s): 12.5 us, 3.2 sy, 0.0 ni, 82.6 id, 1.5 wa, 0.0 hi, 0.2 si, 0.0 st MiB Mem : 15872.0 total, 2048.0 free, 8192.0 used, 5632.0 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used%Cpu(s) 各列的含义必记字段含义信号us用户态 CPU 使用率应用自己在干活正常的主要消耗sy系统态 CPU 使用率内核在干活系统调用、中断等过高需警惕id空闲率越大越空闲wa等待 I/O 的时间很高 → 磁盘或网络是瓶颈这是关键信号st被虚拟化偷走的时间云服务器被其他租户抢占可联系云厂商Mem 行重点看used和availablefree 命令里而不是free——因为buff/cache是内核缓存可以随时回收不是被占用了。记住wa高问题在磁盘us高问题在你的程序sy高问题在内核或系统调用。4. CPU 排查vmstat / mpstat / pidstat当怀疑 CPU 有问题时用下面三个命令由粗到细。4.1 vmstat一屏看全局vmstat1每秒刷新一次按CtrlC退出。输出示例procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 102400 204800 524288 0 0 12 15 800 1000 30 20 40 10 0重点看这几列列含义判断r正在运行/等待 CPU 的进程数运行队列长期大于 CPU 核数→ CPU 饱和b阻塞在 I/O 上的进程数持续大于 0 → 磁盘 I/O 有问题us/sy用户态 / 系统态 CPU同 topwa等待 I/O 的 CPU持续偏高 → 磁盘瓶颈si/so从磁盘换入 / 换出内存长期不为 0 → 内存不足见第 5 节4.2 mpstat看是不是单个核爆了mpstat-PALL1如果一个多核服务器整体负载不高但某个核%usr接近 100%说明单个核心成了热点常见于单线程应用。这样就能避免被整体看起来正常骗过去。4.3 pidstat锁定具体进程pidstat1输出每个进程的 CPU 占用配合top里的高占用 PID可以精准定位是谁在吃 CPU。pidstat-pPID1# 只看某个进程pidstat-t1# 按线程看排查多线程应用CPU 排查小结vmstat看整体 →mpstat看核心 →pidstat定位进程。us高先怀疑应用sy高怀疑系统调用wa高直接跳到磁盘排查。5. 内存排查free / vmstat5.1 free看内存到底够不够free-h输出示例total used free shared buff/cache available Mem: 15Gi 8.0Gi 2.0Gi 300Mi 5.5Gi 7.3Gi Swap: 2.0Gi 0.0Gi 2.0Gi新手最容易误解的一点used高 ≠ 内存不够。buff/cache是 Linux 拿空闲内存做的磁盘缓存是为了加速读取随时可以被回收给程序用判断内存是否紧张看available真正可用的内存而不是free只有available接近 0同时开始大量使用Swap才是真的内存不足5.2 vmstat 的 si/so内存告急的信号回到vmstat 1siswap in从磁盘换入内存soswap out从内存换出到磁盘如果si/so持续不为 0说明内存真的不够了系统正在频繁倒腾数据到磁盘这是很伤性能的。此时思路应该是加内存、或排查哪个进程内存泄漏。# 顺便看看哪些进程吃内存最多top-o%MEM# 按内存占用排序psaux--sort-%mem|head6. 磁盘 I/O 排查iostat / iotop / df当top里的wa很高时问题基本就在磁盘。6.1 iostat磁盘有多忙iostat-xz1输出示例每设备一行Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util sda 20.0 30.0 1024.0 2048.0 0.0 0.0 0.0 0.0 12.0 15.0 0.50 51.2 68.2 8.00 40.0新手看两个指标指标含义信号%util设备忙的时间占比接近100%→ 磁盘快成瓶颈await平均 I/O 等待时间毫秒明显变大 → 磁盘响应慢注意SSD / 云盘瞬时能力很强%util100% 不一定代表慢要结合await一起看。6.2 iotop谁在疯狂读写sudoiotop实时显示每个进程的磁盘读写速度用来锁定是哪个进程在狂写磁盘比如日志刷太频繁、数据库没开缓冲。6.3 df / du磁盘是不是满了df-h# 看各分区使用率满了会引发各种诡异问题du-sh/var/log/*|sort-rh|head# 找大文件优先查日志磁盘满会导致程序无法写日志、数据库无法落盘表现经常是莫名卡死。排查性能问题前先确认磁盘没满。7. 网络排查ss / sar / ping7.1 ss连接状态一览ss-antp替代老旧的netstat列出所有 TCP 连接及其状态。重点看异常状态状态含义风险SYN_RECV连接请求堆积可能被攻击SYN Flood或服务处理不过来TIME-WAIT连接关闭等待过多会占满端口需调优ESTAB异常多活跃连接过多可能连接泄漏ss-s# 统计摘要一眼看各状态数量7.2 sar看网卡流量和丢包sar-nDEV1# 每秒看网卡收发流量sar-nEDEV1# 看网卡错误和丢包errors / drops如果rxkB/s/txkB/s接近网卡带宽上限就是带宽打满出现大量drop说明网卡或内核队列处理不过来。7.3 延迟排查ping-c4目标IP# 看基础延迟和丢包ping-c4-s1400目标IP# 用大包测排查 MTU 问题8. 实战案例服务器突然变慢怎么办把前面所有知识串成一个完整流程。场景你管理的服务器最近响应很慢用户开始抱怨。第 1 步拍快照看整体60 秒内uptimetop发现load average: 8.50, 6.20, 3.10 # 负载持续上升且远超核数 %Cpu(s): 5.0 us, 2.0 sy, 0.0 ni, 10.0 id, 82.0 wa, ...关键信号wa高达 82%说明 CPU 大量时间在等磁盘 I/O——瓶颈很可能在磁盘而不是 CPU。第 2 步确认瓶颈类型iostat-xz1vmstat1看到某块盘%util长期 100%、await飙升同时vmstat的b阻塞进程持续不为 0。实锤磁盘 I/O 瓶颈。第 3 步锁定元凶进程iotop# 看谁在狂读写pidstat-d1# 按进程看磁盘读写发现某个应用在疯狂写日志或者数据库在频繁刷盘。第 4 步分析根因并解决常见根因与对策根因对策日志刷太频繁 / 日志过大调日志级别、加日志轮转logrotate数据库未合理用缓冲 / 慢查询多优化 SQL、加大 buffer、加索引单盘性能不足换 SSD、加缓存层、多盘负载均衡代码反复读写大文件优化代码减少不必要的 I/O第 5 步验证uptimetop# 再看负载是否回落、wa 是否下降优化完一定要回到同一批命令复测用数据确认问题解决了而不是感觉好多了。9. 常见优化手段先确认瓶颈再动手再次强调先定位瓶颈再优化。在不知道瓶颈在哪的情况下调参等于蒙眼修车。9.1 几个常见的内核参数改前先备份、先小范围试验参数作用何时考虑调vm.swappiness控制系统多愿意用 Swap内存充足但频繁换页时可从默认值调低如 10fs.file-max/ulimit -n文件描述符上限服务报 “too many open files” 时TCP 相关net.ipv4.tcp_tw_reuse等加速 TIME-WAIT 连接回收ss -s显示 TIME-WAIT 过多时# 临时修改重启失效sudosysctlvm.swappiness10# 永久修改写入 /etc/sysctl.conf 后执行sudosysctl-p9.2 更重要的优化其实是这些代码层面减少无效 I/O、避免不必要的锁、用缓存架构层面加缓存Redis、读写分离、水平扩容资源层面升级配置、换 SSD、加内存对入门阶段来说先学会测量把慢的原因找对比急着调参数重要得多。10. 进阶方向下次想看更深的入门掌握上面这些工具后如果还想深入可以了解这几个方向本篇不展开perfLinux 自带的性能剖析工具可以看 CPU 时间都花在哪个函数上perf top、perf record/report火焰图Flame Graph把 CPU 栈采样可视化一眼看出热点函数eBPF / bpftrace现代内核观测技术可以在不修改程序的情况下动态追踪内核 4.4 支持strace追踪进程的系统调用排查程序卡在哪个系统调用上11. 总结一张图 一套命令性能问题 │ ▼ 第 1 步 看整体 ──► uptime(负载) / top(wa、us、Mem) │ ▼ 第 2 步 分资源 ──► CPU: vmstat / mpstat / pidstat │ 内存: free -h / vmstat(si/so) │ 磁盘: iostat / iotop / df │ 网络: ss / sar / ping │ ▼ 第 3 步 锁进程 ──► pidstat / iotop / top 排序 │ ▼ 第 4 步 找根因 ──► 日志 / 业务代码 / 配置 │ ▼ 第 5 步 优化验证 ─► 改完用同一批命令复测三句话记住本文核心先测量再优化——没有数据就没有优化别凭感觉乱调参数。看指标有规律——wa高看磁盘、us高看应用、si/so高看内存、drop高看网络。排查有套路——先整体后局部先定位瓶颈再动手改完必须复测验证。性能优化不是玄学而是一套测量 → 定位 → 优化 → 验证的可重复流程。把上面的工具用熟你已经能解决大多数服务器变慢的问题了。如果这篇博客对你有帮助欢迎点赞收藏也欢迎在评论区聊聊你遇到过最诡异的性能问题参考资料Brendan Gregg《性能之巅》及 USE 方法 — https://www.brendangregg.com/usemethod.htmlNetflixLinux Performance Analysis in 60,000 Milliseconds — https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55常用工具官方文档man uptime/man top/man vmstat/man iostat/man free/man ss/man sar