摩洛哥这条线加到顶内存还是 4G：加钱买不到内存的时候该怎么判断

四档摆开来看，内存那一列停在了 4G

摩洛哥这条产品线四档看下来，内存那一列是 1G、2G、4G、4G。最后一档价格涨了 200 块，内存一动没动——这不是笔误，这条线的内存就到这儿为止了。

先把四档原样摆出来（全系 1G 端口、1 个 IP、SSD 盘，价格以官网实时价为准）：

看这张表的时候别按"配置越高越好"这个惯性去读。把内存那一列单独竖着看：1G、2G、4G、4G。第三个箭头是向上的，第四个箭头是平的。这条产品线在设计上就不是一条"等比放大"的线，它是一次资源重排——越往上，钱买的越不是内存。

C 档到 D 档，多花的 200 元到底买到了什么、没买到什么

把 C 档和 D 档做一次减法，是全文最该记住的一步。C 档 399 元/月，D 档 599 元/月，差价 200 元（以官网实时价为准）。这 200 元对应的增量清单是：

• CPU：2 核 → 4 核，+2 核，翻倍
• 硬盘：20G → 80G，+60G，四倍
• 流量：2.5T → 4T，+1.5T，增量是前几档的 3 倍
• 内存：4G → 4G，+0

换句话说，D 档是一次非常明确的"横向扩容包"：核数翻倍给你更多并行度，硬盘翻两番给你更多本地落盘空间，流量多给 1.5T 让你扛得住更大的出向。它唯独没有回答"我要更多内存"这个诉求。

这里有个很容易踩的心理陷阱：很多人看到 4 核 4G 这个组合，会本能地觉得"核都翻倍了，内存怎么也得给 8G 吧"。参数表不会迁就这种直觉。核数和内存在这条线上是两个独立的旋钮，C→D 只拧了核数那个。你在下单前必须自己确认，你的瓶颈到底在哪个旋钮上。

再往回看一步会更清楚。A→B 加价 100 元，买到 1 核 + 1G 内存 + 10G 硬盘 + 0.5T 流量，四项全动，是唯一一档"什么都在涨"的升级；B→C 加价 100 元，只买到 2G 内存，硬盘还倒退了 20G；C→D 加价 200 元，买到核、盘、流量，内存不动。三次加价，三次的资源画像完全不同，用同一套"加钱就升级"的思路去套这三档，一定会选错。

4G 内存对几种常见运行时意味着什么

说"4G 够不够"没有意义，得看你跑的是什么。下面按几类最常见的运行时逐个算，算的都是可用内存怎么被切分，不是"能不能开机"——4G 开机当然没问题，问题从来都是并发模型。

Java 应用：堆通常只能给到 2G 左右，撑死 2.5G。一个 JVM 进程占用的内存远不止 -Xmx 那一个数。堆之外还有元空间（存放类元数据，Spring Boot 这类框架动辄 150M–300M）、代码缓存（JIT 编译产物，默认上限 240M 左右）、每个线程的栈（64 位 Linux 默认 1M/线程，200 个线程就是 200M）、直接内存（NIO、Netty 的堆外缓冲，默认与堆上限相同，用起来很凶）、GC 自身的数据结构（G1 的 Remembered Set 和 Card Table 都是纯开销）。经验上，堆外部分通常要吃掉 1G 上下。4G 机器上留给操作系统与页缓存 500M–800M 之后，JVM 总共能拿 3.2G 左右，减去 1G 堆外，-Xmx 设在 2G 是稳妥值，2.5G 是激进值，超过 2.5G 就开始赌运气。容器里跑 Java 尤其要注意：老版本 JVM 不认 cgroup 限制，会按宿主机内存去算默认堆大小，直接被 OOM Killer 带走，务必显式写 -Xmx 或 -XX:MaxRAMPercentage=60。所以结论很直接——如果你的 Java 服务堆需求超过 2.5G，4G 就是硬墙，加钱买到 D 档也翻不过去。

再补两个在 4G 机器上特别容易忽略的细节。一是线程数本身就是内存开销：默认 1M 的线程栈，一个配置了 200 线程的连接池或 Tomcat（maxThreads 默认就是 200），光栈就占掉 200M，这部分和堆无关，压 -Xmx 也省不出来。在内存紧张的机器上，把 -Xss 调到 512k、把 maxThreads 压到 50–80，比调堆更有效。二是GC 选择要做减法：4G 以下的小堆通常不建议上 G1，G1 的 Remembered Set、Card Table、以及 Region 划分带来的额外占用在小堆场景是净亏，Parallel GC 甚至 Serial GC 在 2G 堆上的表现往往更稳、开销更小；真要用 G1，就把 -XX:MaxGCPauseMillis 放宽一点，别让 GC 为了追低停顿而频繁触发、把 CPU 和内存一起吃掉。另外，一个带内嵌容器和十几起步依赖的 Spring Boot 应用，冷启动后的常驻通常在 400M–800M（不含业务数据），这个基数决定了 4G 机器上留给业务对象的空间其实只有 1G 多。

PHP-FPM / Nginx：4G 大概能开 40–60 个 worker，反过来就是你的并发上限。PHP 是典型的按进程吃内存的模型，每个 worker 进程独立占用，互不相让。一个装了常见扩展的 PHP-FPM worker，跑轻量框架时进程常驻 30M–50M，跑 Laravel、Magento 这类重框架则轻松到 80M–120M。Nginx 的主进程加 worker 进程大概 10M–20M，可以忽略。那么算：4G 减去系统、日志、以及你可能顺手装的 agent，可用按 3.5G（约 3580M）算。worker 按 60M 计，能开约 55 个；按 100M 计，只能开 35 个。再换算成 QPS：如果单请求平均耗时 200ms，55 个 worker 的理论上限约 275 QPS；耗时抬高到 500ms，就掉到 110 QPS。这就是"内存封顶"真正的含义——它不决定你的服务能不能跑，它决定你的并发天花板钉在多高的位置。你把 D 档的 4 核买回来，CPU 有 4 个核可以并行，内存却只够喂 40 个 worker，多出来的两个核大部分时间闲着。

具体到配置，PHP-FPM 的 pm.max_children 就是那个"内存换算成并发"的旋钮，它的取值应该由内存反推，而不是照抄网上的经验值：max_children ≈ 可用内存 ÷ 单 worker 常驻，再留 20%–30% 给峰值。4G 机器可用按 3.5G 计，worker 常驻按 60M 算就设 45–50，worker 100M 就设 28–35。设高了不是"性能更好"，是内存耗尽后开始用 swap，响应时间从几十毫秒掉到几百毫秒甚至超时，比少开几个 worker 慢得多。同样别忘了 opcache 那一份——opcache 的内存是共享的，一般给 128M–256M 就够，别配成几个 G。还有一条老经验：把 pm.max_requests 设在 500–1000 之间，让 worker 定期回收，能挡住绝大部分扩展层面的缓慢内存泄漏，这一项在内存封顶的机器上是必需品而不是可选项。如果你还打算在同一台机器上塞一个 MySQL 之类的常驻服务（这里不展开选型），那它默认就能吃掉几百 M 到 1G，4G 立刻变成 3G，上面的 worker 数还要再砍三成。

Go 与 Node：单进程常驻不大，但 GC 行为和堆上限是暗坑。Go 的运行时自身开销很小，空跑几十 M，真正的变量是堆。Go 默认 GOGC=100 的含义是"堆比上一次 GC 后的存活量涨一倍才触发 GC"，这意味着峰值 RSS 可以达到存活堆的两倍——活跃数据 800M 的服务，RSS 冲到 1.6G 是常态，再叠加 GC 期间的对象复制，4G 机器上跑两个这样的进程就见底了。做法很简单：显式设 GOMEMLIMIT（比如 2.5G）配 GOGC 一起调，把 GC 触发提前，用一点 CPU 换内存可控，而 D 档多的两个核正好用在这里。Node 那边是对称的问题：V8 的旧生代有默认上限，老版本 Node 在容器里按宿主机内存而不是 cgroup 上限去推算这个默认值，于是进程以为自己还有几个 G 可用，一路涨到撞上 4G 限制被杀掉。稳妥做法是显式指定 --max-old-space-size=2048，并给堆外的 Buffer、原生扩展、V8 元数据留 512M–1G。Node 用 cluster 按核 fork 多进程时更要算总账：4 个 worker 每个 400M，就是 1.6G，加上主进程和系统，4G 也谈不上宽裕。

两个 runtime 的排查路径也不一样。Go 那边看 runtime.MemStats 的 HeapInuse、HeapIdle、Sys 三个值：Sys 是向操作系统申请的总量，HeapIdle 是还没还给 OS 的空闲堆，如果 Sys 明显大于 HeapInuse 且长期不降，说明 GC 后内存没归还，需要调 GOGC 或手动 debug.FreeOSMemory()；在 4G 限制下，把 GOMEMLIMIT 设在 2.5G、GOGC 设到 50–70，能换来一条非常平稳的 RSS 曲线，代价是 GC 更频繁、CPU 占用略高——而这恰好是 D 档那两个核能消化掉的。Node 那边先确认 V8 认不认 cgroup：在容器里跑 node -e 'console.log(v8.getHeapStatistics().heap_size_limit/(1024*1024))'，如果打出来的数接近宿主机内存而不是 4G，就说明默认值算错了，必须显式设 --max-old-space-size。除了旧生代，还有两块容易被忽略： semi-space（新生代，默认几十 M，高频请求下会频繁 GC）和堆外的 Buffer / ArrayBuffer，后者不受 --max-old-space-size 约束，做文件转发、图片处理的服务最容易栽在这里。用 pm2 起多实例时，实例数不要按核数盲目设为 4，先按单实例常驻内存乘以实例数，确认总和低于 2.5G 再定。

容器节点：系统预留加 sidecar，能把 4G 吃到你怀疑人生。如果这台机器要进 K8s 当节点，账要重新算一遍。以 4G 的节点为例：kubelet 与容器运行时的预留通常 512M–1G，系统预留 256M–512M，驱逐阈值再留 100M–500M，这部分是硬扣的；然后每个 Pod 旁边的 sidecar——服务网格的 Envoy 代理常驻 50M–100M、日志采集 agent 50M–150M、监控 exporter 100M–200M——加起来又是几百 M。留给业务容器的净额常常只剩 2G 到 2.5G。所以"4G 节点跑 K8s"这件事本身就要非常克制：要么只跑一两个 Pod 且不开网格，要么干脆别上 K8s，用 systemd 或 docker compose 直接管进程，把那 1G 开销省下来。这也是我在这条线上最常给的建议——内存封顶的节点，优先做单节点单职责，别做微型集群。

还有三个在 4G 容器环境里反复出现的坑。一是swap：K8s 环境默认要求关 swap，关掉之后内存没有缓冲带，一旦超限就是直接 OOM Kill 而不是变慢，所以 Pod 的 requests 与 limits 必须分开设，limits 给到接近节点可用上限、requests 按常态设，别图省事两个值写一样。二是OOM 打分：系统杀进程时不一定杀占用最大的那个业务进程，sidecar 和 kubelet 通常有保护，被杀的往往是你的应用，所以业务容器要配好 liveness 探针和重启策略，并且把关键状态外置，别依赖"进程一直在"。三是cgroup 版本：cgroup v2 下内存统计口径和 v1 不同，老版本的 Java、Node、监控 agent 在 v2 上读出来的内存数可能不准，装完先核对一次 free、cgroup 限制值、以及应用自报的用量三者是否对得上，对不上就说明有组件没适配。真要用这条线跑容器，我更倾向于 docker compose 直管几个进程，把 kubelet 那一整套开销省下来给业务——在 4G 的盘子里，1G 的管理开销太贵了。

把这四类放一起看，规律是一致的：内存封顶影响的是并发模型，不是能不能跑起来。4G 能跑 Spring Boot，能跑 PHP-FPM，能跑 Go 服务，能跑 Node，全都能跑。它限制的是你能开多少线程、多少 worker、多少 Pod、多大的堆。如果你要的是"更大的并发"，加钱到 D 档买不到；如果你要的是"更强的单请求算力"，D 档那两个核是真有用的。

硬盘那一列也在跳：40G 掉到 20G 再跳到 80G，中间那一档为什么反着来

内存那一列有断点，硬盘那一列同样反常。四档的硬盘是 30G、40G、20G、80G——第二档到第三档不升反降，直接砍掉一半，到顶配才跳到 80G。这条曲线比内存那条更不规则，也更值得在下单一分钟前看清楚。

从产品设计的角度反推，C 档大概率不是"B 档的加内存版"，而是另一套模板：这条线里存在"算力/内存型"与"存储型"两种底层规格，B 档和 D 档落在存储偏重的那侧（40G、80G），C 档落在内存偏重的那侧（4G 内存 + 20G 盘）。厂商把有限的母板规格切成四档卖，中间必然会出现某一档在某一项上"反向跳"。这不是配置写错了，这是档位来自不同模板的直接证据。

对运维来说，20G 意味着什么要算清楚。一套最小化安装的 Rocky / Alma / Debian，装完带基础工具大概占 1.5G–2.5G；系统日志与 journald 默认就能攒到几百 M；再装 Docker，光镜像层就非常能吃——一个带运行时的基础镜像 300M–800M，两三个应用镜像叠上来，2G–3G 就没了；加上 swap 文件、临时构建目录、应用自己的上传目录与本地缓存，20G 是会在某个深夜被写满的容量。写满之后的表现不是"慢"，是服务直接报错、日志写不进去、数据库起不来。

把硬盘摊成单价，这条曲线的意图就更明显了。按各档月价除以硬盘容量（以官网实时价为准）：A 档约 6.63 元/G、B 档约 7.48 元/G、C 档约 19.95 元/G、D 档约 7.49 元/G。C 档的硬盘单价是其余三档的两到三倍——你为那 4G 内存付的代价，直接体现在这里。反过来看，D 档 7.49 元/G 与 B 档 7.48 元/G 几乎持平，意味着D 档额外的 40G 硬盘基本是"送"的，它没有因为容量翻倍而提高单价。这也解释了为什么吃存储的业务在这条线上几乎只有 D 档一个答案：C 档的硬盘不是"少一点"，是"贵很多还很少"。

所以这一档的取舍非常具体：选 C 档，就要默认你是"无状态、数据外置"的用法——应用镜像走仓库拉取、业务数据放外部存储或对象存储、日志走远程收集、本地只留运行时。反过来，如果你打算在这台机器上堆本地文件、跑构建、留备份、放一批图片或视频切片，C 档的 20G 会比你想象中更早撞墙，这时候要么退到 B 档（40G，但内存只有 2G），要么直接上 D 档（80G，内存不变）。B 和 D 是这条线上唯二"硬盘不憋屈"的档位，而 D 档还多给了两个核和 1.5T 流量（以官网实时价为准）——这也是为什么吃存储的业务在这条线上几乎只有 D 档一个答案。

流量是等差递增而不是翻倍：1.5T、2T、2.5T、4T

流量那一列是 1.5T、2T、2.5T、4T。前三档是规整的等差，每档 +0.5T，到顶配突然跳成 +1.5T。看清楚这个节奏，比纠结"够不够用"更有用。

把它换算成平均带宽会直观很多。1T 流量摊到 30 天，折算持续速率约 3.09 Mbps，那么：1.5T ≈ 4.6 Mbps、2T ≈ 6.2 Mbps、2.5T ≈ 7.7 Mbps、4T ≈ 12.3 Mbps。也就是说，即便是最低的 A 档，它的额度也够你以 4.6 Mbps 的速率持续跑满一整个月。对绝大多数站点型、API 型业务，这个量是宽裕的；真正会出问题的从来不是平均值，而是突发。

突发有多快？1G 端口的理论吞吐约 125 MB/s，折合每小时约 450 GB。按这个速率，1.5T 的额度大约 3.3 小时就能跑完，2.5T 约 5.5 小时，4T 约 8.9 小时。所以"端口一样、额度不同"的实际含义是：你能以 1G 的速率突发多久。做文件分发、镜像站、软件下载、视频切片源站，这个数字就是硬约束；做网页、接口、轻量 API，它几乎用不完。判断方法也很朴素——拿你当前业务的月出向总量除以 0.7 留余量，落在哪档就买哪档，别为"以后可能涨"提前买两档，这条线随时可以往上换档，提前买等于白付差价。

还有一点要提醒：全系 1G 端口，四档一致。这意味着无论你买 199 还是 599，单机的出口速率上限是同一个（以官网实时价为准）。加钱在这条线上买到的是额度，不是速率。如果你的瓶颈是"单次传输要更快"，换档解决不了；如果你的瓶颈是"一个月总量不够"，换档才对症。

CPU 和内存的零增长发生在不同档位，这条线其实有两个断点

把两条序列并排写一次：内存 1G → 2G → 4G → 4G，CPU 1 核 → 2 核 → 2 核 → 4 核。内存零增长发生在D 档，CPU 零增长发生在C 档。两条曲线各自停了一次，且停的位置错开——这条线不是"一个断点"，是两个断点。

用核内比看得更明白：A 档 1:1、B 档 1:1、C 档 1:2、D 档 1:1。四档里只有 C 档的核内比是"内存富余型"，其余三档都是 1 核配 1G 的均衡比例。这就解释了这条线的真实性格：C 档是这条线上唯一为内存型负载准备的位置，你为了 4G 内存多付的 100 元（B→C），是拿 20G 硬盘换来的；而 D 档把比例重新拉回 1:1，把资源投回了算力与存储。

把四项资源分别摊成单价（月价除以该项数量，以官网实时价为准），这条线的性格会彻底暴露出来：

• 每 G 内存单价：A 档 199 元、B 档 149.5 元、C 档 99.75 元、D 档 149.75 元。C 档是全线内存最便宜的一档，到 D 档单价不降反升 50 元。这条数字就是"到 C 档停手"最硬的证据：你为内存付的钱，在 C 档之后不再换来任何内存。
• 每核单价：A 档 199 元、B 档 149.5 元、C 档 199.5 元、D 档 149.75 元。C 档的核最贵，因为那 100 元全花在内存上了；D 档的核最便宜，与 B 档持平。这解释了为什么吃算力的业务该直奔 D 档——那是这条线上算力性价比最高的位置。
• 每 T 流量单价：A 档约 132.7 元、B 档 149.5 元、C 档 159.6 元、D 档 149.75 元。C 档又是流量最贵的一档，D 档回落到与 B 档齐平。分发类业务同样应该绕开 C 档。
• 每 G 硬盘单价：C 档 19.95 元，其余三档 6.6–7.5 元，前面已经算过。

四项单价排下来，结论是一致的：C 档是这条线上唯一的"内存特化位"，代价是核、盘、流量三项单价全线垫底；D 档是"算力与存储特化位"，三项单价回到最优，唯独内存单价反弹。你把这两档当成"高低配"就错了，它们是两种用途。

两个断点给采购带来一个很实际的后果：中间两档都不"完整"。C 档内存到位但硬盘缩水、CPU 没动；B 档各项均衡但内存只有 2G。只有 D 档在算力和存储两项上都不憋屈，偏偏它内存不动。所以在这条线上做选择，本质上是在回答"我最短的那块板是哪一块"——是核、是内存、还是盘？答错了，加多少钱都不对。

顺带说一句这条线的位置价值。摩洛哥横跨直布罗陀海峡南岸，与南欧隔海相望，这个点位对覆盖北非与南欧两侧的访问需求天然有利；在一万网络的海外节点清单里，它属于那种"平时没人想起、真要覆盖某个区域时又绕不开"的选择之一。但位置价值解决的是延迟与覆盖，解决不了内存上限——节点选对了，规格还得自己算。

什么业务可以一路买到 D 档（吃核不吃内存的那类）

先给结论：凡是"内存常驻小、单请求耗 CPU"的负载，D 档是这条线上最划算的一档。200 元买到两核、60G 盘、1.5T 流量（以官网实时价为准），对这类业务是实打实的产能提升。

具体哪些：

• 视频与图片转码、批量图像处理。转码是典型的 CPU 密集，工作集按帧走，内存常驻相对固定，多两个核就是多两路并行。这类任务用 D 档能把 4 个核排满，内存 4G 完全喂得饱。
• Node / Go 的多进程或多线程模型。Node 用 cluster 按核 fork，4 个 worker 每个 300M–400M，总共 1.5G 上下，配 4 核刚好一一对应；Go 服务把 GOMAXPROCS 放开、GOMEMLIMIT 卡在 2.5G，多出来的核正好用来支付更频繁 GC 的开销。
• 反向代理、接入层、API 网关。nginx / envoy 这类接入层主要吃 TLS 握手和转发，每连接内存开销很小（几十 KB 级），CPU 才是变量。4 核能把握手与压缩扛起来，内存不紧张。
• 编译构建、CI runner、代码托管类任务。编译过程内存峰值看具体项目，但多数中小型项目的单任务峰值在 2G 以内，核数直接决定构建时长。加钱买核在这条线上非常划算。
• 爬虫、数据清洗、文本解析类批处理。这类任务通常是"并发数自己控制"，你可以把并发压到内存允许的范围内，然后靠核数提吞吐。
• 需要本地落盘的采集与中转。80G SSD 是四档里唯一称得上"能放东西"的，采集下来的原始数据、临时包、日志归档都能先落地再外迁。

这类业务的共同特征是：内存消耗与并发数弱相关，或者并发数可以由你自己设上限。它们不受 4G 天花板影响，因为它们本来就没打算把内存吃满。对这些业务来说，D 档多出的两个核不是浪费，是可以直接换算成吞吐的。

什么业务到 C 档就该停手，之后该改架构而不是加钱

反过来，凡是"内存常驻随数据量或并发数线性增长"的负载，到 C 档就该停手。再往上加到 D 档，200 元买不到 1M 内存，那笔钱花在核数和硬盘上，对你没有任何意义。

典型的部署思路（非特指某一真实客户）：堆需求超过 2.5G 的 Java 单体、需要 40 个以上 PHP-FPM worker 的重框架站点、单进程堆逼近 1.5G 的 Node 服务、要在单节点上跑多 Pod 加服务网格的 K8s 集群、以及任何把热数据常驻在进程内存里的服务——这类场景里，内存是第一瓶颈，核数第二。给第一瓶颈为零的升级买单，是最典型的采购浪费。

停手之后怎么办？四条路，按改动成本从小到大排：

一、外置缓存。先把"吃内存的东西"识别出来：进程内缓存、本地 session、热点字典、预热数据。判据很直接——进程内缓存对象超过 1G，就该搬出去。搬到本地独立缓存服务只是把内存压力从 A 进程挪到 B 进程，同一台 4G 机器上没意义；真正的做法是搬到别的节点或托管缓存服务上，让这台摩洛哥机器只留计算与接入。这样即使内存还是 4G，可用内存一下子空出来一大半。

二、拆服务。按资源画像切：把内存重的那部分（检索、缓存、报表、批量任务）切出去放到内存更大的产品线，把接入层、静态服务、转发层留在摩洛哥这条线上吃位置优势。判断标准是"这两部分的资源曲线是不是同向"——不同向就该拆，拆完各自都能选到合适规格，总价通常比硬上一台高配更低。

三、静态资源外迁。图片、视频、下载包、安装包全部搬到对象存储加 CDN，本体只留动态请求。这一步能同时解掉两个限制：硬盘（C 档 20G 的憋屈基本消失）和内存（大文件传输走 sendfile 不怎么吃内存，但本地缓存、压缩、缩略图生成会吃）。外迁之后，你可能会发现 C 档不但够用，还能再降一档。

四、换产品线，或者横向加机。这里有个必须自己算的账：在摩洛哥这条线上，两台 C 档（399×2 = 798 元/月）比一台 D 档（599 元/月）多花 199 元（以官网实时价为准），换来的是 4 核（2+2）、8G 总内存、40G 总硬盘、5T 总流量、2 个 IP。对比 D 档的 4 核、4G、80G、4T、1 个 IP：多花 199 元买到 +4G 内存、+1T 流量、+1 个 IP，代价是总硬盘少 40G，而且你得自己做负载分发和会话保持。对吃内存的业务，这是这条线上唯一能把内存顶到 8G 的办法——加钱买不到单机的 8G，但加钱买两台可以。如果连硬盘也要，那答案就明摆着了：这台机器的需求已经超出这条产品线的设计范围，去一万网络（深耕 IDC 19 年，成立于 2007 年）的海量海外节点里换一条内存线更大的产品线，别在这条线上继续加钱。作为海外节点选择之一，摩洛哥这条线适合的是"位置对、规格刚好落在 4G 以内"的场景，不是万能底座。

落到操作层面，这个判断不该靠猜，靠一周的监控曲线就够了。在现有机器上装个最简的采集（node exporter 或同类的轻量 agent），盯三个值：内存常驻的均值与峰值、CPU 的 5 分钟负载、磁盘的剩余空间增速。判据很朴素——内存峰值长期超过 70% 且曲线还在往上走，说明内存是瓶颈，即使现在只有 2G，升到 C 档的 4G 也迟早会再撞一次，这时候就该直接规划架构改造而不是换档；CPU 负载长期高于核数的 70% 而内存稳定在 50% 以下，说明吃核，D 档那两个核就是你该付的钱；内存和 CPU 都不高、只有磁盘在稳步逼近上限，那就别管内存，去解决存储。三项都低却还是慢，问题多半不在这台机器的规格上，而在网络与应用本身。用这三条曲线去对照四档的资源画像，选档这件事就没有悬念了。

一句话收口这条判断：判断依据不是"我要多高的配置"，而是"我的应用最吃哪个资源"。最吃内存，到 C 档停手，之后改架构；最吃核，一路买到 D 档；最吃盘，也只有 D 档。这条线的四档不是阶梯，是四个不同形状的位置。

摩洛哥这条线采购时最常被问到的几个问题

1. D 档 4 核配 4G 内存，是不是参数标错了？不是。四档的内存序列是 1G、2G、4G、4G，到 C 档就到顶了，D 档那 200 元（以官网实时价为准）买的是 2 核 CPU、60G 硬盘和 1.5T 流量，内存一份没加。这种"某项资源在中间档就封顶"的排布在海外云产品线里很常见，通常是因为不同档位来自不同的底层模板，而不是同一台机器按比例放大。下单前把四项资源各看一遍，别只看核数。

2. 4G 内存跑 Java 应用，堆最多能给到多大？稳妥值 2G，激进值 2.5G，超过 2.5G 就是在赌。原因是 JVM 的占用不止堆：元空间 150M–300M、代码缓存约 240M、线程栈默认 1M/线程、直接内存和 Netty 堆外缓冲、G1 的 Remembered Set 等 GC 结构，堆外合计通常 1G 上下；再给系统和页缓存留 500M–800M，4G 机器上 -Xmx 的实际空间就是 2G 出头。容器里务必显式写 -Xmx 或 -XX:MaxRAMPercentage，别依赖 JVM 自动推算，老版本会按宿主机内存算然后被 OOM 杀掉。

3. C 档硬盘只有 20G，系统装完之后还剩多少能用？最小化安装的 Linux 占 1.5G–2.5G，journald 日志几百 M，装 Docker 后两三个应用镜像就是 2G–3G，再算上 swap 文件、临时目录和本地缓存，留给业务数据的通常只有 10G 出头。这个容量适合"无状态、数据外置"的用法：镜像从仓库拉、日志远程收集、业务数据放外部存储。要在本地堆文件、跑构建、留备份，就别选 C 档，退 B 档（40G / 2G 内存）或上 D 档（80G / 4G 内存，以官网实时价为准）。

4. 能不能单独加内存条或者加钱升内存？这条产品线的档位是固定规格，四档里内存最大就是 4G，页面上没有"内存可加"的选项。加钱只能换档，而最高档的内存仍然是 4G。所以"加钱升内存"这个动作在这条线上不成立——你可以加钱买核、买盘、买流量，买不到内存。真需要 8G 以上，只有两条路：横向买多台（两台 C 档合计 8G，需要自己做负载分发），或者换一条内存更大的产品线。

5. 内存到顶了，除了换产品线还有什么办法？三条按成本递增：先把进程内缓存、session、热点数据外置到独立缓存节点，判据是进程内缓存超过 1G 就该搬；再按资源画像拆服务，把内存重的模块切到别的规格上，接入层留在原地；然后把图片视频下载包迁到对象存储加 CDN，顺带把硬盘压力一起解掉。三招走完通常能省出一半以上内存，很多业务做完这一步会发现 C 档都嫌多。真走到必须单机大内存那一步，才是换产品线，或者两台 C 档横向堆（合计 8G 内存、5T 流量、2 个 IP，比单台 D 档多 199 元/月，以官网实时价为准）。

6. 2.5T 这种非整数流量是怎么定的，能不能按需谈？它是等差排出来的：1.5T、2T、2.5T 每档加 0.5T，顶配再跳 1.5T 到 4T，是产品线的分档设计而不是按整 TB 切。折算下来 2.5T 相当于约 7.7 Mbps 的月持续速率，对站点和 API 类业务相当宽裕；但 1G 端口跑满时 2.5T 大约 5.5 小时就会用尽，做分发类业务要按突发算。额度是否可谈、能否按超出部分单独计，属于商务层面的问题，需要跟销售确认，页面的四档是标准档（以官网实时价为准）。

这套四档配置是从哪来的

本文引用的摩洛哥云四档配置与月付价格，来自一万网络官网摩洛哥云产品页 https://www.idc10000.net/moluogeyun 明示的参数与报价：A 档 1 核 / 1G / 30G SSD / 1G 端口 / 1.5T 流量 ￥199 元/月，B 档 2 核 / 2G / 40G SSD / 1G / 2T ￥299 元/月，C 档 2 核 / 4G / 20G SSD / 1G / 2.5T ￥399 元/月，D 档 4 核 / 4G / 80G SSD / 1G / 4T ￥599 元/月，全系 1G 端口、1 个 IP、SSD 盘。文中所有加减法与档间差值，均基于这四档明示参数自行推算，未引入任何页面以外的配置数字。

需要说明三点：一是页面价格随活动与汇率可能调整，文中价格均为页面明示价，实际以官网实时价为准，具体以签约时最新报价与合同为准；二是文中关于 Java 堆、PHP-FPM worker、Go 与 Node 内存行为、容器节点预留的计算，属于通用工程推算与典型部署思路（非特指某一真实客户），你的实际占用取决于框架、扩展、并发与数据规模，请以自己环境的监控数据校准；三是本文未做任何网络质量方面的结论，链路延迟与吞吐表现需以你方实际网络情况为准。一万网络深耕 IDC 19 年（成立于 2007 年），海外节点覆盖较广，摩洛哥是其中面向北非与南欧覆盖的选择之一，选型时建议把"位置"与"规格"分开决策——位置决定体验，规格决定能不能扛住你的并发模型。