开篇：你是否遇到过这些崩溃时刻？
凌晨2点，正在熟睡的你被电话惊醒：“线上服务响应超时，用户大面积投诉！”你匆忙打开电脑，SSH登录服务器，面对满屏的进程和日志，脑子一片空白——从哪里开始排查？用什么命令？怎么快速定位问题？
如果你也有过类似经历，或者正在为“Linux命令太多记不住”、“系统优化不知从何下手”而苦恼，那这篇文章就是为你准备的。掌握高效的排查与优化技巧，是每一位运维工程师的必修课。
读完本文，你将收获：
- 🔧 20个高频运维命令的进阶用法（不只是
ls、cd，而是top -Hp、strace -c这些实战利器）
- 📊 5大系统性能指标的优化方案（CPU、内存、磁盘I/O、网络、进程管理全覆盖）
- 🚀 3个生产环境真实案例拆解（附完整排查过程和可复用脚本）
- 💡 1套系统优化检查清单（可直接用于日常巡检和故障预防）
一、基础命令进阶：从“会用”到“用好”
1.1 CPU排查三剑客：top、htop、pidstat
很多人用 top 只会看CPU使用率，但真正的高手会这样用：
关键命令1：定位高CPU进程的具体线程
# 先找到高CPU进程的PID（假设是12345）
top -c
# 查看该进程的所有线程CPU占用
top -Hp 12345
# 将线程ID转换为16进制（用于匹配jstack输出）
printf "%x\n" 12356 # 假设高CPU线程ID是12356
踩坑经验：我曾经只看进程级CPU，结果某个Java应用的GC线程疯狂占用CPU却没发现，导致排查了3小时。正确做法：always 使用 -Hp 参数查看线程级详情。
关键命令2：实时监控指定进程的资源消耗
# 每2秒刷新一次PID 12345的详细资源占用
pidstat -u -r -d -t -p 12345 2
# 参数说明：
# -u: CPU使用统计
# -r: 内存使用统计
# -d: 磁盘I/O统计
# -t: 显示线程级别信息
1.2 内存排查进阶：不只是free -h
关键命令3：精准定位内存泄漏进程
# 查看进程内存映射，找出异常增长的内存段
pmap -x 12345 | tail -5
# 持续监控内存增长趋势（每5秒记录一次）
while true; do
date >> mem_monitor.log
ps aux | grep 12345 | grep -v grep >> mem_monitor.log
sleep 5
done
血泪教训：曾经一个Node.js应用内存缓慢泄漏，用 free -h 只能看到总内存在减少，却不知道是哪个进程。后来用 smem -rs swap -p 按swap使用量排序，立刻定位到问题进程。
1.3 磁盘I/O深度分析：iotop的高级用法
关键命令4：找出隐藏的I/O杀手
# 实时显示每个进程的磁盘读写速度
iotop -oP -d 2
# 参数说明：
# -o: 只显示有I/O活动的进程
# -P: 只显示进程，不显示线程
# -d 2: 每2秒刷新
# 查看某个进程的I/O详细信息
cat /proc/12345/io
实战技巧：MySQL数据库突然变慢，CPU和内存都正常，最后发现是日志文件写入导致磁盘I/O饱和。解决方案：将 innodb_flush_log_at_trx_commit 从1改为2，写入性能提升5倍。
二、系统优化实战：从原理到落地
2.1 CPU优化：不只是调整nice值
优化方案1：CPU亲和性绑定
# 将nginx worker进程绑定到指定CPU核心
# 在nginx.conf中添加：
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
# 验证绑定效果
taskset -cp $(pgrep nginx)
为什么要这样做：避免进程在CPU核心间频繁切换，减少L1/L2缓存失效，实测可提升15%性能。
优化方案2：中断负载均衡
# 查看当前中断分布
cat /proc/interrupts
# 将网卡中断绑定到特定CPU
echo 2 > /proc/irq/24/smp_affinity # 24是网卡中断号
2.2 内存优化：科学配置才是王道
优化方案3：合理设置swappiness
# 查看当前值
cat /proc/sys/vm/swappiness
# 临时修改（重启失效）
echo 10 > /proc/sys/vm/swappiness
# 永久修改
echo "vm.swappiness = 10" >> /etc/sysctl.conf
sysctl -p
参数选择经验：
- 数据库服务器：设为1-10（优先使用物理内存）
- 应用服务器：设为30-60（平衡内存和swap）
- 个人桌面：保持默认60
踩坑提醒：不要设为0！曾经为了“优化性能”设为0，结果内存不足时直接OOM Kill掉了核心进程。
2.3 网络优化：提升并发连接能力
优化方案4：TCP参数调优
# 优化TCP连接队列
echo 'net.core.somaxconn = 65535' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_max_syn_backlog = 8192' >> /etc/sysctl.conf
# 优化TIME_WAIT状态处理
echo 'net.ipv4.tcp_tw_reuse = 1' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_tw_recycle = 0' >> /etc/sysctl.conf # 注意：不要开启！
# 立即生效
sysctl -p
注意事项：tcp_tw_recycle 在NAT环境下会导致连接异常，生产环境绝对不要开启！这类网络参数的调整需要谨慎，务必在理解原理和测试后再应用。
三、实战案例：真实故障排查全过程
案例1：诡异的CPU 100%却找不到进程
故障现象：监控显示CPU使用率100%，但top命令看不到高CPU进程。
排查过程：
# Step 1: 检查是否有隐藏进程
ps aux | awk '{print $3}' | sort -rn | head -10
# Step 2: 查看内核线程
ps aux | grep "\[.*\]"
# Step 3: 检查I/O wait（发现wa值异常高）
top
# 显示：Cpu(s): 2.0%us, 3.0%sy, 0.0%ni, 0.0%id, 94.0%wa
# Step 4: 定位I/O瓶颈进程
iotop -oP
# 发现是rsync备份进程导致
根因：定时备份脚本使用rsync同步大量小文件，导致I/O wait飙高，CPU看起来100%但实际是在等待I/O。
解决方案：
- 将rsync改为增量备份：
rsync -avz --delete
- 限制rsync带宽：
--bwlimit=10240 （限制为10MB/s）
- 调整备份时间到业务低峰期
案例2：内存泄漏导致的连锁反应
完整排查脚本（可直接使用）：
#!/bin/bash
# 文件名：check_memory_leak.sh
# 功能：自动检测可能存在内存泄漏的进程
echo "=== Memory Leak Detection Script ==="
echo "Monitoring memory usage for 60 seconds..."
# 创建临时文件
tmpfile=$(mktemp)
# 第一次采样
ps aux --sort=-%mem | head -20 | awk '{print $2,$4,$11}' > $tmpfile.1
# 等待60秒
sleep 60
# 第二次采样
ps aux --sort=-%mem | head -20 | awk '{print $2,$4,$11}' > $tmpfile.2
echo -e "\n=== Processes with significant memory growth ==="
echo "PID MEM_BEFORE MEM_AFTER GROWTH COMMAND"
# 对比两次采样结果
while read pid mem1 cmd1; do
mem2=$(grep "^$pid " $tmpfile.2 | awk '{print $2}')
if [ ! -z "$mem2" ]; then
growth=$(echo "$mem2 - $mem1" | bc)
if (( $(echo "$growth > 0.5" | bc -l) )); then
printf "%-6s %-10s %-10s %-7s %s\n" \
"$pid" "$mem1%" "$mem2%" "+$growth%" "$cmd1"
fi
fi
done < $tmpfile.1
# 清理临时文件
rm -f $tmpfile*
echo -e "\n=== Recommendation ==="
echo "For suspicious processes, use: pmap -x PID"
echo "Or check memory maps: cat /proc/PID/smaps"
使用方法：
chmod +x check_memory_leak.sh
./check_memory_leak.sh
四、系统优化检查清单（可直接用于日常巡检）
每日检查项
- CPU负载：
uptime 查看1/5/15分钟负载，不超过CPU核数的0.7倍
- 内存使用：
free -h 确保可用内存 > 20%
- 磁盘空间：
df -h 确保所有分区使用率 < 80%
- 关键进程：
systemctl status nginx/mysql/redis 确保服务正常
每周优化项
- 清理日志：
find /var/log -name “*.log” -mtime +30 -exec rm {} \;
- 检查僵尸进程：
ps aux | grep defunct
- 分析慢查询：检查MySQL slow query log
- 更新系统：
yum update --security 或 apt-get upgrade
每月深度优化
- 磁盘碎片整理：
e4defrag /dev/sda1（ext4文件系统）
- TCP连接分析：
ss -s 查看连接状态分布
- 内核参数复查：对照最佳实践检查
/etc/sysctl.conf
结语：从被动救火到主动防御
掌握了这套“命令进阶 + 优化方案 + 排查脚本”的组合拳，你就能从被动的“救火队员”转变为主动的“系统架构师”。记住：优秀的运维不是没有故障，而是能在故障发生前发现征兆，在故障发生时快速恢复。
希望这份实战指南能帮助你在日常工作中游刃有余。如果你对系统性能调优和自动化运维有更多兴趣，欢迎在云栈社区与我们交流探讨。
发表于 18 小时前
|
查看: 0|
回复: 0
