---
title: "资源限制"
description: "理解每副本的 CPU、内存预留与上限，以及它们对调度和更新的影响。"
---

> Documentation Index
> Fetch the complete documentation index at: https://cdelivery.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 资源限制

资源设置按每个副本生效。创建或编辑应用时，在资源设置中分别配置预留与限制；修改需要 Operator 或 Admin。

## 预留和限制

| 设置 | 作用 |
| --- | --- |
| CPU 预留 | 调度时为副本考虑的 CPU 容量 |
| 内存预留 | 调度时为副本考虑的内存容量 |
| CPU 限制 | 限制运行时可使用的 CPU 份额 |
| 内存限制 | 限制运行时可使用的内存，超出可能导致进程被终止 |

预留不是资源使用量的预测值，也不等同于运行时上限。限制过小会造成节流或内存不足；预留过大会让副本找不到满足条件的服务器。

CPU 单位为核，例如 `0.5` 表示半个 CPU 核的容量。界面支持从 `0.001` 到 `10000`，精度为 `0.001`。内存按界面所选 MiB 或 GiB 填写，注意不要把字节与 MiB 混用。

## 配置示例

一个有两个副本的 Web 应用，可以从以下值开始测量：

| 项目 | 每个副本 |
| --- | --- |
| CPU 预留 | 0.5 |
| CPU 限制 | 1 |
| 内存预留 | 256 MiB |
| 内存限制 | 512 MiB |

两个副本合计需要考虑 1 核 CPU 和 512 MiB 内存预留；平台本身和其他应用还需要额外容量。这是说明计算方式的示例，不是适用于所有业务的推荐配置。

保存后查看[应用指标](/docs/zh-cn/guides/observability/metrics/application/)，根据正常负载及峰值修正配置。预留不应高于对应限制。

## 更新和扩容需要额外空间

使用先启动新副本的更新策略时，新旧副本会暂时重叠，服务器需要容纳额外预留。自动扩容同样受资源、标签和每台服务器副本上限约束。

CPU 限制也影响自动扩缩容对负载的解释。未设置 CPU 限制时，不能按单核百分比理解所有副本的负载；详见[副本与自动扩缩容](/docs/zh-cn/guides/apps/scaling/)。

## 调整后的验证

1. 确认新副本能够完成调度。
2. 在代表性业务负载下观察 CPU、内存和请求延迟。
3. 对照应用日志检查是否发生内存不足、进程退出或重启。
4. 检查同服务器其他应用是否仍有足够资源。

如果更新卡住，先检查额外副本容量，再检查标签和每台服务器的副本限制。不要仅提高期望副本数而忽略服务器容量。

运行时资源限制的基础行为可参考 [Docker 资源约束说明](https://docs.docker.com/engine/containers/resource_constraints/)。

Source: https://cdelivery.dev/docs/zh-cn/guides/apps/resources/index.mdx