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%，同时看await和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，必须与压测场景匹配，否则瓶颈永远不在硬件上
