如何用 sandbox_memory_profile 脚本为 AIO 沙箱采集内存基线快照【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow当你要评估或更换 DeerFlow 的沙箱运行时例如在 AIO 与 CubeSandbox、OpenSandbox、gVisor、Kata 等候选后端之间做选择需要先拿到当前 AIO 沙箱在真实负载下的内存基线否则没有可对比的参照物。backend/docs/SANDBOX_MEMORY_PROFILING.md 给出了这套流程的起因Issue #3213 报告单个沙箱在 Kubernetes 上的内存接近 1 GiB在引入新 provider 之前必须先测出当前 AIO 沙箱的基线并用同一份 DeerFlow 负载对比候选后端。scripts/sandbox_memory_profile.py就是为这个目的写的采集脚本它对外只做两件事——shell 调用kubectl然后输出 JSON 或 Markdown 报告不引入额外的运行时依赖见 scripts/sandbox_memory_profile.py。前提条件脚本运行依赖一个可用的 Kubernetes 环境满足以下条件当前kubectl上下文能访问目标集群并有权限执行kubectl top pod、kubectl get pods和kubectl execkubectl top有数据可返回即集群的指标能力可用脚本第一步就是top pod沙箱 Pod 正在运行且命名空间和标签选择器与脚本默认值一致--namespace默认deer-flow--selector默认appdeer-flow-sandbox如果集群里命名空间或标签不同用同名参数覆盖即可不需要改脚本。脚本做了什么采集一次快照时脚本依次执行kubectl top pod -n namespace -l selector --no-headers拿到每个沙箱 Pod 的 CPU 与内存working set读数kubectl get pods -n namespace -l selector -o json拿到 Pod 元数据合并进报告——phase、startTime、labels以及每个容器的 image、resources.requests、resources.limits仅在加--include-processes时对每个 Pod 执行kubectl exec ... -- sh -c ps -eo pid,ppid,rss,args --sort-rss把 RSS 最高的前--process-limit默认 10个进程加入报告。单个 Pod 的exec失败或超时不会中断整体采集错误会记入报告的process_errorsJSON或## Process Sample ErrorsMarkdown其余 Pod 继续正常采样。每条 kubectl 调用的超时时间由--kubectl-timeout控制默认 30 秒。按负载阶段采集快照文档要求至少覆盖以下 7 类采样点每个阶段用一个有辨识度的--sample值区分沙箱 ready 后的空载状态--sample empty执行一条简单 bash 命令之后--sample after-bash跑一个 import 常见包的 Python 任务之后--sample after-python预期有 Node 负载时跑完 Node 任务之后在/mnt/user-data/outputs下生成文件之后--sample after-artifact释放并暖复用warm reuse之后目标并发水位例如 10、50、100 个沙箱。主路径命令在仓库根目录执行python scripts/sandbox_memory_profile.py \ --namespace deer-flow \ --selector appdeer-flow-sandbox \ --sample empty \ --include-processes \ --format markdown文档给出的各阶段 JSON 采集示例python scripts/sandbox_memory_profile.py --sample after-bash --format json python scripts/sandbox_memory_profile.py --sample after-python --format json python scripts/sandbox_memory_profile.py --sample after-artifact --format json--include-processes用于区分 Pod 级 cgroup 内存和进程 RSS 这两个数。它们不会精确相等cgroup 内存可以包含 page cache 等内核记账部分进程 RSS 采样拿不到这些。哪个数字更贴近你想回答的问题决定了你需要哪一路数据。保存原始 JSON。文档明确要求对比后端时保留 raw JSON以便事后审计 totals、Pod 名称、镜像、requests/limits 和时间戳。如何核对报告报告中的summary给出 pod_count、total_memory_mib、average_memory_mib、max_memory_mib、parsed_memory_count/unparsed_memory_count等汇总值Markdown 格式的逐 Pod 表格列为Pod | Phase | CPU | Memory | Start Time加--include-processes后还有## Top Processes段PID / PPID / RSS / Command。核对时关注两点解析失败计数。unparsed_memory_count、unparsed_cpu_count非 0 说明有 Pod 的读数没被解析报告中的总量只覆盖已解析的部分结论要以parsed_memory_count是否覆盖全部目标 Pod 为前提。进程采样错误。pods_with_process_sample_errors非 0 时说明部分 Pod 的kubectl exec被拒绝或超时这类 Pod 没有进程级数据但其kubectl top读数仍在报告里。文档对kubectl top读数本身有一条重要限定它报告的是 Kubernetes/容器 working set 内存应作为容量信号对待不是独占的 RSS/PSS。Pod 级内存包含 Pod 内所有容器还可能包含计入 cgroup 的 cache。某个结果反常时先检查沙箱进程和节点上的 cgroup 指标再下结论。用基线对比候选后端拿到 AIO 基线后对比要在同一份 DeerFlow 负载上进行并按 backend/docs/SANDBOX_MEMORY_PROFILING.md 的候选运行时矩阵记录证据核心项包括维度需要的证据容量Pod/实例数、总内存、平均内存、最大内存启动1、10、50、100 个并发沙箱的 ready 延迟命令bash 输出、超时行为、失败形态文件read_file、write_file、二进制update_file、list_dir、glob、grep上传gateway 上传的文件在沙箱内可见产物写入/mnt/user-data/outputs的文件可被后端 artifact API 读取路径/mnt/user-data/workspace、/mnt/user-data/uploads、/mnt/user-data/outputs、/mnt/acp-workspace及 skills 路径保持预期语义隔离不同用户和线程之间不能互相读数据清理release、idle 超时、进程重启、孤儿清理能释放资源运维部署前置、特权组件、网络、存储、升级路径文档的 PR 指引把基线数据定为了硬性条件在没有用同一份 DeerFlow 负载测过当前 AIO 沙箱和候选后端之前不要声称新 provider 修复了高并发内存问题实验性 provider 的 PR 优先标注Related to #3213除非 PR 本身附带可复现的负载数据证明达到目标内存降幅且 uploads、outputs、artifacts 与隔离行为不回归。【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何用 sandbox_memory_profile 脚本为 AIO 沙箱采集内存基线快照
如何用 sandbox_memory_profile 脚本为 AIO 沙箱采集内存基线快照【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow当你要评估或更换 DeerFlow 的沙箱运行时例如在 AIO 与 CubeSandbox、OpenSandbox、gVisor、Kata 等候选后端之间做选择需要先拿到当前 AIO 沙箱在真实负载下的内存基线否则没有可对比的参照物。backend/docs/SANDBOX_MEMORY_PROFILING.md 给出了这套流程的起因Issue #3213 报告单个沙箱在 Kubernetes 上的内存接近 1 GiB在引入新 provider 之前必须先测出当前 AIO 沙箱的基线并用同一份 DeerFlow 负载对比候选后端。scripts/sandbox_memory_profile.py就是为这个目的写的采集脚本它对外只做两件事——shell 调用kubectl然后输出 JSON 或 Markdown 报告不引入额外的运行时依赖见 scripts/sandbox_memory_profile.py。前提条件脚本运行依赖一个可用的 Kubernetes 环境满足以下条件当前kubectl上下文能访问目标集群并有权限执行kubectl top pod、kubectl get pods和kubectl execkubectl top有数据可返回即集群的指标能力可用脚本第一步就是top pod沙箱 Pod 正在运行且命名空间和标签选择器与脚本默认值一致--namespace默认deer-flow--selector默认appdeer-flow-sandbox如果集群里命名空间或标签不同用同名参数覆盖即可不需要改脚本。脚本做了什么采集一次快照时脚本依次执行kubectl top pod -n namespace -l selector --no-headers拿到每个沙箱 Pod 的 CPU 与内存working set读数kubectl get pods -n namespace -l selector -o json拿到 Pod 元数据合并进报告——phase、startTime、labels以及每个容器的 image、resources.requests、resources.limits仅在加--include-processes时对每个 Pod 执行kubectl exec ... -- sh -c ps -eo pid,ppid,rss,args --sort-rss把 RSS 最高的前--process-limit默认 10个进程加入报告。单个 Pod 的exec失败或超时不会中断整体采集错误会记入报告的process_errorsJSON或## Process Sample ErrorsMarkdown其余 Pod 继续正常采样。每条 kubectl 调用的超时时间由--kubectl-timeout控制默认 30 秒。按负载阶段采集快照文档要求至少覆盖以下 7 类采样点每个阶段用一个有辨识度的--sample值区分沙箱 ready 后的空载状态--sample empty执行一条简单 bash 命令之后--sample after-bash跑一个 import 常见包的 Python 任务之后--sample after-python预期有 Node 负载时跑完 Node 任务之后在/mnt/user-data/outputs下生成文件之后--sample after-artifact释放并暖复用warm reuse之后目标并发水位例如 10、50、100 个沙箱。主路径命令在仓库根目录执行python scripts/sandbox_memory_profile.py \ --namespace deer-flow \ --selector appdeer-flow-sandbox \ --sample empty \ --include-processes \ --format markdown文档给出的各阶段 JSON 采集示例python scripts/sandbox_memory_profile.py --sample after-bash --format json python scripts/sandbox_memory_profile.py --sample after-python --format json python scripts/sandbox_memory_profile.py --sample after-artifact --format json--include-processes用于区分 Pod 级 cgroup 内存和进程 RSS 这两个数。它们不会精确相等cgroup 内存可以包含 page cache 等内核记账部分进程 RSS 采样拿不到这些。哪个数字更贴近你想回答的问题决定了你需要哪一路数据。保存原始 JSON。文档明确要求对比后端时保留 raw JSON以便事后审计 totals、Pod 名称、镜像、requests/limits 和时间戳。如何核对报告报告中的summary给出 pod_count、total_memory_mib、average_memory_mib、max_memory_mib、parsed_memory_count/unparsed_memory_count等汇总值Markdown 格式的逐 Pod 表格列为Pod | Phase | CPU | Memory | Start Time加--include-processes后还有## Top Processes段PID / PPID / RSS / Command。核对时关注两点解析失败计数。unparsed_memory_count、unparsed_cpu_count非 0 说明有 Pod 的读数没被解析报告中的总量只覆盖已解析的部分结论要以parsed_memory_count是否覆盖全部目标 Pod 为前提。进程采样错误。pods_with_process_sample_errors非 0 时说明部分 Pod 的kubectl exec被拒绝或超时这类 Pod 没有进程级数据但其kubectl top读数仍在报告里。文档对kubectl top读数本身有一条重要限定它报告的是 Kubernetes/容器 working set 内存应作为容量信号对待不是独占的 RSS/PSS。Pod 级内存包含 Pod 内所有容器还可能包含计入 cgroup 的 cache。某个结果反常时先检查沙箱进程和节点上的 cgroup 指标再下结论。用基线对比候选后端拿到 AIO 基线后对比要在同一份 DeerFlow 负载上进行并按 backend/docs/SANDBOX_MEMORY_PROFILING.md 的候选运行时矩阵记录证据核心项包括维度需要的证据容量Pod/实例数、总内存、平均内存、最大内存启动1、10、50、100 个并发沙箱的 ready 延迟命令bash 输出、超时行为、失败形态文件read_file、write_file、二进制update_file、list_dir、glob、grep上传gateway 上传的文件在沙箱内可见产物写入/mnt/user-data/outputs的文件可被后端 artifact API 读取路径/mnt/user-data/workspace、/mnt/user-data/uploads、/mnt/user-data/outputs、/mnt/acp-workspace及 skills 路径保持预期语义隔离不同用户和线程之间不能互相读数据清理release、idle 超时、进程重启、孤儿清理能释放资源运维部署前置、特权组件、网络、存储、升级路径文档的 PR 指引把基线数据定为了硬性条件在没有用同一份 DeerFlow 负载测过当前 AIO 沙箱和候选后端之前不要声称新 provider 修复了高并发内存问题实验性 provider 的 PR 优先标注Related to #3213除非 PR 本身附带可复现的负载数据证明达到目标内存降幅且 uploads、outputs、artifacts 与隔离行为不回归。【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考