CPU和内存怎么搭配才不浪费？按用途和并发算清楚
CPU和内存怎么搭配，没有放之四海而皆准的比例。核心原则是让两者中更紧缺的资源不成为瓶颈：CPU密集型业务优先保核数，内存密集型业务优先保容量，均衡型业务参考常见比例再根据监控调整。
下面按用途给出估算方法，并说明选型后如何验证。
先判断业务属于哪一类
搭配之前，先回答三个问题：
- 应用是计算密集还是内存密集？比如视频转码、批量计算偏CPU；数据库、缓存、Java应用偏内存。
- 并发访问量大概多少？并发越高，Web进程和数据库连接占用的资源越多。
- 是否在同一台服务器上跑多个服务？数据库和Web服务混部时，内存要叠加计算。
如果只是个人博客或企业展示站，1核1G或1核2G通常够用；
如果是MySQL加Web应用混部，2核4G是更稳妥的起点；
Java应用建议至少2核4G起步，因为JVM本身需要预留堆外内存。
按用途估算CPU与内存比例
静态网站和小型博客：CPU需求很低，内存主要被系统、Nginx和少量PHP进程占用。
1核1G能跑，但建议1核2G留出余量。
这类场景CPU和内存不需要严格比例，内存略富余即可。
数据库服务器：MySQL、PostgreSQL等对内存敏感，InnoDB缓冲池通常建议设为可用内存的50%到70%。
如果数据量在几GB以内，2核4G或2核8G比较常见；
数据量更大时优先加内存，CPU核数影响并发查询处理能力。
Java应用：JVM堆内存加上元空间、线程栈等开销，实际占用往往比堆设置大。
2核4G只能跑轻量服务，生产环境建议2核8G或4核8G起步。
CPU核数影响GC线程和请求处理，内存不足会直接导致OOM。
高并发Web服务：PHP-FPM或Node.js进程数受CPU核数限制，同时每个进程占用内存。
按每核支撑20到50个并发估算，再乘以单进程内存，就能粗略得出内存需求。
例如4核、每进程50MB、预期200并发，内存至少需要10GB左右。
云服务器选型时的实操检查
在云控制台选配置时，按以下顺序核对：
- 查应用官方文档的最低配置要求，作为下限。
- 估算系统基础占用：Linux系统本身约200到500MB，加上监控、日志等常驻服务。
- 列出每个业务进程的常驻内存，相加后留20%到30%余量。
- 确认CPU核数是否满足并发进程数或线程池大小。
- 如果预算有限，优先保证内存不低于估算值，CPU可以后续升配。
选型后不要立刻认定配置合理，上线后观察一周再判断。
用监控验证搭配是否合理
登录服务器后，用以下命令检查实际使用情况：
# 查看CPU负载和空闲率
top -bn1 | head -5
# 查看内存和swap使用
free -h
# 查看历史负载（需安装sysstat）
sar -u 1 5判断标准：
- CPU空闲率长期低于20%，说明CPU偏紧，考虑升核或优化代码。
- 内存可用值长期低于总内存的10%，且swap开始被使用，说明内存不足。
- swap使用量持续增长但CPU不高，通常是内存不够，应用被迫换页。
如果两者都紧张，优先升级更影响业务响应的那个。
数据库场景优先加内存，计算场景优先加CPU。
常见误区
只看总价不看配比：低价高内存但CPU核数很低的机型，跑数据库或编译任务时CPU会成为瓶颈。
内存越大越好：内存超过实际需求的部分不会提升性能，反而增加成本。
按监控数据调整更合理。
忽略系统盘和带宽：CPU和内存搭配合理，但磁盘IOPS不足或带宽跑满，整体体验依然会差。
CPU和内存怎么搭配，最终要回到业务实际消耗。
先按用途估算一个起点，上线后用top和free验证，再根据监控数据调整，比套用固定比例更可靠。
