内存带宽和容量：先加哪个更划算

内存跑满了不等于就该买内存条，机器卡也不等于就该换 CPU。内存带宽容量先加哪个更划算，答案取决于这台机器眼下是被“装不下”卡住，还是被“算不快”卡住。前者补容量，后者看通道和频率，两笔钱花在两个完全不同的地方，搞反了就是白扔。下面把我这些年判断的顺序写出来，能省一笔是一笔。

内存带宽容量先加哪个更划算，先分清两种卡

装不下和算不快，症状压根不一样。装不下的机器，监控里最先红的是内存使用率和 swap，磁盘灯一直闪；算不快的机器，内存占用看着挺悠闲，CPU 死活上不去，磁盘也不忙，任务就是慢吞吞。前者是工作集超过了物理内存，系统被迫把热数据往磁盘上倒腾，倒一次两次看不出来，倒多了整机就发飘，本来毫秒级的请求开始排队。后者是数据喂得不够快，核再多也只能干瞪眼。

还有第三种，最坑人：两条都占一点。内存差一截、通道也没插满，你先补哪样都能好一点，但都不彻底，容易得出“加内存没用”这种结论。遇到这种机器，别急着下单，先把监控拉长到一个完整业务周期看，白天和夜里的曲线差多少，峰值那几分钟到底是谁先到顶。

容量告急的几张典型脸

看几个地方基本就能定性。swap 长期有进出、page fault 涨得快、系统日志里留下过 OOM killer 的名字，这几样凑一块，容量不够没跑。数据库那边更直白：InnoDB 的 buffer pool 命中率掉下去，磁盘读飙起来，加内存的收益通常比换 CPU 明显得多，这是最经典的一笔划算买卖。

Redis 频繁淘汰 key、PHP-FPM 子进程被系统杀掉、Java 服务隔三差五 Full GC，本质上都是同一类信号换了个名字。这时候别去纠结频率是 2666 还是 3200，先把容量顶到位。频率那点差距在容量不足面前，属于挠痒痒。

带宽不够的时候，CPU 反而显得很闲

内存带宽吃紧的表现有点反直觉：CPU 利用率不高，但吞吐就是上不去。多路机器上还容易撞见 NUMA 这档子事——进程在 A 节点上跑，数据落在 B 节点的内存里，跨节点取一趟延迟立马上去，核越多越难看。这种毛病换内存条治不了，得从绑核、调度的层面动手。

做加密、压缩、内存里大规模排序、向量检索这类活儿的机器，吃的是吞吐不是容量，通道数和频率这时候才值钱。反过来讲，普通企业站、CMS、小商城，基本碰不到这条线，别被参数表吓着，看到“高带宽”三个字就往里冲。

空着的插槽，是最容易白扔的钱

见过太多机器，八个插槽只插两根条子，还理直气壮说内存够用。够用是够用，通道数少一半，带宽直接打折，主板白瞎了。补同规格的条子把通道插满，通常比换 CPU 便宜不少，收益还是立竿见影的那种。

要留神两件事：混插不同频率会一起降到低的那个跑，标称值全成了摆设；ECC 的 RDIMM 和普通 UDIMM 不能凑一桌，这个以主板或服务器的官方规格说明为准，别听卖家一句“都能插”就信了。同代、同频、同容量最省心，实在要混，也尽量让每个通道的配置对称。

大容量数据库的两笔账

大容量数据库这行尤其容易算错。buffer pool 能装下热数据，靠的是容量；扫大表、做聚合、跑分析，靠的是带宽。日常点查是随机访问，容量和延迟更关键；那种一跑一大片的分析型查询，带宽和通道数就压上来了，还得看临时表和排序会不会把内存吃穿。

一笔钱只能解一道题。先看业务是哪一类，再决定是加条子还是换平台，别拿跑分析的机器去照抄线上的点查配置，反过来也一样。混跑的机器，宁可两头都留点余量，也别把某一头掐到临界点。

虚拟主机和小规格云主机，逻辑不太一样

在共享环境里折腾这些参数意义不大。VPS 或虚拟主机看到的内存数字，是服务商划给你的一段，背后物理机的通道、频率你既看不见也改不了，能动的只有套餐规格。这种场景下扩容是按月算账的，先确认到底是被自己的程序吃满，还是被邻居吵到——性能忽高忽低、半夜固定时段变慢，多半是共享资源的事，升级配置未必治得了根。

这类细节以服务商或官方页面的说明为准，别信截图，也别信群里随手甩的一张跑分图。同一台机器换个时段测，结果就能差出一截。

我一般按这个顺序动手

先看监控定性，别一上来就买硬件。容量线：内存使用率长期高位、swap 有进出、缓存命中率低，先加容量，把工作集塞进去，别的往后排。带宽线：CPU 上不去、吞吐卡死、插槽还空着，先插满通道、统一频率，再考虑平台换代。两条都占的机器，通常说明业务已经长到该拆了，堆硬件不如拆服务，把读写重的和计算重的分开，各自配各自的机器。

最后提一句，买之前先量，别照抄别人的配置单。同一份配置在别人那儿够用，到你身上可能差一截，因为跑的东西不一样。规格拿不准就去翻官方手册，翻不到就问服务商，别靠猜。花半天做测量，能省下的往往不止一根条子的钱。