引言
Linux服务器性能问题是最让运维工程师头疼的故障之一。服务器响应缓慢、网站打开转圈、数据库查询超时，这些现象背后可能隐藏着CPU打满、内存泄漏、磁盘IO瓶颈、网络延迟等各种原因。不同于服务不可用这种"非黑即白"的故障，性能问题往往是渐进的、模糊的，需要运维工程师有系统的排查思路和丰富的经验积累。
本文面向初中级运维工程师和系统管理员，详细讲解Linux服务器性能问题的排查流程。文章不追求面面俱到的理论讲解，而是从实战出发，提供可以直接落地执行的操作步骤。内容包括CPU、内存、磁盘IO、网络四大基础资源的排查方法，进程级别性能分析工具的使用，以及常见性能瓶颈的识别和处理。
本文假设读者具备基本的Linux操作能力，能够熟练使用top、ps等基础命令。阅读本文后，读者应该能够：对性能问题建立系统化的排查思路、使用top、htop、vmstat、iostat、netstat等工具进行性能诊断、分析CPU、内存、磁盘、网络四大资源的瓶颈所在、定位到具体进程或服务并进行处理。
一、性能排查基础
1.1 性能问题的分类
Linux服务器性能问题可以分为四大类：CPU密集型、内存密集型、IO密集型、网络密集型。实际生产环境中，往往是多种问题混合存在，需要综合分析。
CPU密集型问题的特征是服务器负载高但IO等待低。典型场景包括：频繁的计算任务、加密解密、大量正则表达式处理、不当的循环结构等。这类问题的表现是CPU使用率接近100%，但磁盘和网络IO较低。
内存密集型问题的特征是可用内存持续下降，swap使用率上升。典型场景包括：内存泄漏、应用配置不当（jvm heap过大）、缓存数据过大等。表现是free命令显示可用内存很少，si/so（swap in/out）数值较高。
IO密集型问题的特征是磁盘读写量巨大，IO等待时间长。典型场景包括：频繁的日志写入、大数据量的数据库操作、不当的临时文件使用等。表现是iostat显示高util%，CPU的wa（wait）值高。
网络密集型问题的特征是网络带宽接近饱和或存在大量连接异常。典型场景包括：DDoS攻击、爬虫频繁访问、接口调用超时等。表现是网络流量接近带宽上限、大量连接处于TIME_WAIT状态。
1.2 排查的基本顺序
性能问题排查遵循"先整体后局部、先CPU后内存、IO网络配合看"的原则。
第一步，用top或uptime命令快速了解系统负载概况。系统负载（load average）如果超过CPU核心数，说明存在资源争抢。
第二步，用vmstat命令查看系统整体的CPU、内存、IO、swap状态。关注r（运行队列长度）、b（阻塞进程数）、wa（IO等待）、si/so（swap换入换出）等指标。
第三步，用iostat命令查看磁盘IO情况，确定是否存在IO瓶颈。
第四步，用free命令查看内存使用情况，确认是否存在内存不足。
第五步，用netstat或ss命令查看网络连接状态，确认是否存在网络问题。
第六步，确定瓶颈所在后，用top、ps等工具定位到具体进程，进行进一步分析。
1.3 系统负载与CPU核心数的关系
理解系统负载（load average）与CPU核心数的关系，是判断服务器是否"繁忙"的前提。
load average是Linux系统的重要指标，通过uptime命令或top命令的第一行可以看到：
uptime# 输出：16:45:12 up 45 days, 3:22, 2 users, load average: 2.85, 3.21, 4.10
load average的三个数字分别代表1分钟、5分钟、15分钟的平均负载。理想情况下，load average应该小于CPU核心数。如果load average长期高于CPU核心数，说明系统处于高负载状态，新任务需要等待才能执行。
假设服务器有8个CPU核心：
- load average为2.85，说明平均有2.85个任务在等待CPU资源，系统比较轻松
- load average为8，说明CPU资源刚好够用，没有等待
- load average为12，说明有4个任务在等待CPU资源，系统繁忙
可以通过以下命令查看CPU核心数：
nproc# 或者grep "processor" /proc/cpuinfo | wc -l
1.4 关键性能指标速览
vmstat命令是性能排查中最常用的工具之一，它能在一屏之内展示系统整体的CPU、内存、IO、swap等关键指标：
vmstat 2 5
参数2表示每隔2秒采样一次，共采样5次。输出示例：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 2048000 123456 789012 0 0 50 100 500 1000 10 5 80 5 0
各列含义：
正常状态参考：
- id应大于30%（如果持续低于30%说明CPU繁忙）
- wa应小于20%（如果高于20%说明IO存在瓶颈）
二、CPU性能排查
2.1 快速查看CPU状态
top命令是排查CPU问题的首选工具，它能够实时显示系统资源使用情况和进程列表：
top
top界面的第一行是系统负载信息，第二行是任务（进程）统计，第三行是CPU使用情况，第四五行是内存使用情况，下方是进程列表。
CPU区域的显示含义：
%Cpu(s): 25.0 us, 5.0 sy, 0.0 ni, 68.0 id, 2.0 wa, 0.0 hi, 0.0 si, 0.0 st
- ni（nice）：优先级调整过的用户进程消耗的CPU百分比
- hi（hardirq）：处理硬件中断消耗的CPU百分比
- si（softirq）：处理软中断消耗的CPU百分比
us高sy低：正常情况，说明用户进程在大量计算。
us高sy也高：需要检查系统调用或上下文切换是否过多。
wa高：说明进程在等待IO，可能是磁盘IO慢或网络IO慢。
hi/si高：说明存在大量中断或软中断，可能与网络或存储驱动有关。
2.2 定位CPU占用最高的进程
在top界面中，按Shift+M按内存排序，按Shift+P按CPU排序。按q退出。
查看CPU占用最高的进程：
ps aux --sort=-%cpu | head -20
这条命令会列出CPU占用前20的进程。输出示例：
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 12345 95.0 2.0 1234567 456789 ? R 10:00 950:00 myapproot 12346 3.2 1.0 234567 123456 ? S 10:00 120:00 javaroot 1 0.5 0.1 12345 6789 ? Ss Jan01 5:00 systemd
%CPU列是重点，如果某个进程的CPU占用持续接近或超过100%（单核心），说明该进程存在CPU密集型问题。
2.3 查看进程线程
对于Java、Go等支持多线程的语言，一个进程可能有多个线程。查看特定进程的线程：
# 查看进程的所有线程ps -eLf | grep <pid># 或使用top查看线程top -H -p <pid>
top的-H参数显示线程视图，-p参数指定进程ID。
2.4 分析CPU使用率高的常见原因
原因一：业务代码存在无限循环或密集计算。这是最常见的原因，需要检查业务代码逻辑。
排查方法：使用strace跟踪系统调用，确认进程在做什么：
strace -p <pid> -c
-c参数统计系统调用，按Ctrl+C结束。
原因二：GC（垃圾回收）频繁。对于Java应用，GC频繁会导致CPU飙高。
排查方法：查看GC日志，确认GC频率和耗时：
jstat -gc <pid> 1000 10
这条命令每1秒打印一次GC统计，共打印10次。
原因三：正则表达式回溯。大量使用正则表达式的应用，如果正则写的不当，可能导致灾难性回溯。
原因四：加密解密或压缩解压。这些操作本身就是CPU密集型的，需要确认是否有必要。
2.5 高CPU问题的处理步骤
确认是高CPU问题后，按以下步骤处理：
第一步，确认是哪个进程：
ps aux --sort=-%cpu | head -10
第二步，查看该进程的详细信息：
ps -ef | grep <pid>
第三步，查看进程打开的文件和网络连接：
lsof -p <pid>
第四步，如果是业务进程，查看应用日志：
# Java应用tail -f /var/log/myapp/application.log# Nginxtail -f /var/log/nginx/error.log
第五步，考虑处理措施：
- 如果是异常进程（如被入侵），立即kill：
kill -9 <pid>
2.6 系统层面的CPU优化
如果确认是系统层面需要优化，考虑以下方向：
调整进程优先级。使用nice和renice调整进程优先级：
# 启动时设置优先级nice -n 10 /path/to/application# 调整运行中的进程renice -n 10 -p <pid>
nice值范围是-20到19，值越低优先级越高。
绑定CPU核心。使用taskset将进程绑定到特定CPU核心，减少上下文切换：
# 绑定到CPU核心0-3taskset -c 0-3 -p <pid>
三、内存性能排查
3.1 快速查看内存状态
free命令是最常用的内存查看工具：
free -h
输出示例：
total used free shared buff/cache availableMem: 31Gi 28Gi 1.5Gi 200Mi 1.5Gi 2.5GiSwap: 8Gi 0B 8Gi
各列含义：
- available：实际可用内存（包括cache可回收部分）
重点关注available而不是free。Linux会使用空闲内存作为缓存来提高性能，这些缓存可以在需要时释放。所以看到free很低但available很高是正常现象。
3.2 内存使用的详细分析
查看内存使用的详细信息：
cat /proc/meminfo
输出中关键指标：
MemTotal: 32768000 kB # 总内存MemFree: 1500000 kB # 完全空闲MemAvailable: 2500000 kB # 可用内存Buffers: 123456 kB # 缓冲区Cached: 1500000 kB # 缓存SwapCached: 0 kB # 交换到磁盘的缓存Active(anon): 18000000 kB # 活跃匿名内存Inactive(anon): 2000000 kB # 不活跃匿名内存Active(file): 5000000 kB # 活跃文件内存Inactive(file): 3000000 kB # 不活跃文件内存SwapTotal: 8000000 kB # swap总大小SwapFree: 8000000 kB # swap空闲
SwapUsed不为0且持续增长，说明存在内存压力，物理内存不足。
3.3 查看进程内存占用
按内存使用排序查看进程：
ps aux --sort=-%mem | head -20
或者使用top按内存排序（按Shift+M）。
3.4 分析内存泄漏
内存泄漏的典型特征是：进程占用的内存持续增长，不下降，即使在负载降低后也不释放。
监控进程内存使用变化：
# 每5秒检查一次，共检查20次for i in {1..20}; do ps -o pid,rss,vsz,comm -p <pid> sleep 5done
或者使用pmap查看进程的内存映射：
pmap -x <pid> | sort -k3 -n -r | head -20
-x参数显示扩展格式，| sort按第3列（Kbytes）排序。
3.5 内存使用率高常见原因
原因一：应用内存泄漏。Java应用最常见，典型表现是堆内存持续增长直到OOM。
排查方法：分析堆内存dump或GC日志。Java应用可以查看JVM内存使用：
jstat -gc <pid>jmap -heap <pid>
原因二：缓存数据过大。Nginx、Redis等应用会使用大量内存作为缓存。
排查方法：检查应用配置，确认缓存大小限制。
原因三：JVM heap配置过大。如果JVM的heap配置超过了物理内存的一半，可能影响系统稳定性。
排查方法：检查JVM参数：
jcmd <pid> VM.flags
原因四：进程数过多。大量进程同时运行会消耗大量内存。
排查方法：检查进程数：
ps aux | wc -l
3.6 swap问题排查
swap使用率高（si/so持续不为0）是内存不足的明确信号。
查看swap使用情况：
swapon -sfree -hvmstat 2 5
如果发现swap使用率高，需要分析是物理内存真的不足，还是存在内存泄漏。
分析哪些进程在使用swap：
for f in $(ls /proc/*/status 2>/dev/null); do awk '/VmSwap/{print $2, $3, $4}'$f | whileread size unit name; doif [ "${size%"*}" -gt 0 ]; thenecho"$name$size$unit"fidonedone | sort -k2 -n -r | head -20
这个脚本会列出使用swap最多的前20个进程。
3.7 内存问题的处理步骤
第一步，确认是否真的内存不足：
free -hvmstat 2 5
如果available远大于used，说明内存充足，不需要处理。
第二步，确认是哪个进程占用内存最多：
ps aux --sort=-%mem | head -10
第三步，分析进程类型：
- 系统进程（kswapd、jbd2等）占用高，说明存在IO压力
第四步，处理措施：
四、磁盘IO排查
4.1 IO性能基础概念
磁盘IO问题是生产环境中常见的性能瓶颈。理解几个基本概念有助于后续排查：
IOPS（Input/Output Operations Per Second）：每秒IO操作数，衡量随机读写能力。
吞吐量（Throughput）：每秒数据传输量，衡量顺序读写能力，单位通常是MB/s或GB/s。
延迟（Latency）：单个IO操作的响应时间，单位通常是毫秒。
利用率（Utilization）：磁盘处理IO的时间占总时间的百分比，接近100%时说明磁盘饱和。
不同类型的存储设备性能差异巨大：
- HDD（机械硬盘）：IOPS通常几十到几百，延迟毫秒级
4.2 iostat命令详解
iostat是排查磁盘IO问题的核心工具，需要安装sysstat包：
yum install sysstat # CentOS/RHELapt-get install sysstat # Debian/Ubuntu
基本用法：
iostat -x 2 5
参数-x显示扩展统计信息，每2秒采样一次，共5次。
输出示例：
Linux 5.4.0-xxx (hostname) 05/13/2026 _x86_64_ (8 CPU)avg-cpu: %user %nice %system %iostat %idle 10.50 0.00 5.25 2.50 81.75Device: r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz %utilsda 10.00 100.00 5120.00 51200.00 0.00 5.00 0.00 4.76 10.00 5.00 2.50 55.00
关键指标：
- await：平均IO等待时间（毫秒），包含排队时间和实际处理时间
判断IO瓶颈的标准：
- await远高于正常值（HDD通常10-20ms，SSD<1ms）
4.3 查看具体进程的IO使用
iotop命令可以查看每个进程的IO使用情况，需要root权限：
yum install iotop # 安装iotop
iotop界面类似于top，按IO排序显示进程。
参数说明：
iotop -o # 只显示有IO活动的进程iotop -p <pid> # 只显示特定进程iotop -a # 累计显示IO量
如果iotop不可用，可以使用pidstat：
pidstat -d 2 5
4.4 查看IO等待
CPU的wa（wait）值高，说明进程在等待IO：
vmstat 2 5
结合iostat可以确认是哪个设备导致的IO等待。
4.5 分析IO模式
确认是IO问题后，需要分析是读多还是写多，是随机IO还是顺序IO。
查看每个磁盘的读写统计：
iostat -x 1 3
如果r/s高说明读多，w/s高说明写多。
查看具体文件系统的IO：
df -h
确认是哪个挂载点的问题。
4.6 常见IO问题原因
原因一：日志写入过多。应用程序产生大量日志写入。
排查方法：检查/var/log目录大小：
du -sh /var/log/*
原因二：数据库IO压力大。频繁的数据库读写操作。
排查方法：查看数据库的慢查询日志。
原因三：临时文件操作频繁。应用在/tmp目录频繁读写。
排查方法：使用lsof查看进程打开的文件。
原因四：swap操作。内存不足导致频繁换页。
排查方法：结合内存排查一起看。
4.7 IO问题的处理步骤
第一步，确认是否是IO问题：
iostat -x 2 5
关注%util和await指标。
第二步，如果是IO问题，确认是读还是写导致的：
iostat -x 1 3
看r/s和w/s哪个更高。
第三步，定位到具体进程：
iotop
第四步，分析是哪个文件或挂载点：
lsof -p <pid>
第五步，处理措施：
五、网络性能排查
5.1 快速查看网络状态
查看网络连接统计：
netstat -s
或者使用ss命令（更现代，性能更好）：
ss -s
查看活动连接：
ss -tan state established | head -20
5.2 网络带宽检查
查看网卡流量：
cat /proc/net/dev
或者使用iftop（需要安装）：
iftop -i eth0
监控特定端口的连接数：
netstat -an | grep :80 | wc -l
5.3 连接状态分析
分析TCP连接状态分布：
netstat -an | awk '/^tcp/{print $NF}' | sort | uniq -c
或使用ss命令：
ss -tan state established | wc -lss -tan state time-wait | wc -lss -tan state syn-recv | wc -l
常见的异常状态：
- 大量SYN_RECV：可能是SYN Flood攻击
- 大量ESTABLISHED但没有数据传输：可能是连接泄漏
5.4 网络延迟排查
测试到目标主机的延迟：
ping -c 10 <target>
测试DNS解析：
time nslookup example.com
测试TCP连接延迟：
telnet <host> <port>
5.5 网卡队列和中断
查看网卡中断分布：
cat /proc/interrupts | grep eth
查看网卡队列：
ethtool -l eth0
调整网卡队列数：
ethtool -L eth0 combined 8
5.6 网络问题的处理步骤
第一步，确认是否网络问题：
ping -c 5 8.8.8.8ping -c 5 <gateway>
如果内网通但外网不通，可能是NAT或路由问题。
第二步，分析连接状态：
ss -tan state syn-recv | wc -l
如果SYN_RECV状态连接很多，可能是SYN Flood攻击。
第三步，检查防火墙：
iptables -L -niptables -L -n -t nat
第四步，处理措施：
- DDoS攻击：使用iptables限速或接入云防护
六、综合排查案例
6.1 案例一：服务器负载高但CPU使用率不高
现象：uptime显示load average很高，但top显示CPU使用率不高。
分析：load average高但CPU空闲，说明进程在等待IO或其他资源，而不是在计算。
排查步骤：
用vmstat查看：
vmstat 2 5
关注r列（运行队列）和b列（阻塞进程）。
用iostat查看IO：
iostat -x 2 5
看哪个磁盘的%util很高。
用iotop定位进程：
iotop
看哪个进程的IO最多。
根因：很可能是日志写入或数据库IO导致。
6.2 案例二：内存持续增长
现象：free命令显示内存使用持续增长，但应用日志没有明显异常。
分析：可能是内存泄漏或缓存增长。
排查步骤：
查看进程内存占用：
ps aux --sort=-%mem | head -20
监控特定进程：
for i in {1..30}; do ps -o pid,rss,vsz -p <pid>; sleep 10; done
检查swap使用：
free -hvmstat 2 5
根因：可能是应用内存泄漏或JVM heap配置过大。
6.3 案例三：CPU使用率高但找不到高CPU进程
现象：top显示CPU使用率很高，但ps命令找不到占用CPU高的进程。
分析：可能是系统调用或中断导致的CPU消耗。
排查步骤：
查看系统CPU消耗：
top
看sy（系统调用）占比。
查看中断：
cat /proc/interrupts
用strace分析进程：
strace -p <pid> -c
根因：可能是大量系统调用、软中断或网络中断。
七、性能优化建议
7.1 系统参数优化
调整文件描述符限制。高并发服务需要调整文件描述符限制：
# 查看当前限制ulimit -n# 临时调整ulimit -n 65535# 永久调整，编辑/etc/security/limits.conf* soft nofile 65535* hard nofile 65535
调整内核参数。编辑/etc/sysctl.conf：
# 增加tcp连接最大数量net.ipv4.tcp_max_syn_backlog = 65535# 调整socket缓冲区大小net.core.rmem_max = 16777216net.core.wmem_max = 16777216# 调整TIME_WAIT复用net.ipv4.tcp_tw_reuse = 1# 调整文件描述符fs.file-max = 65535
使配置生效：
sysctl -p
7.2 应用配置优化
JVM优化。对于Java应用，合理的JVM参数很重要：
-Xms4g -Xmx4g # 堆内存大小-XX:+UseG1GC # G1垃圾回收器-XX:MaxGCPauseMillis=200 # 最大GC停顿时间
Nginx优化：
worker_processes auto;worker_rlimit_nofile 65535;events { worker_connections 65535; use epoll;}
7.3 监控和告警
建立完善的监控体系是预防性能问题的关键。
关键告警指标：
建议使用Prometheus + Grafana或云监控服务。
总结
Linux性能排查的核心是建立系统化的思路：
- 先整体后局部：先用vmstat、iostat等工具确认问题类型，再定位具体进程
- 先CPU后内存、IO：CPU是最容易排查的，从它开始
- 多个指标配合看：单一指标可能误导，配合多个指标分析
- 找到根因再处理：不要盲目杀进程或重启服务，找到根因才能根本解决
常用命令速查：
# 系统整体状态uptimevmstat 2 5# CPU分析topps aux --sort=-%cpu | head -10# 内存分析free -hps aux --sort=-%mem | head -10# IO分析iostat -x 2 5iotop# 网络分析ss -snetstat -an | awk '/^tcp/{print $NF}' | sort | uniq -c# 进程详细分析strace -p <pid> -clsof -p <pid>pmap -x <pid>
性能优化是一个持续的过程，需要在日常运维中不断积累经验，建立完善的监控体系，才能在问题发生前发现问题。
八、生产环境实战案例
8.1 案例：Java应用频繁Full GC导致服务卡顿
背景：某电商平台促销活动期间，订单接口响应时间从正常200ms飙升至5-10秒，用户投诉页面加载缓慢。
排查过程：
- 初步诊断。登录服务器，用top查看CPU使用率，发现并不高，但load average偏高：
uptime# 16:45:12 up 45 days, 3:22, load average: 12.85, 10.21, 8.10top# 发现多个Java进程CPU使用率不高但运行时间很长
jstat -gc 12345 1000 10 # 每秒打印一次Java进程12345的GC统计
输出显示：FGC（Full GC）次数很多，每次Full GC耗时超过2秒。这是典型的GC过于频繁导致的服务卡顿。
jmap -heap 12345
输出显示：Heap配置了8GB，但老年代使用率持续在95%以上，说明内存分配不合理或者存在内存泄漏。
cat /var/log/myapp/gc.log | tail -100
GC日志显示：对象创建速度远大于回收速度，导致频繁Full GC。
根因：JVM heap配置过大（8GB），导致GC时扫描的内存区域过大，单次GC停顿时间过长。同时应用存在对象创建过多的问题。
修复方案：
修复后的JVM参数：
-Xms4g -Xmx4g \-XX:+UseG1GC \-XX:MaxGCPauseMillis=200 \-XX:G1HeapRegionSize=4m \-XX:InitiatingHeapOccupancyPercent=45 \-XX:G1ReservePercent=15
# 观察GC情况jstat -gc 12345 1000 10# 检查接口响应时间curl -o /dev/null -s -w "%{time_total}\n" http://localhost:8080/api/orders
总结：Java应用性能问题，GC是常见的根因。关键是要监控GC情况，分析GC日志，合理配置JVM参数。
8.2 案例：Nginx连接数暴涨导致服务不可用
背景：某网站突然无法访问，Nginx返回502 Bad Gateway错误。
排查过程：
systemctl status nginx# 显示nginx is runningnetstat -an | grep :80 | wc -l# 连接数超过60000
netstat -an | awk '/^tcp/{print $6}' | sort | uniq -c | sort -rn
输出显示大量TIME_WAIT状态连接，说明上游服务处理能力不足。
systemctl status php-fpm# 显示php-fpm正常运行netstat -an | grep 9000 | wc -l# 9000端口（PHP-FPM）连接数超过10000
ps aux | grep php-fpm | wc -l# 只有50个worker进程cat /etc/php-fpm.d/www.conf | grep ^pm.max_children# pm.max_children = 50
根因：PHP-FPM的max_children设置为50，但连接数远超这个数字，导致请求排队或被拒绝。
修复方案：
# 编辑 /etc/php-fpm.d/www.confpm.max_children = 200pm.start_servers = 50pm.min_spare_servers = 50pm.max_spare_servers = 200pm.max_requests = 500# 重启PHP-FPMsystemctl restart php-fpm
proxy_connect_timeout 60s;proxy_send_timeout 60s;proxy_read_timeout 60s;
upstream backend { server 127.0.0.1:9000; keepalive 200;}
- 优化数据库连接。检查数据库连接是否成为瓶颈，如果是，需要增加连接池大小或优化查询。
总结：高并发场景下，PHP-FPM等上游服务的进程数配置很重要。要结合服务器资源和业务特点合理配置。
8.3 案例：MySQL慢查询导致网站响应缓慢
背景：某论坛网站访问速度变慢，首页加载需要10秒以上。
排查过程：
top# CPU和内存使用正常netstat -an | grep :80 | wc -l# 连接数正常
mysql -u root -p -e "SHOW PROCESSLIST\G" | head -50
输出显示多个查询运行时间超过30秒，最长的超过5分钟。
cat /var/log/mysql/slow-query.log | tail -50
发现多个未建索引的JOIN查询，单表数据量超过千万级别。
mysql -u root -p -e "EXPLAIN SELECT * FROM posts JOIN users ON posts.user_id = users.id WHERE posts.created_at > '2026-01-01'\G"
输出显示：全表扫描，没有使用索引。
根因：posts表缺少user_id和created_at的联合索引，查询时全表扫描。
修复方案：
-- 先备份mysqldump -u root -p mydb posts > /backup/posts.sql-- 添加索引（注意：在大表上添加索引可能很慢，需要在业务低峰期执行）ALTERTABLE posts ADDINDEX idx_user_created (user_id, created_at);
-- 避免SELECT *SELECTid, title, created_at FROM posts WHERE user_id = 123;
# /etc/mysql/my.cnfslow_query_log = 1slow_query_log_file = /var/log/mysql/slow-query.loglong_query_time = 2
mysql -u root -p -e "EXPLAIN SELECT * FROM posts WHERE user_id = 123 AND created_at > '2026-01-01'\G"# 确认使用了索引
总结：数据库查询性能问题，首先要开启慢查询日志，定位慢查询，然后分析执行计划，添加合适的索引。
8.4 案例：服务器遭遇DDoS攻击
背景：服务器网络带宽突然占满，服务器无法远程访问，网站完全无法访问。
排查过程：
cat /proc/net/dev | grep eth0# 发现接收字节数异常高
netstat -an | awk '/^tcp/{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
发现大量来自同一IP段的连接。
ss -tan state syn-recv | wc -l# 超过50000个SYN_RECV连接
根因：SYN Flood攻击，攻击者发送大量SYN包但不完成三次握手，耗尽服务器连接资源。
处理措施：
# 屏蔽单个IPiptables -I INPUT -s 1.2.3.4 -j DROP# 屏蔽IP段iptables -I INPUT -s 1.2.3.0/24 -j DROP
# 编辑 /etc/sysctl.confnet.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 65535net.ipv4.tcp_syn_retries = 2net.ipv4.tcp_synack_retries = 2# 使配置生效sysctl -p
yum install fail2ban -y# 配置fail2bancat > /etc/fail2ban/jail.local << 'EOF'[DEFAULT]bantime = 3600findtime = 600maxretry = 100[ssh-iptables]enabled = truefilter = sshdaction = iptables[name=SSH, port=ssh, protocol=tcp]logpath = /var/log/securemaxretry = 5[nginx-http-auth]enabled = truefilter = nginx-http-authaction = iptables[name=nginx-auth, port=http, protocol=tcp]logpath = /var/log/nginx/error.logmaxretry = 10EOFsystemctl enable fail2bansystemctl start fail2ban
- 接入云防护服务。如果是大规模DDoS攻击，本地防护很难应对，建议接入云服务商提供的DDoS防护服务。
总结：DDoS攻击是常见的网络安全问题，需要建立多层防护机制。应用层可以用iptables和fail2ban，基础设施层建议使用云防护服务。
九、常用调优参数汇总
9.1 系统内核参数
编辑/etc/sysctl.conf，添加以下参数：
# 网络参数net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_fin_timeout = 30net.ipv4.tcp_keepalive_time = 1200net.ipv4.ip_local_port_range = 1024 65535net.ipv4.tcp_max_syn_backlog = 65535net.ipv4.tcp_max_tw_buckets = 5000net.core.somaxconn = 65535net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 65536 16777216# 文件系统参数fs.file-max = 65535fs.inotify.max_user_watches = 524288# 内存参数vm.swappiness = 10vm.dirty_ratio = 60vm.dirty_background_ratio = 5
使配置生效：
sysctl -p
9.2 limits.conf参数
编辑/etc/security/limits.conf：
* soft nofile 65535* hard nofile 65535* soft nproc 65535* hard nproc 65535
9.3 常用监控命令脚本
编写一个简单的性能监控脚本：
#!/bin/bash# performance_monitor.shLOG_FILE="/var/log/performance_$(date +%Y%m%d).log"echo"=== $(date) ===" >> $LOG_FILEecho"=== System Load ===" >> $LOG_FILEuptime >> $LOG_FILEecho"=== Memory Usage ===" >> $LOG_FILEfree -h >> $LOG_FILEecho"=== Top 10 CPU Processes ===" >> $LOG_FILEps aux --sort=-%cpu | head -11 >> $LOG_FILEecho"=== Top 10 Memory Processes ===" >> $LOG_FILEps aux --sort=-%mem | head -11 >> $LOG_FILEecho"=== Disk IO ===" >> $LOG_FILEiostat -x 1 1 >> $LOG_FILEecho"=== Network Connections ===" >> $LOG_FILEss -s >> $LOG_FILEecho"=== Done ===" >> $LOG_FILE
加入crontab定期执行：
crontab -e# 每天早上9点执行0 9 * * * /bin/bash /opt/scripts/performance_monitor.sh
十、总结
Linux性能排查需要建立系统化的思维框架：
- 理解四大资源：CPU、内存、磁盘IO、网络是性能问题的四个主要方向
- 掌握核心工具：top、vmstat、iostat、ss、netstat是排查的瑞士军刀
- 建立排查顺序：先整体后局部，先CPU后内存，IO网络配合看
- 多指标综合分析：单一指标可能误导，要配合多个指标判断
- 找到根因再处理：不要盲目重启服务，找到根本原因才能彻底解决
性能优化是一个持续的过程，需要在实践中不断积累经验。推荐的做法：
性能问题的排查和优化没有捷径，只有多实践、多总结，才能在遇到问题时快速定位、妥善处理。
10个月宝宝每天需要喝多少奶粉？
