2026 年 Linux 服务器运维优化实战技巧，看完少加班两小时
其实很多运维兄弟都有这个问题——服务器配置不差，但就是跑不顺。今天老李就把压箱底的几个优化技巧掏出来，都是实战中总结的，照着做，你的服务器也能飞起来。
先说个反常识的：别迷信高配置
很多人一遇到性能问题就想着加钱升级配置。老李说句实话，80% 的性能问题不是配置不够，而是配置没用好。
我见过最离谱的案例：一台 16 核 64G 的服务器，跑个日 PV 5 万的博客都卡。查了半天发现，MySQL 的 innodb_buffer_pool_size 居然用的默认值 128M。改到 32G 之后，直接起飞。
所以第一步，先把你现有的配置吃透，再考虑花钱。
内核参数调优，这几个必须改
Linux 默认的内核参数是保守配置，为了兼容性牺牲了性能。生产环境必须调【修改前记得备份！！！备份！！！备份！！！】。
打开 /etc/sysctl.conf，加上这几行：
# 提高网络连接效率 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 直接爆炸。
两个建议：
降低 swappiness：默认值是 60，改成 1 或者 5。
vm.swappiness = 1告诉内核：不到万不得已别用 swap。监控内存使用：别等 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% 告警）
网络连接数（异常波动告警）
告警渠道接上钉钉或者企业微信，有问题第一时间知道。
说在最后
运维这活儿，说白了就是"平时多流汗，战时少流血"。上面这些技巧，看着简单，但真能做到位的没几个。
老李的建议是：别想着一次性全改了。每周挑一个点优化，测试没问题再上线。稳扎稳打，比啥都强。
对了，如果你有什么独家的优化技巧，欢迎在评论区分享。大家互相学习，一起少加班。
有问题评论区见。
