128核256线程双路EPYC 7713香港服务器，容器集群资源如何按负载规划？

业务从每秒几百次请求增长到几千次请求，服务器是否够用，取决于增长的是轻量查询、复杂计算，还是需要读取大量数据的接口。对128核256线程的双路EPYC 7713香港服务器，容器集群资源不能按“有多少线程就分多少容器”规划，而应把请求量、单次资源消耗、常驻数据、峰值持续时间和增长率转换为CPU、内存、存储及网络需求，再找出最先达到边界的资源。

这类配置适合承载可并行的API服务、后台任务、多业务容器和一定规模的数据处理负载，但128个物理核不等于256个物理核，双路服务器也不等于两个独立故障域。规划时既要利用多核资源，又要为操作系统、容器平台、流量突增和业务扩展留出空间；香港部署还需单独核对带宽、目标访问地区的链路和上下游时延，不能仅凭CPU规格判断整机承载量。

一、先把业务负载拆成可计算的画像

请求量、并发量与响应时间分别回答什么问题

请求量描述单位时间内需要处理多少工作，通常以QPS或RPS表示；并发量描述某一时刻有多少请求正在处理或等待；响应时间决定这些请求占用资源多久。三者相关，但不能相互替代。

在系统相对稳定、统计口径一致时，可以用以下关系估算平均在途请求数：

平均在途请求数 ≈ 每秒请求数 × 平均响应时间（秒）。

例如，一个接口每秒接收8000次请求，平均响应时间为0.08秒，则平均在途请求数约为640。这里的640不是TCP连接数，也不是必须启动640个工作进程；异步服务可能用较少线程管理大量在途请求，阻塞式服务则更容易先耗尽线程池。

容量评估应同时记录平均值与P95、P99延迟。平均延迟适合建立基础关系，尾部延迟则用于判断排队和服务目标是否开始失守，不能直接把P99代入上述公式，称为平均并发。

按请求类型拆分，而不是只保留一个总QPS

相同QPS对应的资源需求可能差异很大。建议至少将业务拆成以下几类：

CPU需求可按各类请求分别计算后相加。内存、磁盘和网络还要区分共享部分与独占部分，不能把所有容器的平均占用简单乘以副本数。

增长变量也应拆开：请求量增长不一定带来同等比例的内存增长，数据量增长却可能降低缓存命中率，进一步放大数据库和磁盘压力。每月请求增长10%、数据增长20%的业务，应分别预测，而不是统一套用一个增长率。

峰值需要附带持续时间

持续30秒的活动突发，与每天持续两小时的业务高峰，不能使用同一种余量策略。前者可能通过有限排队、缓存和预留副本吸收，后者应按持续容量规划。

后台任务还要补充完成期限。任务允许在夜间处理，和必须在五分钟内完成，对CPU预算的要求明显不同。队列只能改变处理时间分布，不能消除最终需要完成的计算量。

二、把负载转换成这台服务器的资源预算

CPU：以128个物理核建立保守基线，再验证SMT收益

单颗EPYC 7713为64核128线程，双路合计128核256线程。启用SMT且系统完整识别时，操作系统通常呈现256个逻辑CPU，但两个同属一个物理核的逻辑线程共享部分执行资源。

256个逻辑CPU代表可调度的线程位置，不代表业务性能必然达到128个物理核的两倍。

对于混合容器负载，可先以128个物理核建立保守容量模型，再通过目标业务压测确认SMT收益。计算密集型任务、内存带宽敏感任务和等待较多的服务，获得的收益并不相同。

基础估算关系是：

业务CPU需求 ≈ 请求速率 × 单请求CPU成本 + 后台任务CPU需求。

这里必须统一计量口径。若单请求成本采用物理核基线测试得到的“核秒”，结果就是物理核等效需求；若使用容器监控中的CPU seconds/s，通常反映逻辑CPU调度时间，应结合相同线程拓扑和负载条件校准，不能直接当作独占物理核数量。

业务可用CPU还要扣除系统与平台预算：

业务CPU预算 = 物理核等效总量 − 系统及平台预留。

随后再乘以目标利用率，得到正常峰值允许使用的范围。延迟敏感服务不宜长期贴近满载，因为CPU排队、上下文切换和内核处理都可能推高尾延迟。

内存：按工作集和峰值规划，不按平均值填满

标题给出了CPU规格，并未限定内存配置。容量推演前应核对实际交付的内存容量、条数、插槽分布以及双路之间的配置是否均衡，不能从128核推导出固定内存容量。

内存需求至少包括：

• 应用常驻堆、运行时和连接状态。
• 缓存、数据库热数据、索引与缓冲区。
• 批处理、中间结果和请求突发形成的瞬时占用。
• 容器平台、监控、日志代理及操作系统开销。

可使用以下关系整理预算：

整机内存需求 = 平台保留 + 常驻业务工作集 + 峰值增量 + 安全余量。

对于垃圾回收型应用，容器内存限制不能只覆盖应用堆，还应包含线程栈、直接内存、运行时和其他实际计入容器的内存。数据库与文件服务则需要结合页缓存和业务延迟判断，不能将所有缓存占用都视为可随意回收的空闲空间。

存储：容量与性能分别计算

存储容量首先由数据增长和保留策略决定：

原始保留量 = 每日新增数据 × 保留天数。

再加入副本、索引、日志、快照及临时空间。以每日新增20GB、保留30天、存储放大系数2为例，基础占用为：

20 × 30 × 2 = 1200GB。

如果另预留25%的临时与维护空间，并要求正常占用不超过规划可用空间的70%，则所需可用容量约为：

1200 × 1.25 ÷ 0.70 ≈ 2143GB，即约2.14TB。

这里GB、TB采用十进制口径，1TB = 1000GB。放大系数需由实际数据结构确定；若已包含某类索引或副本，就不能再次重复计入。同机多副本也不能替代独立节点或外部备份。

容量够用不代表性能够用。数据库随机读写应关注IOPS与延迟，日志和批量处理应关注吞吐，备份及镜像拉取还可能与业务争用磁盘。同一块盘混放多个容器的数据，必须验证混合负载下的表现，而不是只看单任务顺序读写速度。

香港网络：按应用方向核对带宽与链路

香港服务器的网络规划应区分网卡端口速率、合同带宽、共享或独享方式，以及业务实际可用吞吐。这些数值不是同一个概念，CPU配置也不能推导出网络配置。

对以响应流量为主的接口，可先计算应用层出站需求：

出站速率（Mbps）≈ 每秒请求数 × 平均响应字节数 × 8 ÷ 1,000,000。

例如8000次请求/秒，平均响应为12KB，采用1KB = 1000字节的十进制口径：

8000 × 12,000 = 96,000,000字节/秒，即96MB/s；再乘8，得到约768Mbps。

这还未计入协议开销、重传、备份和其他业务流量。若可用带宽只有100Mbps，CPU即使很空闲，也无法持续输出这一规模的响应。若端口标称1Gbps，也应继续核对实际带宽保障与高峰表现。

此外，应从目标访问地区测量时延、丢包和吞吐。服务频繁访问异地数据库时，跨地区往返可能比计算更早成为瓶颈；增加EPYC核心数无法缩短这部分网络等待。

三、判断瓶颈时，要看排队发生在哪里

CPU利用率不高，也可能已经到达业务上限

整机CPU平均利用率较低，不代表所有服务都有余量。常见情况包括单个热点线程饱和、容器CPU配额过小、线程池或连接池耗尽，以及共享锁限制并行度。

双路服务器还应检查NUMA局部性。内存分布不均衡、任务集中在一个CPU插槽，或大量跨NUMA访问，都可能使另一部分核心无法有效分担负载。对大工作集、低延迟服务，增加容器副本前，应先验证任务与内存的分布。

建议把下列指标成组观察：

关键不是出现某一个高数值，而是业务指标恶化与资源压力是否同步发生。高CPU但延迟达标、吞吐稳定，不一定需要立即扩容；CPU只有40%却已经违反响应时间目标，也不能认定容量充足。

Kubernetes的requests与limits不是承载量保证

Kubernetes通常以逻辑CPU作为CPU资源计量基础，1 CPU在这一裸金属场景下通常对应一个可调度逻辑CPU的时间份额，不等同于独占一个物理核。

CPU requests影响调度与竞争时的份额，CPU limits限制可使用的CPU时间。内存requests用于调度预算，内存limits则构成运行时边界，达到限制可能触发OOM。requests总量能被调度，并不说明所有Pod同时进入峰值后仍能满足业务目标。

因此应将两个预算分开：

• 调度预算：基于Node Allocatable与各Pod的requests，判断是否可以放置。
• 业务容量预算：基于真实负载下的吞吐、延迟和资源争用，判断放置后是否可用。

CPU可以在受控条件下利用不同业务峰值错开进行超分，但必须验证同时突发时的结果。内存不能用同样方式乐观处理，尤其是有状态服务和峰值较大的任务。

四、用一组容量推演找出真正的增长空间

以下示例用于演示方法，不代表某台服务器的实测承载保证。内存、网络与业务成本均为示例条件，采购时应以实际交付配置及目标应用验证。

CPU允许多少请求增长

业务包含API和后台任务。API峰值为8000请求/秒，在同口径物理核基线下，每请求CPU成本为6毫秒核时间；后台任务需要8个物理核等效预算。

API需求为：

8000 × 0.006 = 48个物理核等效。

合计需求为48 + 8 = 56个物理核等效。正常峰值CPU预算为：

（128 − 8）× 65% = 78个物理核等效。

如果后台任务需求不变、请求类型及单次CPU成本稳定，API理论规划上限约为：

（78 − 8）÷ 0.006 ≈ 11667请求/秒。

相对8000请求/秒，CPU侧约有46%的请求增长空间。该结果不包含业务复杂度变化、缓存命中率下降或并行效率变化，需要用压测校准。

内存可能比CPU更早达到规划边界

业务可用于正常峰值的内存预算为：

（512 − 48）× 80% = 371.2GiB。

将业务峰值占用拆成两部分：

当前低于371.2GiB规划边界，但只剩35.2GiB余量。

如果API与任务部分共216GiB随负载近似线性增长，缓存及其他组件共120GiB保持不变，则可支持的增长比例约为：

（371.2 − 120）÷ 216 − 1 ≈ 16%。

也就是说，在这些条件下，内存允许的增长约为16%，明显小于CPU侧的46%。实际内存若主要由固定堆构成，增长关系可能并不线性；若缓存也随数据增长，边界又会提前，应重新拟合。

网络需要同步校验，不能在算完CPU后补看

8000请求/秒、平均12KB响应，对应约768Mbps应用层出站流量。在2Gbps示例可用带宽、70%规划目标下，预算为1400Mbps。

请求增长25%后，出站需求约为960Mbps，仍低于该目标，但需要继续计入协议开销和其他流量。如果实际只有1Gbps可用带宽，其70%规划目标为700Mbps，当前768Mbps就已超过目标，网络会先于内存成为需要调整的资源。

因此，这组业务的增长空间应取各资源可支持增长量中的较小值，而不是使用CPU剩余比例。在示例2Gbps条件下，优先关注内存；带宽条件改变后，优先级也会改变。

五、容量余量要对应故障范围和采购变量

同机容器集群提供的是隔离，不是整机容灾

在一台双路服务器上部署多个容器，能够划分资源和业务边界，但所有容器仍共享主机、电源、存储及网络故障域。将同一台机器切成多个虚拟节点，也不会增加独立物理故障域。

若业务要求一台物理服务器故障后仍继续服务，应使用多台服务器，并按故障后的剩余容量规划：

故障后剩余节点的可用业务预算，应覆盖故障时需要保留的峰值负载。

副本也需要分散到独立节点。单机内部预留20%资源主要用于突发、发布和维护，不能称为节点故障接管容量。

什么时候适合选这类高核心数配置

双路EPYC 7713的价值在于容纳较多可并行工作。如果多个服务能横向增加副本、后台任务能拆分，并且内存、存储与网络配套充足，高核心数可以提高单机业务密度。

以下情况则不宜仅靠增加核心数解决：

• 主要接口被单线程、串行锁或低并行度程序限制。
• 热数据已经超过内存规划边界。
• 数据库随机IO延迟过高，新增应用副本只会增加存储压力。
• 香港到主要用户或上游服务的链路不满足时延目标。
• 业务要求跨物理节点接管，而方案只有一台服务器。

成本也应按完整配置比较，而不是只比较CPU型号。内存扩展、存储可用容量与性能、带宽保障、备份空间、独立节点及管理方式都会影响实际成本。核对候选方案时，应比较相同负载目标和故障要求下的整体配置。

交付验收至少应确认：CPU与线程拓扑、内存容量及双路分布、磁盘与RAID后的可用容量、网卡端口与合同带宽、虚拟化或容器平台资源限制，以及代表性混合负载下的延迟和吞吐。任何一项变化，都可能改变前面的容量结果。

围绕这类高并发、多容器和后台任务场景，A5数据提供香港AMD EPYC物理服务器租用，覆盖EPYC 7713等单路、双路平台，并配套不同内存、SSD或NVMe存储及CN2、国际带宽资源。香港服务器产品还覆盖建站、数据库、接口服务和多任务计算等用途，支持将计算、存储与网络资源组合到同一部署方案中。

六、用业务退化点确定监控与扩容阈值

从逐级加压结果反推阈值

阈值不应直接照搬“CPU到80%就扩容”。更有效的方法是逐级提升代表性负载，同时观察吞吐、P95/P99、错误率、任务积压与资源指标。

1. 固定请求类型比例、数据规模和缓存条件，建立当前负载基线。
2. 逐级增加负载，每一级保持足够时间，让GC、缓存、写入和队列行为显现。
3. 找出吞吐增速下降、尾延迟明显上升或错误率超标的区间。
4. 将正常运行目标放在退化点之前，并额外覆盖流量预测误差、发布期间双份副本和故障接管需求。
5. 单独验证突发峰值与持续峰值，避免把短时可承受量当作长期容量。

压测若只覆盖缓存命中请求，不能用于估算大量未命中时的容量；只运行API，也不能代表API、数据库、日志和后台任务同时繁忙时的整机能力。

扩容触发条件要同时包含持续时间与提前量

可以将监控分成预警和执行两层：预警提示容量趋势接近规划边界，执行条件则对应服务目标开始恶化，或预测会在交付完成前耗尽余量。

作为起点，CPU可观察持续负载、热点核心与限流；内存可观察峰值工作集、回收压力及OOM；存储可观察可用空间、写入延迟和临时空间；网络可观察方向性吞吐、丢包与重传；任务系统则观察到达速率是否持续高于完成速率。这些指标必须与业务延迟、错误率和完成期限一起判断。

例如，当前受内存约束的增长空间约为16%，而对应工作集月增长约10%，在该增长趋势持续的条件下，大约一到两个月就会接近规划边界。如果扩容交付、迁移及验证需要数周，就应提前启动，而不是等到OOM后再处理。

最终应保留一张持续更新的容量表：当前峰值、经验证的规划上限、可增长比例、预计触达时间、对应扩容动作。CPU不足时增加计算节点或调整并行度；内存不足时扩展内存、拆分有状态服务或压缩工作集；存储和网络不足时扩展相应资源。让监控指标指向明确动作，才能把128核256线程的硬件规模转化为可持续的业务容量。