Rerun 海量点云卡顿排查指南从 576 个 chunk 压到 217 个【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun打开一个 50 万行的 .rrdRerun Viewer 转圈 30 秒才出第一帧时间轴一拖fps 从 60 掉到个位数内存从 800MB 顶到 2GB。如果你正在用 Rerun 做机器人多模态数据的日志查询与可视化遇到这类数据量一上来就慢的症状八成不是 GPU 不够快而是 chunk 切得太碎。Rerun 把日志切成 Arrow 编码的 chunk 存储几乎所有环节的成本都跟 chunk 数量近似线性挂钩——chunk 越多索引、查询、渲染的固定开销就越高。先看结论瓶颈 → 对策 → 收益对照症状定位到的瓶颈关键对策预期收益打开 rrd 10s小 chunk 数量过多离线rerun rrd optimize打开时间降至 1/3时间轴拖拽掉帧每帧遍历过多 chunk放大RERUN_CHUNK_MAX_*单帧 CPU 降 30-50%端到端延迟 200msSDK 微批过小、chunk 碎片调RERUN_FLUSH_TICK_SECS延迟压到 50ms 内稳态内存 2GB冗余元数据 无 GC合并 --memory-limit稳态内存降 30%只要有一条命中往下看就有明确的下一步。第一步 诊断三条命令锁定瓶颈位置别急着改参数先用官方 CLI 摸清底# 看 chunk 分布num_chunks、ipc_size_bytes_avg、num_rows_avg rerun rrd stats data.rrd重点看三个数num_chunks是否远大于num_rows说明 chunk 太碎、ipc_size_bytes_avg是否小于 100 KiB说明平均 chunk 偏小、Chunk index analysis段里的effective与theoretical lower bound比值是否超过 3×。官方给了一份完整的示例输出可以直接对照optimize-chunks.md。Viewer 侧再开两样东西一是在设置里勾选 Show performance metrics顶栏会挂出 RAM、每帧 CPU 毫秒数、FPS、端到端延迟四个指标二是CtrlShiftM打开开发者面板进 Latency 标签看batch creation → gRPC sink → encode and transmit → receive and decode → ingest into viewer五段耗时——哪一段占大头瓶颈就在那一层。完整操作路径与解读表见 diagnose-performance.md。第二步 定位四种最常见的卡点1. 碎 chunk 堆积最高频典型现象num_chunks到几万、num_rows_avg只有个位数。根因是 SDK 每 200ms 或 1 MiB 就切一次微批长时间流式日志下来 chunk 数量线性膨胀。确认方法就是上面rrd stats的三个数外加Chunk index analysis里的excess数值——只要三位数起基本可以锁定。2. SDK 微批阈值过保守典型现象Latency 面板里batch creation或encode and transmit段耗时最长。根因是默认 0.2s 时间阈值 1 MiB 空间阈值高吞吐日志下每批只攒几个事件就发走了。确认方法是观察 gRPC sink 附近的耗时占比30% 基本就是它。3. 时间轴拖拽引发查询风暴典型现象静态打开正常、一拖动时间轴掉帧。根因是 Viewer 每帧要遍历当前时间可见的全部 chunk 做可见性计算chunk 越多egui 立即模式下的查询代价越高。确认方法设置里隐藏所有 View若帧率立刻恢复说明是渲染查询叠加问题。4. 内存被历史 chunk 占满典型现象跑 20 分钟后内存 2GB顶栏 RAM 数字持续上涨。根因是默认上限是系统内存 75%旧 chunk 不会被主动回收。确认方法开发者面板 Memory 火焰图看哪一类 chunk 占用最大。第三步 优化三个可直接落地的手段手段一离线rerun rrd optimize收益最大适用反复查询或分发的 rrd 文件、数据集预处理阶段。思路是把小 chunk 合并到接近目标大小一次性砍掉索引压力和固定开销。# 官方实测576 chunk → 217-62.3%耗时 2.5s # object-store 适合仓库/训练侧live 适合在线 Viewer rerun rrd optimize --profile object-store --max-size 2MiB \ -o out.rrd in.rrd合并后ipc_size_bytes_avg从 200 KiB 提到 410 KiB打开和查询都有明显提速。手段二在线调 SDK 微批阈值适用直播/录屏阶段SDK 与 Viewer 同机或跨网。把时间阈值和空间阈值同时放宽让单批攒更多事件再发。# 默认 0.2s/1MiB → 放宽到 0.5s/4MiBchunk 数量约减半 export RERUN_FLUSH_TICK_SECS0.5 export RERUN_FLUSH_NUM_BYTES4194304代价是端到端延迟增加约 300ms换取 Viewer 侧查询和索引开销显著下降。延迟敏感就把 tick 调到 0.3s 折中。手段三Viewer 存储层合并上限适用Viewer 端持续接收流式日志、chunk 又不够大触发合并的场景。默认 384 KiB / 4096 行可以整体放大。# 启动 Viewer 时放大合并阈值让 chunk 长得再合并 RERUN_CHUNK_MAX_BYTES1048576 \ RERUN_CHUNK_MAX_ROWS16384 \ rerun --memory-limit 4G data.rrd配合--memory-limit给内存兜底避免长时间运行把系统吃满。Python 侧的 ETL/格式转换也可以把合并塞进 pipeline走LazyChunkStream.collect(optimizeOptimizationProfile.OBJECT_STORE)会执行与 CLI 相同的合并逻辑。核心源码在 crates/store/re_chunk_optimizer/。第四步 验证跑一次对比表优化完必须回测不然数字只是感觉。固定同一条命令在优化前后各跑一遍把关键列抄进下表指标优化前优化后变化num_chunks576217-62.3%ipc_size_bytes_avg200 KiB410 KiB105%ipc_size_bytes_max568 KiB1.0 MiB78%冷启动打开耗时3.5s1.2s-66%时间轴拖拽平均帧 CPU42 ms18 ms-57%稳态内存10min 播放2.1 GB1.4 GB-33%数字不必完全一致方向必须对。只要num_chunks降下来、平均 chunk 变大、打开耗时和帧 CPU 同向下降说明合并真起效了反之要回头查--profile选对没有、环境变量是否被覆盖。实施优先级与进阶方向按投入产出排序先跑rerun rrd stats看num_chunks与理论下界的比值3× 就立刻rerun rrd optimize——这是唯一一次性能拿到 50% 以上收益的动作。再调RERUN_CHUNK_MAX_*和RERUN_FLUSH_*把在线路径的 chunk 数量压下去解决拖拽掉帧。最后才是--memory-limit和隐藏 View作为兜底。进阶方向把合并做成 CI 步骤每次数据集更新自动重压一遍让object-store预设产物直接进仓库。接入 puffin 火焰图CtrlShiftP抓取定位 Viewer 内部的[WAIT]阻塞区分查询慢和渲染慢。超大 rrd 同时保留object-store和live两份产物仓库查询用前者、本地预览用后者两边都不牺牲。 记住这一条Rerun 的性能问题 80% 出在 chunk 数量而 80% 的 chunk 数量问题可以被一条rerun rrd optimize解决。先把 stats 跑起来数字会告诉你该往哪走。【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考