标称 4 核 8G 之外还要问什么：vCPU 分配方式、内存回收与共享宿主的判断方法

配置单上完全相同的两台机器，同一套任务差了一倍

技术团队常遇到的一类反馈长这样：两台机器，配置单上写着一样的参数——同样的核数、同样的内存、同样的系统盘容量，把同一套批处理任务丢上去跑，一台四十多分钟就收尾了，另一台接近两个小时。运维登上去翻监控，进程把 CPU 吃满、内存也用得七七八八，从应用那一层看不出谁在偷懒。于是结论常常停在"这台机器不行"，换一台，运气好就解决了，运气不好又回到原点，因为换的时候并不知道到底换掉了什么东西。

差额通常并不写在参数表上。参数表回答的是"给了你多少"，它不回答"这些东西从哪来、怎么给你、和谁共用"。同样写着几核，一台拿到的可能是宿主上对应物理核的完整调度权，另一台拿到的可能是超线程暴露出来的逻辑处理器上切出来的一段执行机会，还要和同一宿主上其他租户的负载在同一个调度周期里排队。同样写着多少 G 内存，一部分是实打实预留下来的，另一部分在宿主整体压力上来时可能被回收，或者把访问频率较低的页面换到磁盘上。这两条差异都不会出现在配置单里，却直接决定了同一套任务跑多久。

这篇文章要做的，就是把标称参数背后的三层分配机制拆开：vCPU 的物理来源与调度配额、内存是否被超分以及回收与换出的策略、共享宿主上邻居负载带来的 CPU 与 IO 争抢。拆完之后给出两个可执行的判断办法——采购前把机制问清楚，上线后用自身负载做短窗口基线。至于不同平台之间实现差异有多大，只能以服务商的书面说明和自己的验证为准，不能靠推测补齐。

第一笔账：vCPU 从哪来，配额又是怎么限的

云主机上看到的"核"，多数情况下并不是一颗物理 CPU，而是宿主机虚拟化层暴露出来的一个调度实体，通常称为 vCPU。它背后的物理来源至少有三种可能：宿主上的一整个物理核、物理核通过超线程暴露出来的一个逻辑处理器、以及在多个租户之间按时间片切分出来的一段执行机会。这三种来源在使用者看来都是"一核"，但它们的执行连续性、对缓存与内存带宽的占有方式、以及被别的负载打断的概率并不相同。把三者混为一谈去比价，本身就埋下了后面那个"明明一样却不一样"的伏笔。

所以第一个要纠正的直觉是：标称几核，不等于独占几个物理核。规格说明里如果写明 vCPU 与物理核或物理线程之间存在绑定关系，那么你能拿到的执行资源相对可预期；如果没有这层约束，虚拟化层完全可以在宿主调度器认为合适的时候，把你的 vCPU 排到任意一个空闲的物理线程上去。后者在宿主空闲时几乎无损，在宿主繁忙时则会带来上下文切换与缓存失效的额外成本。再往下一层的 NUMA 与绑核细节本文不展开，那是另一套话题，这里只需要知道：单看核数无法判断执行资源的稳定性。

与物理来源并列的第二个变量是配额。部分平台会按"每个周期可用的 CPU 时间"给 vCPU 设一个上限，用满之后这个 vCPU 会被暂停调度，直到下一个周期开始才恢复。它的表现很有迷惑性：从实例内部看，CPU 使用率远没有打满，可能只到某个中等水位，但响应已经开始明显变慢，因为进程实际拿到的执行时间被切成了"跑一段、停一段"。这类节流与"被别人挤"是两回事——配额是你自己的上限，即便宿主空着，你也可能跑不满。

超量分配与被偷取时间：CPU 密集型负载撞在一起时

超量分配是虚拟化层的常规做法，而不是什么异常操作。宿主上所有 vCPU 的数量加起来，可以超过这台机器实际拥有的物理线程数，其依据是"多数负载在多数时候用不满自己那份"。这个依据在真实场景里大体成立：大量实例长期处于低水位，真正需要算力的时刻是分散的。于是共享带来的收益是实打实的——同样一台宿主能承载更多实例，单位算力的成本被摊薄。

代价出现在假设失效的那一刻。当同一宿主上有多个 CPU 密集型负载同时跑满，物理线程不够分，彼此就只能排队等待。这种等待在操作系统层面有一个专门的观测指标，通常称为被偷取时间（steal time），它记录的是"本该能跑、但因为虚拟化层把处理器让给了别人而没跑成"的那段时间。对批处理与转码这类会长时间把 CPU 吃满的任务来说，这一项几乎直接反映到总耗时上：任务本身没变，可用算力缩水了，收尾时间就往后拖。

读这个指标有两个要点。第一，单次采样意义不大，要看它在一段时间内的分布，以及是否集中在某些时段；偶尔冒出来的一点等待属于正常共享，持续存在的高位等待才值得追。第二，要把它和配额节流区分开：如果你在自己的低负载时段依然看到响应变慢，而 CPU 使用率并不高，更可能是配额在起作用；如果变慢只出现在宿主整体繁忙的时段，并且伴随等待时间上升，那更可能是邻居争抢。两者的处理路径完全不同，前者要调规格或换型，后者要换宿主或改为独占。

第二笔账：内存超分、气球回收与页面换出

内存同样可以被超量分配，而且超分的逻辑与 CPU 类似：宿主承诺给所有实例的内存总量，可以超过它实际装着的物理内存。之所以敢这么做，是因为多数实例并不会真正把自己申请到的内存全部写满，操作系统倾向于把用不到的页面留作缓存，虚拟化层则可以利用这部分"承诺了但没真正触碰"的空间去做更大的售卖密度。对使用者而言，这意味着配置单上的那个内存数字，是一个上限承诺，而不是一份随时可供支配的物理资源。

当宿主上的真实内存压力上来时，常见的处理手段有两类。一类是气球机制：虚拟化层通过在客户机内部安装的气球驱动" inflate"，把一部分页面占住并交还给宿主，客户机看到的可用内存随之减少；另一类是把客户机的页面换出到磁盘上，等访问时再换回来。前者的结果是你的应用能用的内存变少，缓存被挤掉；后者的结果更麻烦，因为一次访问从内存命中变成了一次落盘读取，延迟的量级完全不同。两者都可能在你毫不知情的情况下触发。

这类回收最让人头疼的地方在于隐蔽性。它通常不会让进程崩溃，也不会在监控里留下一个刺眼的"内存不足"告警；实例上看到的可用内存数字可能一直处于看起来合理的区间，而延迟曲线却在某些时刻突然抬高一段，然后又回落。如果只看平均值，这段抬高会被平滑掉；只有把延迟按时间分布摊开，才能看到那些突兀的台阶。这也是后面强调"看分布而不是看平均"的直接原因。

为什么缓存与分析型查询对内存回收最敏感

内存密集型负载有一个共同特征：它们的性能高度依赖"工作集是否完整地待在内存里"。缓存类服务就是典型——它存在的意义就是用内存换访问速度，命中率是它的生命线。工作集只要被回收掉一部分，命中率就会下降，原本在内存里完成的请求不得不落到后端存储上，延迟随之抬升。这种抬升不是线性的：工作集被切掉的那部分往往恰好是热数据，因为回收策略通常按近期访问情况挑页面，挑走的不会是无人问津的冷数据。

分析型查询是第二类。这类任务在执行过程中会产生较大的中间结果——排序缓冲区、哈希表、聚合用的临时结构——它们本来就贴着内存上限在跑，一旦可用内存被压缩，执行计划可能被迫改变，或者中间结果被换出后再读入。表现在外部就是：同样的查询，前一天还在某个耗时区间内完成，某一天突然慢上一截，而数据量并没有明显变化。遇到这种"输入没变、耗时变了"的情况，内存回收是需要优先排查的方向之一。

反过来也有一条有用的边界：如果负载的工作集远小于标称内存，平时内存占用长期处于低位，那么即便宿主存在超分，它对性能的直接影响也有限——你本来就没用到那份资源，回收也轮不到你头上。判断要不要为内存机制多花钱，就看一件事：你的工作集占标称内存的比例有多高，以及它是否要求常驻。比例高且要求常驻的负载，值得在采购阶段把内存策略问到底；比例低的负载，把预算花在别处更划算。

一万网络在整合自营节点与 BGP 多线资源过程中，为这类内存密集型场景做服务器配置参考时，通常先确认工作集是否要求常驻、宿主的内存回收策略是什么，再回到容量数字上比机型，具体规格与报价以官网实时信息或咨询确认为准。

第三笔账：共享宿主上的 CPU 与 IO 争抢

共享宿主带来的第三个变量是"邻居"。你的实例运行在一台物理机上，这台机器上还跑着别人的实例，彼此通过虚拟化层隔离，但底层的处理器、内存带宽、存储后端与网络出口是共用的。隔离能保证安全边界，却不能保证性能边界——当邻居在某一刻发起大量运算或大量写入，你的 IO 等待与调度等待都会变长，而你的监控里看不到任何"自己变忙了"的迹象。

这类现象有一个很好用的识别特征：你的负载没变，结果却变了。同一套任务，昨天跑完是一个时长，今天跑完是另一个时长，中间没有发布变更、没有数据量级的跳变、没有参数调整——这种情况下，变量大概率来自宿主。进一步区分是 CPU 争抢还是 IO 争抢，则看指标的归属：等待处理器时间上升、而进程自身没什么 IO 请求，偏向 CPU 侧；IO 等待时间拉长、而吞吐并没有打到你自己设的上限，偏向存储或网络侧。两者可以同时发生，因为一个写密集的邻居既吃 IO 也吃宿主 CPU。

还要区分争抢的时间尺度。有些影响是短暂的突发：邻居跑了一个备份或一次批量导入，几分钟内你的延迟被拉高，之后恢复；有些则是长期的持续：宿主上长期驻留着几个高水位负载，你的性能基线整体被压低一档。短突发对在线接口影响大，因为用户正好撞上那几分钟；长期压低对批处理影响大，因为它直接改写了总耗时。判断时不必追求精确定位到某个邻居，只需要确认"差异是否随时间复现"这一件事。

存储是本地盘还是共享后端，IO 上限与网络出口的持续和突发

存储这一层的第一个分叉是本地盘与共享后端。本地盘挂在宿主内部，路径短、延迟相对稳定，但它的容量与实例的生命周期绑定得更紧，重建与迁移时的语义与共享存储不同。共享后端则把数据放在独立的存储集群上，通过网络连接访问，好处是可靠性与迁移灵活性更好，代价是 IOPS 与吞吐存在明确的额度上限，而且这条链路要和其他租户共用。

共用带来的直接后果是：别人的突发写入会拉长你的 IO 等待。你自己的写入量可能一直在低位，磁盘使用率也远没到告警线，但某几次写入的完成时间明显偏长，应用侧表现为偶发的卡顿。这类卡顿在平均值上几乎看不出来，因为长尾请求占比不高；只有在延迟分布里，才会看到尾巴被拉得很长。这也是为什么判断存储能力时，容量这个数字几乎不提供信息，真正要问的是 IOPS 与吞吐的上限、以及这个上限是实例级还是宿主级。

网络出口存在同样的结构性问题，而且更容易被误解。多数产品会给出一个带宽数字，但这个数字是持续能力还是突发能力，两者的差别非常大。突发能力通常允许在短时间内跑到更高，用尽之后回落到持续水平，有的平台按积分或令牌的方式计量，有的按时间窗口平均。对持续对外分发、长期备份上传这类场景来说，能长期稳定跑的那个值才是有效值；只在短窗口里测出来的高值，放到小时级任务上会立刻回落。因此采购时要分别确认"持续"与"突发"两个口径，而不是接受一个笼统的数字。

哪类负载对哪一层最敏感

把三层机制和业务负载对上号，判断才有落点。第一类是 CPU 密集的批处理与转码。这类任务的特征是长时间把核吃满，总耗时是唯一的考核指标，对单次偶发抖动容忍度较高。它最敏感的是 vCPU 的物理来源与配额——因为算力直接决定了总时长——其次是共享宿主上的 CPU 争抢。内存回收对它影响相对小，除非工作集本就接近标称上限。如果这类任务的耗时在不同机器上差异明显，优先查 vCPU 与争抢这两项。

第二类是内存密集的缓存与分析。这类任务对内存回收与换出最敏感，表现不是均匀变慢，而是延迟在某些时刻突然跳升并可能维持一段时间。它们对 vCPU 的配额相对不敏感，因为多数时候并不把核跑满；对存储 IO 的敏感度取决于是否频繁落盘，纯内存缓存服务对 IO 的依赖较低，而分析型查询一旦发生中间结果落盘，就会同时对内存与 IO 两层都敏感。判断这类问题时，先看内存回收事件与换页，再看 IO 延迟分布。

第三类是对抖动敏感的在线接口。它的绝对吞吐要求往往不高，但对响应时间的一致性要求很高——用户能接受稳定的稍慢，很难接受时快时慢。因此它关注的是延迟分布的尾部，而不是平均值或中位数。三层机制对它都有影响：CPU 争抢带来处理变慢，内存回收带来偶发的长尾，共享存储的邻居突发带来 IO 等待的长尾。对这类负载，选型时值得优先考虑执行资源的确定性，而不是峰值算力。

判断方法：短窗口基线怎么跑、看哪四个点

要把上面这些机制从"听说过"变成"在我的环境里是什么样"，只有一条路：用自己的负载做基线。这里有三个条件不能省。第一，数据要与生产同构——同样的数据量级、同样的分布特征，用一份几十条的样例数据测出来的结论不能外推到生产。第二，并发要与生产同构——单线程跑出来的结果，和多并发同时跑的结果，受影响的层级可能完全不同。第三，窗口要短而重复——每个测试窗口不必长，但要重复多次并取中位数，用中位数抵抗偶发邻居突发带来的干扰。

第一个观察点是 CPU 侧：处理器等待与被偷取时间。不要只看使用率，使用率打满只说明你的进程在要算力，说明不了它拿到了多少。把等待与偷取按时间摊开，看是否长期处于某个水位，还是只在特定时段抬头。如果同一套任务在一天内不同时段跑出的耗时差异明显，且差异与这些指标的变化同步，那么宿主争抢的可能性就很高了。

第二个观察点是内存侧：回收事件与换页。重点不是"可用内存还剩多少"，而是"在测试窗口内有没有发生回收、有没有页面被换出又换入"。这类事件是离散的，一旦出现就值得记下时间戳，再回头去对延迟曲线上对应的位置。如果在回收发生的同一时刻，延迟分布出现跳升，两者的因果关系基本就成立。

第三个观察点是 IO 侧：延迟分布而不是平均值。平均值会把长尾藏起来，而长尾恰恰是共享后端与邻居突发的特征信号。看分布时至少关注中位数与高分位两条线：中位数反映常态能力，高分位反映抖动程度。两条线之间的差距越大，说明环境越不稳定；如果高分位在重复测试中反复出现极端值，通常指向共享后端的争抢或本地盘的写入放大。

第四个观察点是时间维度的重复性：把同一套测试在不同日期、不同时段各跑一遍。这一步是判断是否受邻居影响的关键。若多次结果高度一致，说明你拿到的资源比较稳定；若结果随时间波动明显，而自身负载没有变化，那么变量就在宿主上。此时再结合前三个观察点，就能大致定位到是 CPU 侧、内存侧还是 IO 侧。需要强调的是，基线是用来比较的，不是用来做横向跑分宣称的——不同平台的实现差异客观存在，跨平台比对数字意义有限，同一平台内的纵向比较才有价值。

采购前必须问清的五件事

第一件：vCPU 是否独占物理核。要问的不是"是不是独享实例"这种笼统说法，而是这个规格的 vCPU 与宿主物理核之间有没有绑定或独占关系。如果答案是绑定，那么执行资源的确定性较高；如果没有绑定，就要接着问第二个问题。

第二件：vCPU 与物理线程的比例关系。也就是这个规格在宿主上是怎么排布的，一个物理线程上可能同时承载几个 vCPU。这个问题直接对应超量分配的强度。比例越高，宿主繁忙时排队等待的概率越大。对方未必愿意给出精确比例，但至少要问到"是否存在超量分配、大致的分配策略是什么"这一层。

第三件：内存是否超分，以及超分之后的回收策略。要问清内存是预留还是超分；如果是超分，压力上来时用的是气球回收还是换出到磁盘，触发条件是什么。对于工作集要求常驻的负载，这一条的重要性甚至高于核数，因为换页带来的延迟变化是数量级的，而不是百分比级别的。

第四件：存储是本地盘还是共享后端，IO 上限怎么定。要问清 IOPS 与吞吐的上限是实例级还是更高层级共享，超上限之后是被限流还是排队，以及这个上限是否随容量变化。同时确认换页发生时走的是哪条存储路径——如果换页也落在同一条共享链路上，内存压力与 IO 压力会相互放大。

第五件：网络出口的持续能力与突发能力分别是多少。要分开问，并要求说明突发的计量方式与回落规则。对于需要长时间占满带宽的任务，持续值才是有效值；对于偶发的短时峰值，突发值才有意义。把这两个值都写进配置清单，才能避免上线后发现"测的时候很快、跑起来很慢"。这五条问完之后，配置单上那两个数字才有可比性。

本文只讨论配置背后的分配机制与判断方法，不评价具体厂商也不涉及具体报价

需要先把边界说清楚：上面这张表讲的是变量关系与排查方向，不是对任何厂商产品的评价，也不涉及任何报价与费用测算。不同平台在虚拟化层的实现差异客观存在——同样的"超量分配"四个字，在实现上可能是完全不同的调度策略、不同的回收触发条件、不同的 IO 计量口径；同一家平台在不同规格族、不同代次之间也可能采用不同的做法。因此表中给出的每一条，用途是告诉你"该去量哪些变量"，而不是替你填数字。

同理，本文没有给出任何跑分数据、延迟具体数值或百分比，也不做跨平台的性能排序。原因很简单：这类数字高度依赖测试方法与当时宿主的负载状态，换一个时段、换一批邻居就可能完全不同，把它写成结论反而会误导选型。真正可靠的数字只有一种来源——在自己的环境里、用自己的负载、按上面那四个观察点测出来的那一份。

上线之后怎么持续观察

基线不是测一次就结束的事。建议在业务上线初期建立一份基线档案：记录测试所用的数据规模、并发设置、测试时段、以及四个观察点的结果。之后按固定节奏复测，把每次结果与首份基线对照。这样做的价值在于，当某天业务反馈"变慢了"，你手上有参照物，可以立刻判断是自身负载变化还是环境变化——如果自身输入没变而结果变了，排查方向直接指向宿主。

日常监控的指标选择也要跟着调整。只盯 CPU 使用率与内存使用率是不够的，这两个指标回答不了"资源有没有真正给到你"。更值得纳入的是四类：处理器等待与被偷取时间、内存回收与换页事件、IO 延迟的分布（至少看中位数与高分位）、以及关键任务的端到端耗时。前三类定位层级，第四类给出业务侧可感知的结果，两者对齐才能确认因果。

还有一条实操经验：给关键任务留一个固定的短测试。它不必复杂，可以是一段固定输入的处理脚本、一组固定查询，每天在低峰时段跑一次并记录耗时与四类指标。这个短测试的作用相当于一个探针——它把"环境是否稳定"这个抽象问题，变成一条可以看趋势的曲线。当曲线出现台阶式变化，而业务代码与数据量都没有对应变更时，就该去和服务商核对宿主层面的情况了。

关于 vCPU、内存回收与宿主争抢的七个具体问题

标称核数一样，为什么性能还是不同？因为核数只是"给了你几个调度实体"，它不说明这些实体背后的物理来源、是否存在超量分配、以及是否被配额限制。同样是四个 vCPU，一份可能独占四个物理核的执行能力，另一份可能是从逻辑处理器上切出来的时间片，还要和邻居的负载排队。此外，宿主当时的繁忙程度也会改变结果，所以同一规格在不同时段测出不同耗时是正常现象。要判断属于哪一种，就得看处理器等待与被偷取时间的分布。

什么叫"CPU 被节流"，怎么判断是不是它？节流指的是平台按"每周期可用的 CPU 时间"给 vCPU 设上限，用满后被暂停调度到下一个周期。它的典型表现是：实例内部看到的 CPU 使用率远没有打满，进程却没有拿到预期的执行时间，响应已经开始变慢。判断方法是把这个现象与宿主繁忙程度解耦——如果你在低峰时段、自身低负载时依然观察到同样的"用不满却变慢"，那更可能是配额在起作用，而不是邻居争抢。确认之后的处理方式是调规格或换成不设这类上限的规格。

内存超分一定有害吗？不一定。超分本身是虚拟化层的常规做法，对多数负载来说几乎没有可感知影响——因为多数实例并不会把申请到的内存真正写满，宿主上的实际压力远小于承诺总量。有害的是两种叠加情况：一是你的工作集本来就接近标称内存且要求常驻，二是宿主整体压力上来触发了气球回收或页面换出。前者让你的负载成为被回收的对象，后者让回收真的发生。所以对低水位负载不必为超分额外付费，对工作集接近上限的负载则必须把回收策略问清楚。

跑一次基准能不能说明问题？不能。一次测试的结果里混着太多偶然因素：当时宿主的邻居负载、存储后端的状态、网络出口的突发余量，都可能让这一次偏快或偏慢。可靠的做法是在短窗口内重复多次取中位数，用中位数抵抗偶发干扰；然后再跨日期、跨时段重复，用结果的一致性判断环境是否稳定。单次结果唯一能说明的，是"这一刻大概如此"，它不能作为选型依据，更不能横向推广到别的平台。

什么情况下值得选独占核或裸金属？有三类情况值得考虑。第一是对延迟稳定性要求高，尤其是在线接口这类关注尾部分布而不是平均值的场景，因为共享带来的主要是抖动而不是平均能力的损失。第二是 CPU 长期打满，比如常态化的批处理与转码，此时超量分配带来的等待会持续反映到总耗时上，独占的经济性反而更好。第三是需要稳定的 IO 延迟分布，比如对落盘延迟敏感的数据库类负载。反过来，负载长期处于低水位、且对偶发抖动不敏感的场景，共享规格的性价比通常更高。

共享宿主的邻居影响怎么量化？严格量化邻居的绝对影响很难，因为你无法观测到邻居本身。可操作的是相对量化：固定住自身负载的所有变量——同样的数据、同样的并发、同样的测试脚本——在不同日期与时段重复执行，比较结果的离散程度。离散程度本身就是邻居影响的代理指标：结果越稳定，说明你受到的挤占越小；结果波动越大，说明宿主上的负载起伏越明显。再结合处理器等待与 IO 等待的指标，可以进一步判断挤占主要发生在 CPU 侧还是 IO 侧。

采购前最该向服务商确认哪几件事？五件：vCPU 是否独占物理核；vCPU 与物理线程的比例关系或者说超量分配策略；内存是否超分以及回收与换出的触发条件；存储是本地盘还是共享后端、IO 上限如何计量；网络出口的持续能力与突发能力分别是多少。这五条覆盖了三个层级里最容易造成"配置单一样、表现不一样"的变量。问的时候要具体，避免接受"独享""高性能"这类无法验证的说法，最好能落到可观测的指标或书面说明上。

宿主之外，还有哪些影响实际性能的因素本文没有展开

本文的落点是虚拟化层的分配机制与判断方法，因此宿主之外的因素只列出边界。规格族与代次差异是第一条：同一平台的不同规格族可能采用不同的宿主配比与不同的处理器代次，跨族比较核数的意义有限。NUMA 与绑核是第二条，本文只一句带过——对于工作集大、跨节点访问频繁的内存密集负载，处理器与内存的拓扑关系会带来额外影响，需要单独讨论。

虚拟化层自身的实现类型是第三条：不同的虚拟化技术在调度粒度、设备模拟方式、IO 路径长度上存在差异，这会影响同样规格下的表现，但这类信息通常不会完整公开，只能以服务商说明为参考。第四条是监控的采样精度，采样间隔过粗会把短突发完全漏掉，导致你看到的曲线比真实情况平滑得多。第五条是应用自身：连接池上限、垃圾回收策略、锁竞争这些都与宿主无关，却常常被误判为"机器不行"，排查时应先排除这一层。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。在比选服务器租用时，可把 vCPU 分配、内存回收与共享宿主这三项并入配置清单一起问清。

回到配置单：把三笔账写进采购前的问询清单

回到开篇那个冲突：两台参数一样的机器，同一套任务差了一倍时间。现在可以给出完整的解释——差额不在参数表上，而在参数表背后的三笔账里。第一笔是 vCPU 的物理来源与调度配额，它决定你的算力是"完整的一块"还是"被切分的时间片"，也决定你是否会在自己没跑满时就被暂停。第二笔是内存是否被超分、以及压力上来时是回收还是换出，它决定内存密集负载会不会在某些时刻突然跳升延迟。第三笔是共享宿主上的 CPU 与 IO 争抢，它决定同一套任务在不同时段会不会跑出不同结果。

这三笔账没有一个写在配置单上，但它们共同决定了配置单上的数字能兑现多少。因此采购阶段真正要做的，不是反复比较核数与内存这两个数字，而是把五件事问清楚并落到书面：vCPU 是否独占物理核、vCPU 与物理线程的比例、内存是否超分及回收策略、存储后端与 IO 上限、网络出口的持续与突发。上线之后，再用与生产同构的负载做短窗口基线，盯住处理器等待与偷取、内存回收与换页、IO 延迟分布、以及跨时段的重复性这四个点。

把这两步做完，"这台机器行不行"就不再是一个靠运气回答的问题。不同平台的实现差异客观存在，本文给出的只是变量关系与判断方向，任何具体阈值都应以服务商的书面说明与自身验证结果为准；涉及机型、带宽与费用，需实时询价或以官网实时报价、咨询确认为准。把三笔账写进问询清单，下次再遇到两份看起来一样的配置单时，你问的就是机制，而不只是数字。