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限速
