Linux 容量评估需预判业务增长下的资源瓶颈，结合压测验证与分阶段规划，聚焦 CPU、内存、磁盘 IO、网络四类资源差异，匹配业务类型与负载模式，并统筹技术配置与非技术因素。
Linux 系统容量评估的核心不是看当前用了多少，而是预判业务增长后资源会不会扛不住。压测是验证预判的手段，容量规划是把验证结果变成可执行的扩容或优化动作。两者必须结合，否则容易要么过度投入，要么线上崩得突然。
明确评估目标：CPU、内存、磁盘 IO、网络四类资源不能混着看
不同业务瓶颈差异极大：Web 服务常卡在 CPU 和网络，数据库往往先耗尽内存和磁盘 IO，批处理任务可能瞬间拉满 CPU 但内存很空。评估前必须先确定主业务类型和典型负载模式（如峰值 QPS、平均连接数、单次请求数据量）。例如，一个日均 50 万 PV 的 API 服务，若平均响应时间已超 300ms 且 95 分位 CPU 使用率持续>75%，就要重点查 CPU 是否成为瓶颈，而不是直接加内存。
- CPU：关注 平均负载（load average）与逻辑 CPU 核数比值 ，持续>0.7 需警惕；用
pidstat -u 1定位高 CPU 进程 - 内存：重点看 可用内存（free + cache/buffer 可回收部分）是否长期<10%，而非简单看 used；
slabtop排查内核内存泄漏 - 磁盘 IO：用
iostat -x 1观察 %util 是否常>80%，同时看 awai t 和 svctm 是否明显升高——说明 I / O 队列积压 - 网络：用
ss -s看 socket 统计，netstat -s | grep -i "retrans"查重传率，超过 2% 需排查网络或应用层问题
压测要贴近真实，别只跑“Hello World”
很多团队用 ab 或 wrk 对一个静态页面压测，结果 CPU 才 30% 就停了——这完全没意义。真实压测必须模拟生产环境的请求组合、数据分布和并发模型。比如电商系统，不能只压商品详情页，还要混合加入购物车写操作、库存扣减、订单创建等，且数据要带 热点（如爆款商品 ID 集中访问）。
- 工具 选型：简单 HTTP 用
wrk，复杂链路推荐locust或jmeter，数据库压测用sysbench（MySQL）或pgbench（PostgreSQL） - 关键步骤：先单接口基线测试（记录 TPS、延迟、资源占用），再逐步增加并发，每档保持 5 分钟以上稳态，记录拐点（性能陡降或错误率突增处）
- 必须监控：压测同时运行
vmstat 1、mpstat -P ALL 1、iotop -o，避免“压测完才发现磁盘被打爆却没录到数据”
容量规划不是算术题，得留余量、看趋势、分阶段
根据压测拐点反推容量上限后，不能直接按 100% 用满来规划。实际部署必须考虑突发流量、内核升级、监控采集开销等隐性消耗。常规做法是按“70% 为安全水位”设计，再叠加业务增长预期。
- 短期（3 个月内）：按当前峰值×1.5 配置，重点优化慢 SQL、缓存命中率、连接池大小等软件层
- 中期（3–6 个月）：引入自动伸缩（如 K8s HPA 基于 CPU/ 自定义指标），或拆分无状态服务，降低单节点压力
- 长期（6 个月以上）：评估架构级调整，如读写分离、分库分表、引入消息队列削峰，避免单纯堆机器
- 务必建立容量看板：用 Prometheus+Grafana 持续跟踪核心指标趋势，设置阈值告警（如内存可用率<15% 持续 10 分钟）
别忘了“非技术”因素：部署方式、内核参数、应用配置同样影响容量
同一台机器，Docker 默认 cgroup 限制、systemd 服务的 LimitNOFILE 设置、Java 应用的 JVM 堆大小，都可能让实际可用资源打五折。压测和规划时必须锁定这些变量。
- 检查关键限制：
cat /proc/sys/fs/file-max、ulimit -n、容器启动时的--memory和--cpus - 内核调优示例：高并发 Web 服务建议调大
net.core.somaxconn（连接队列）、vm.swappiness=1（减少 swap 倾向） - 应用层确认：Nginx 的 worker_connections、MySQL 的 max_connections、Redis 的 maxmemory，必须与压测场景匹配，否则瓶颈永远不在硬件上
