这件事在什么时候变成问题
系统部署上线后，对资源的持续关注是确保服务稳定性和性能的关键。初期，资源配置可能基于预估负载，但实际运行中，用户行为、业务增长、功能更新等因素会带来不确定性。当系统遇到响应变慢、处理延迟、甚至服务中断时，资源不足往往是核心原因之一。例如，文件解析、HTML转Markdown、文本切块等任务，在并发量高时可能迅速耗尽资源，导致任务排队或失败。沙盒环境的CPU、内存和存储上限，也直接影响代码执行效率和稳定性。此外，数据库连接数的瞬时激增、MongoDB的写冲突，以及Milvus等向量库的数据迁移和版本兼容问题，都可能在不经意间演变为严重的性能瓶颈。
资源瓶颈并非总是显而易见，它可能表现为偶发的超时与间歇性的错误。全面崩溃只是其中一种末期表现。尤其是在系统功能迭代，例如 Agent V2 逻辑重写、插件系统架构调整、引入新的多模态模型支持音视频输入等，都可能改变服务的资源消耗模型。当这些变化与现有资源配置不匹配时，问题便会浮出水面。因此，建立一套主动的、周期性的用量与容量复盘机制，将“够不够用”这一模糊概念转化为可量化、可追踪的指标，是技术与运维团队必须面对的决策挑战。这套机制旨在识别潜在瓶颈，指导资源扩容，避免被动应对问题，从而保障业务的连续性和用户体验。
需要先定下来的判据
| 判据 | 取什么值 | 依据 |
|---|---|---|
| 文件解析 Worker 数量 | Node.js 检测到的可用 CPU 并行度，最少 1 个 | 系统自动设置，考虑容器 CPU 配额和进程亲和性，实际运行受内存调度限制。 |
| HTML 转 Markdown Worker 数量 | 可用 CPU 并行度与 5 中的较小值 | 硬上限，任务启动前检查系统安全预留之外的内存余量。 |
| 文本切块 Worker 数量 | 可用 CPU 并行度与 5 中的较小值 | 硬上限，任务启动前检查系统安全预留之外的内存余量。 |
| 沙盒单实例 CPU 核数上限 | AGENT_SANDBOX_CPU_COUNT 环境变量，默认值 1 | 控制沙盒代码执行的计算资源，影响任务并发和执行速度。 |
| 沙盒单实例内存上限 | AGENT_SANDBOX_MEMORY_MIB 环境变量，默认值 2048 MiB | 控制沙盒代码执行的内存消耗，避免因内存不足导致的崩溃。 |
| 沙盒存储容量 | AGENT_SANDBOX_STORAGE_SIZE_GI 环境变量，默认值 1 Gi | 影响沙盒持久化数据量，尤其是 Kubernetes 模式下 PVC 的创建。 |
| 沙盒未活跃暂停时间 | AGENT_SANDBOX_SUSPEND_MINUTES 环境变量，默认值 60 分钟 | 控制资源释放策略，平衡资源利用率和用户体验。 |
这些判据之间存在相互影响和取舍关系。例如，文件解析、HTML转Markdown和文本切块Worker的数量，系统会根据可用的CPU并行度自动设置硬上限，但实际同时运行的任务数还会受到文件解析内存调度的限制。这意味着即使CPU资源充足，如果内存预留不足，任务仍会排队等待。HTML转Markdown和文本切块任务在没有内存余量时会排队，最长等待30分钟，这直接影响用户体验。因此，在评估这些Worker的容量时，需要综合考虑CPU和内存两方面的实际使用情况。
沙盒环境的配置变量，如AGENT_SANDBOX_CPU_COUNT和AGENT_SANDBOX_MEMORY_MIB，直接决定了单个沙盒实例的性能边界。提高这些值可以增强沙盒的处理能力，但也会增加整体资源消耗。AGENT_SANDBOX_STORAGE_SIZE_GI则影响了沙盒可以存储的数据量，对于需要处理大量文件的场景至关重要。AGENT_SANDBOX_SUSPEND_MINUTES和AGENT_SANDBOX_ARCHIVE_INACTIVE_DAYS等策略，则是在资源利用率和用户体验之间进行权衡。较短的暂停时间可以更快释放资源，但可能导致用户频繁遇到沙盒启动延迟。理解这些判据的内在联系和外部影响，是进行容量规划和扩容决策的基础。扩容前，需要对照这些判据的实际值和预期值，判断瓶颈具体出现在哪一层，是计算资源、内存、存储，还是调度策略本身。
具体怎么做
用量与容量复盘的核心在于周期性地收集、分析关键指标，并根据分析结果调整资源配置。这一过程需要从系统多个层面入手，包括核心服务、Worker池、沙盒环境以及数据库等。
首先是核心服务的资源监控。对于fastgpt-app和fastgpt-pro这类主服务，需要持续关注其CPU、内存使用率。当CPU利用率长时间处于高位（例如超过80%）或内存使用接近上限时，表明主服务可能成为瓶颈。同时，监控请求的响应时间，特别是长尾请求的延迟，可以帮助判断服务是否过载。在v4.15.0版本中，增加了文件解析、HTML转Markdown和文本切块的Worker池，避免了并发过高导致资源耗尽。v4.16.2版本进一步优化了文件解析Worker的硬上限设置，根据Node.js检测到的可用CPU并行度自动调整，并考虑容器CPU配额和进程亲和性，最少保留1个Worker。实际同时运行的任务数还会受到文件解析内存调度限制。HTML转Markdown和文本切块Worker的硬上限为可用CPU并行度与5中的较小值。任务启动前会检查系统安全预留之外是否还有可调度内存；没有余量时继续排队，任务完成后会立即重试一次，仍不足时每30秒检查一次，最长等待30分钟。空闲Worker超过60秒后会自动回收，最多长时间保留1个。这意味着需要监控CPU并行度、内存可用量以及任务队列长度和等待时间，以判断Worker池是否需要扩容。
其次是沙盒环境的容量管理。沙盒（fastgpt-sandbox）在v4.16.0版本引入了多项可配置的环境变量，直接影响其资源消耗。AGENT_SANDBOX_CPU_COUNT（默认1）、AGENT_SANDBOX_MEMORY_MIB（默认2048 MiB）和AGENT_SANDBOX_STORAGE_SIZE_GI（默认1 Gi）是核心参数。需要监控沙盒实例的CPU和内存使用情况。如果沙盒任务频繁因资源不足而失败，或者执行时间过长，则应考虑调整这些参数。此外，AGENT_SANDBOX_SUSPEND_MINUTES（默认60分钟）和AGENT_SANDBOX_ARCHIVE_INACTIVE_DAYS（默认7天）控制着沙盒实例的生命周期，影响资源的释放与重用。如果用户反馈沙盒启动慢，可能是因为实例被频繁暂停和归档，需要调整这些时间参数以保持更多活跃实例。沙盒的SANDBOX_MAX_TIMEOUT（默认60000毫秒）、SANDBOX_MAX_MEMORY_MB（默认256MB）、SANDBOX_POOL_SIZE（默认20）等安全相关环境变量也需要根据实际负载进行调整，确保沙盒既能满足业务需求，又能保证系统安全。例如，当代码执行输出JSON大小上限SANDBOX_MAX_OUTPUT_MB（默认10MB）不足时，可能导致任务失败，需要适当调大。
最后是数据库和存储层的复盘。MongoDB作为核心数据存储，其连接数、读写延迟、以及可能的写冲突（如社区反馈的WriteConflict问题）都需要重点关注。当出现WriteConflict错误时，可能需要优化MongoDB的部署配置，例如确保复制集正常运行，或者调整事务处理逻辑。Milvus作为向量库，其版本兼容性至关重要。v4.16.2版本要求Milvus升级到2.5.16或更高版本，并自动切换到Milvus BM25全文检索。如果Milvus版本过低或BM25能力校验失败，FastGPT会终止启动。因此，在升级前，必须确认Milvus版本满足要求，并监控其资源使用，包括存储空间和查询性能。S3等对象存储的用量也应纳入复盘范围，特别是文件上传下载的带宽和延迟。v4.15.0增加了S3支持配置CDN，可以优化文件访问性能。对于存储在S3上的文件，需要监控其增长趋势，评估存储成本和容量需求。
综合以上，复盘工作需要融入日常运维流程。这是一项持续性任务。通过持续监控、定期分析和适时调整，确保系统资源始终与业务需求保持匹配。
怎么验收
- 核心服务资源使用率检查：核对
fastgpt-app和fastgpt-pro服务在峰值负载下的CPU和内存平均利用率。通过标准：CPU利用率低于80%，内存利用率低于85%。 - Worker池任务处理效率验证：检查文件解析、HTML转Markdown、文本切块等Worker池的任务队列长度和平均等待时间。通过标准：任务队列长度在正常范围内波动，平均等待时间低于设定的业务阈值。
- 沙盒环境性能指标评估：监控沙盒实例的CPU、内存使用情况，以及沙盒任务的成功率和平均执行时间。通过标准：沙盒CPU和内存利用率在设定上限内，任务成功率高于设定值，平均执行时间满足业务要求。
- 数据库连接与性能测试：审查MongoDB和Milvus的连接数、读写延迟、以及是否存在
WriteConflict等异常日志。通过标准：数据库连接数在配置范围内，读写延迟低于设定阈值，无频繁的WriteConflict错误。 - 存储系统容量与访问性能核实：检查S3等对象存储的实际用量与可用容量，并测试文件上传下载的平均响应时间。通过标准：存储容量充足，文件上传下载响应时间满足业务需求。
- 环境变量配置一致性确认：核对所有服务（
fastgpt-app,fastgpt-pro,fastgpt-plugin,fastgpt-code-sandbox,fastgpt-agent-sandbox-proxy等）的环境变量配置，特别是涉及资源限制和地址的参数。通过标准：所有相关环境变量配置正确且保持一致，无遗漏或错误配置。 - 系统升级后功能兼容性验证：在完成任何升级（如v4.16.2对Milvus版本的要求）后，执行核心业务流程，验证功能是否正常运行，特别是涉及新旧组件交互的部分。通过标准：所有核心功能正常，无兼容性问题。
- 复盘报告与行动计划审阅：定期生成用量与容量复盘报告，并根据报告内容制定明确的扩容、优化或调整计划。通过标准：报告完整反映系统资源状况，并有可执行的行动计划。
边界：什么情况下这套做法不成立
这套基于周期性用量与容量复盘的做法，依赖于几个关键的外部条件和假设，如果这些条件不成立，其有效性将受到限制。
首先，监控数据的完整性和准确性是基础。如果监控系统无法全面、准确地收集到CPU、内存、网络I/O、磁盘I/O、数据库连接数、Worker任务队列等关键指标，或者数据存在延迟、丢失，那么复盘分析的结果将是片面的，甚至具有误导性。例如，如果无法准确获取沙盒实例的资源使用情况，对AGENT_SANDBOX_CPU_COUNT或AGENT_SANDBOX_MEMORY_MIB的调整就缺乏数据支撑。
其次，业务负载模式的相对可预测性是重要前提。这套方法适用于业务量呈现一定周期性、趋势性增长的场景。如果业务负载存在高度不可预测的突发性峰值，或者变化模式极其复杂，那么基于历史数据和周期性复盘可能难以提前捕捉到瓶颈。例如，如果因营销活动或外部事件导致短时间内用户量激增，远超平时峰值，常规的复盘可能无法及时发现并指导扩容，从而导致服务中断。
再者，系统架构的弹性与可伸缩性也影响这套方法的有效性。如果系统架构本身缺乏弹性，扩容操作复杂、耗时，或者存在单点瓶颈无法通过简单资源增加来解决，那么即使复盘准确识别了问题，也无法快速有效地进行容量调整。例如，如果数据库的扩展性受限于其部署模式，或者某些核心组件无法水平扩展，那么即使发现数据库连接数不足，也难以通过简单的扩容解决。
此外，这套方法无法完全预测和应对软件版本升级带来的潜在性能回归或新瓶颈。每次版本升级（例如v4.15.0或v4.16.2），都可能引入新的功能（如多模态模型支持音视频输入、Agent V2逻辑重写），或对现有组件进行优化（如PDF解析替换为liteparse），这些变化可能彻底改变服务的资源消耗模型。复盘只能在升级后通过观察实际用量来发现问题，而不能预先精确评估。例如，Milvus版本升级到2.5.16或更高版本，并自动切换到BM25全文检索，如果旧向量数据迁移出现问题，可能导致FastGPT终止启动，这类问题需要额外的兼容性测试和迁移方案来保障。
最后，外部依赖服务的稳定性与容量也超出了这套方法的直接控制范围。如果系统依赖的第三方服务（如LLM服务、对象存储服务）出现性能问题或容量限制，即使自身服务资源充足，也可能导致整体服务质量下降。这套复盘主要关注自身系统的用量与容量，对于外部依赖的瓶颈，需要通过与外部服务提供商的沟通和监控来解决。
继续阅读
参考资料
需要进一步确认时
上述判据与验收项可依据公开文档逐条核对。若需要结合具体部署环境与运维条件落地这套流程，可通过商务咨询获取支持；云服务形态可直接开始使用。
- 商务咨询：结合部署环境落地这套流程
- 立即开始：先用云服务验证流程可行性
- 定价：对比不同形态的适用范围