Linux 服务器容量规划需基于可观测数据：CPU 看持续负载趋势与任务类型，内存防 Swap 滥用与泄漏，磁盘重增长量与 IO 性能，网络需结合连接模型及内部通信综合评估。
Linux 服务器容量规划不是靠经验拍脑袋，而是基于可观测数据做资源推演。关键在三点：看清当前负载、理解增长逻辑、留出弹性余量。
CPU 评估：别只看峰值，要看负载趋势
CPU 使用率瞬时值（如 top 显示的 %CPU）容易误导。真正影响容量决策的是持续性负载特征：
- 用 sar -u 1 30 采集 30 秒内每秒采样，观察 1 分钟平均负载（load average）与 CPU 核心数比值；若 15 分钟 load > 核心数×0.7，说明存在潜在瓶颈
- 区分计算型与 I / O 型任务：数据库或 AI 推理类服务更依赖单核性能，Web 服务则受益于多核并发；Skylake 架构 CPU 单通道内存带宽 21.33 GB/s，6 通道总带宽 128 GB/s，内存吞吐可能成为隐性瓶颈
- 容器化环境需额外验证：cgroups 隔离下 /proc/loadavg 反映的是宿主机全局负载，而 docker stats 才能看到容器真实 CPU 节流（throttling）情况
内存评估：警惕 Swap 和缓存假象
free - m 显示“可用内存”不等于可分配内存。系统会把空闲内存用于 page cache，但一旦应用申请，cache 会被快速回收——这本身是正常机制。真正危险信号是：
- SWAP 使用率连续 3 次>5%，Zabbix 等监控应触发告警；此时说明物理内存已不足以支撑活跃工作集
- Redis、Elasticsearch 等内存敏感服务，建议预留至少 4GB 基础内存 + 每 100 万文档 / 键值对增加 1GB；数据库缓冲池（如 InnoDB buffer pool）应设为物理内存的 50%–75%
- 检查 /proc/meminfo 中 Active(anon)与 Inactive(anon)比例，若前者长期占主导且持续增长，大概率存在内存泄漏
磁盘容量与 IO：增长量比占用率更重要
df - h 显示 85% 使用率未必紧急，但若 /var/log 日志每天涨 50GB，按 365 天算就是 18.25TB 年增量——这才是规划依据：
- 用 du -sh /var/log/* | sort -hr | head -5 定位增长主力目录；促销季日志可能指数增长，静态 20% 冗余策略会失效
- iostat -x 1 5 关注 await（I/ O 平均等待毫秒）和 %util：await > 10ms 且 %util > 80%，说明磁盘响应变慢，SSD 替换 HDD 或启用 LVM 在线扩容是优先动作
- MinIO 等对象存储场景，按公式计算总容量：当前量 × (1+ 年增长率）年数 × 副本数；10TB 数据、20% 年增、3 副本、5 年周期，需约 75TB 裸容量
网络与协同指标：带宽不是孤立参数
带宽需求必须结合连接模型计算。100 并发连接×1KB/ s 只是理论下限，实际要考虑 TCP 握手、TLS 加解密、HTTP 头开销：
- 用 ss -s 查看当前全连接数，配合 tcptrack 识别长连接服务（如 WebSocket），避免误判瞬时流量
- 云环境特别注意：当网络利用率>70%，TCP 重传率会几何级上升；阿里云 实测该阈值是扩容关键线
- 不要忽略内部通信开销：Kubernetes 集群中 etcd、kube-apiserver 节点间心跳、MinIO 集群内纠删码同步都消耗带宽，建议单独划 VLAN 或 QoS 限速
