Linux 性能调优的核心不是修改参数，而是先找到瓶颈所在，没有明确瓶颈时的盲目调整往往带来风险。

命令速用版

# 查看整体负载和 CPU 使用率
top -bn1 | head -n 5

# 查看内存和交换分区使用情况
free -h

# 查看磁盘 IO 等待和利用率
iostat -x 1 5

# 查看具体进程的资源消耗（生产环境慎用全进程监控）
pidstat -p <PID> 1 5  # 将 <PID> 替换为实际进程 ID

为什么会这样

系统性能问题通常表现为资源不足或资源争用。CPU 满负载会导致任务排队，内存不足会触发交换分区读写从而拖慢速度，磁盘 IO 瓶颈会让进程处于不可中断睡眠状态。如果不先确认是哪一类资源受限，直接修改内核参数往往无效，甚至可能掩盖真实问题导致系统不稳定。

典型场景内核参数调整

在确认瓶颈后，可针对性调整内核参数。修改前建议先备份当前配置。

1. 内存交换倾向调整：

# 临时生效
sysctl -w vm.swappiness=10

# 永久生效（写入配置文件）
echo "vm.swappiness=10" >> /etc/sysctl.conf
sysctl -p

2. 网络连接优化：

# 允许重用 TIME_WAIT socket
sysctl -w net.ipv4.tcp_tw_reuse=1
# 增加监听队列长度
sysctl -w net.core.somaxconn=65535

注意：修改 /etc/sysctl.conf 后需执行 sysctl -p 加载配置，重启后依然有效。

应用层配置优化案例

内核调整往往是最后手段，应用层配置优化通常收益更直接。

1. Java 应用内存配置：

避免默认堆大小导致频繁 GC，根据物理内存设定固定堆大小。

# 示例：设置初始和最大堆内存均为 4GB
java -Xms4g -Xmx4g -jar app.jar

2. Nginx 并发配置：

根据 CPU 核心数调整 worker 进程，优化连接数限制。

worker_processes auto;
events {
    worker_connections 65535;
}

分步处理

1. 建立基准：在业务正常或故障发生时，记录当前的负载平均值、CPU 使用率、内存使用量和磁盘 IO 等待时间。

2. 识别瓶颈：如果 CPU 使用率高且用户态占比大，通常是应用计算密集；如果等待 IO 时间长，检查磁盘性能或慢查询；如果内存频繁交换，检查应用内存泄漏或配置不足。

3. 实施调整：优先调整应用层配置（如线程池大小、缓存策略），确认无效后再考虑系统层（如文件描述符限制、网络缓冲区）。

4. 记录变更：修改任何配置文件前做好备份，确保可以随时回滚。

怎么验证是否生效

改动后再次运行上述监控命令，对比关键指标。例如调整磁盘调度算法后，观察 iostat 中的 await 值是否下降；调整网络参数后，观察丢包率或连接建立时间。同时观察系统日志 /var/log/messages 或 dmesg 确认没有新的报错。对于内核参数，可使用 sysctl -a | grep 参数名 确认当前值。

常见坑

1. 盲目关闭 Swap：虽然关闭交换分区可以避免换页延迟，但可能导致内存不足时直接触发 OOM Kill，需确保物理内存充足。

2. 随意调整内核参数：修改 /proc/sys 下的参数前需理解其含义，错误的网络参数可能导致连接重置或吞吐量下降。

3. 忽略上下文切换：高负载不一定是 CPU 不够，可能是进程切换过于频繁，需检查 vmstat 中的 cs 列。

4. 监控本身成为瓶颈：避免在生产环境高频率使用全进程监控命令（如 pidstat -p ALL），建议指定具体进程 ID 监控。