大家好，我是 IT 老李。今天聊点实在的。昨天有个朋友找我诉苦，说他那台云服务器天天卡成 PPT，老板还总觉得是他技术不行。我帮他看了下，好家伙，内存占用 95%，swap 都飙起来了，这能不卡么？

其实很多运维兄弟都有这个问题——服务器配置不差，但就是跑不顺。今天老李就把压箱底的几个优化技巧掏出来，都是实战中总结的，照着做，你的服务器也能飞起来。

先说个反常识的：别迷信高配置

很多人一遇到性能问题就想着加钱升级配置。老李说句实话，80% 的性能问题不是配置不够，而是配置没用好。

我见过最离谱的案例：一台 16 核 64G 的服务器，跑个日 PV 5 万的博客都卡。查了半天发现，MySQL 的 innodb_buffer_pool_size 居然用的默认值 128M。改到 32G 之后，直接起飞。

所以第一步，先把你现有的配置吃透，再考虑花钱。

内核参数调优，这几个必须改

Linux 默认的内核参数是保守配置，为了兼容性牺牲了性能。生产环境必须调。

打开 /etc/sysctl.conf，加上这几行：

# 提高网络连接效率net.core.somaxconn = 65535net.core.netdev_max_backlog = 65535net.ipv4.tcp_max_syn_backlog = 8192# 开启 TCP 快速回收net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_fin_timeout = 30# 扩大端口范围net.ipv4.ip_local_port_range = 1024 65535# 提高文件句柄数fs.file-max = 2097152fs.nr_open = 2097152

改完执行 sysctl -p 生效。别怕改坏，这些参数都是经过验证的，出问题的概率比中彩票还低。

内存管理，别让 swap 拖后腿

swap 是个好东西，但也是性能杀手。一旦开始用 swap，磁盘 IO 直接爆炸。

两个建议：

1. 降低 swappiness
   ：默认值是 60，改成 1 或者 5。vm.swappiness = 1 告诉内核：不到万不得已别用 swap。
2. 监控内存使用
   ：别等 OOM 了才发现问题。装个 htop 或者 glances，实时监控。老李推荐 glances，界面友好，信息全面。

磁盘 IO，瓶颈往往在这里

很多人盯着 CPU 和内存，忽略了磁盘 IO。其实大多数 Web 应用，瓶颈都在磁盘。

几个优化方向：

• 用 SSD，别省这个钱
  ：机械盘和 SSD 的随机读写性能差几十倍，这不是钱能弥补的。
• 调整 IO 调度算法
  ：SSD 用 none 或者 noop，机械盘用 deadline。查看当前算法：cat /sys/block/sda/queue/scheduler
• 日志别写同一块盘
  ：应用日志、数据库日志、系统日志，能分开就分开。不然 IO 一高，大家一起卡。

容器化之后，别忘了资源限制

2026 年了，还在裸机跑应用的应该不多了。但容器化之后有个新问题：资源限制没配好。

Docker 或者 K8s 里，一定要给容器设资源限制：

resources:limits:cpu:"2"memory:"4Gi"requests:cpu:"1"memory:"2Gi"

不设限制的结果就是：一个容器把资源吃光，其他容器全饿死。老李见过太多这种事故了。

监控告警，别等用户投诉才发现

最后说个最重要的：监控。

别等用户打电话说"网站打不开了"才发现问题。Prometheus + Grafana 这套组合拳，装起来不难，但能救命。

关键指标就这几个：

• CPU 使用率（超过 80% 告警）
• 内存使用率（超过 85% 告警）
• 磁盘使用率（超过 80% 告警）
• 磁盘 IO 等待（超过 50% 告警）
• 网络连接数（异常波动告警）

告警渠道接上钉钉或者企业微信，有问题第一时间知道。

说在最后

运维这活儿，说白了就是"平时多流汗，战时少流血"。上面这些技巧，看着简单，但真能做到位的没几个。

老李的建议是：别想着一次性全改了。每周挑一个点优化，测试没问题再上线。稳扎稳打，比啥都强。

对了，如果你有什么独家的优化技巧，欢迎在评论区分享。大家互相学习，一起少加班。

有问题评论区见。