2026 年 Linux 服务器运维优化实战技巧，看完少加班两小时

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

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

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

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

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

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

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

Linux 默认的内核参数是保守配置，为了兼容性牺牲了性能。生产环境必须调【修改前记得备份！！！备份！！！备份！！！】。

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

 BASIC

# 提高网络连接效率
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 8192

# 开启 TCP 快速回收
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30

# 扩大端口范围
net.ipv4.ip_local_port_range = 1024 65535

# 提高文件句柄数
fs.file-max = 2097152
fs.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 里，一定要给容器设资源限制：

 BASIC

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

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

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

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

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

关键指标就这几个：

• CPU 使用率（超过 80% 告警）

• 内存使用率（超过 85% 告警）

• 磁盘使用率（超过 80% 告警）

• 磁盘 IO 等待（超过 50% 告警）

• 网络连接数（异常波动告警）

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

说在最后

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

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