性能优化与容量规划

本文说明 Docker 一键安装场景下的资源基线、Ingest 管道与 Doris 存储调优、Web 查询侧参数，以及 Agent/SDK 侧减量建议。安装目录与端口见 Docker 运维参考。

1. 容量规划概览

默认架构

Docker 默认 四容器（Doris FE + BE、ingest、web），遥测经 OTLP 进入 ingest，批量写入 Doris，Web 查询 Doris。数据流详见遥测数据流与存储。

宿主机资源建议

下表来自 deploy/docker/docker-compose.yml 的默认 limits（安装后对应 /opt/databuff-ai-apm/docker-compose.yml）。

层级	CPU（核）	内存	说明
最低可运行	≥ 6	≥ 16 GiB	四容器 limits 合计约 6 CPU / 15 GiB，需为 OS 与 page cache 留余量
生产起步	≥ 8	≥ 32 GiB	中等遥测量、保留默认 30 天分区；BE 为存储与 compaction 主力
高负载	按遥测增量线性扩容	优先加 BE 内存与磁盘	先调 Agent 采样与保留天数，再调 ingest 管道与 BE

组件	CPU limit	内存 limit	JVM / 备注
Doris FE	1	2 GiB	启动脚本将 FE `-Xmx` patch 为 1200m（默认 8192m 会在 2g 容器内 OOM）
Doris BE	2	6 GiB	承载列存、compaction 与 Stream Load
ingest	2	5 GiB	`JAVA_TOOL_OPTIONS`: `-Xms1g -Xmx4g`
web	1	2 GiB	`JAVA_TOOL_OPTIONS`: `-Xms512m -Xmx1536m`

OOM 提示：FE 未 patch 或 BE 内存不足时，容器可能被 kill。见 Docker 运维参考 — 常见故障。

遥测量级粗算（估算思路）

以下为规划用数量级，非压测结论；请按实际采样率与 span 大小代入。

信号	输入变量	粗算关系
Trace	`S` = span/s，`R` = 保留天数	日增量行数 ≈ `S × 86400`；磁盘与 span 字段长度、`meta` 体积正相关
Metrics	`M` = 每分钟写入 Doris 的指标行数（含分钟聚合）	日增量行数 ≈ `M × 1440`；表数量多（`metric_*` 族）时按服务维度放大
Logs	`L` = log 条/min	日增量行数 ≈ `L × 1440`；`body` 与 `attributes` 长度主导单行体积

磁盘增长：日增量 × R × 压缩比。Doris 列存压缩比随数据分布变化，建议对 data/be-storage（Docker）或 BE 卷做 7 天观测 再外推。缩短保留（见下文 dynamic_partition.start）通常比单纯加盘更有效。

2. Ingest 管道调优

Ingest 使用 LMAX Disruptor 环形缓冲 + 多 worker；参数定义见 ai-apm-ingest/src/main/resources/application.yml。

管道并行与缓冲

配置项（YAML）	环境变量	默认值	适用场景	调大	调小
`ingest.pipeline.trace-tasks`	`INGEST_TRACE_TASKS`	`4`	Trace 解析与组装并行度	提高 CPU 占用，降低单队列积压	降低并行，省 CPU
`ingest.pipeline.metric-tasks`	`INGEST_METRIC_TASKS`	`4`	OTLP/JVM/分钟指标路由	同上	同上
`ingest.pipeline.aggregate-tasks`	`INGEST_AGGREGATE_TASKS`	`4`	分钟级聚合 worker	高 metric 吞吐时优先尝试	低负载省资源
`ingest.pipeline.trace-buffer-size`	`INGEST_TRACE_BUFFER_SIZE`	`1024`	每 trace worker 环形缓冲槽位（≥16）	缓冲突发 span，增内存	突发时更易 `overflow` 丢事件
`ingest.pipeline.metric-buffer-size`	`INGEST_METRIC_BUFFER_SIZE`	`1024`	每 metric worker 缓冲	同上	同上
`ingest.pipeline.aggregate-buffer-size`	`INGEST_AGGREGATE_BUFFER_SIZE`	`1024`	每聚合 worker 缓冲	同上	同上

缓冲满时 AsyncTask 在两次 tryPublish 失败后递增 overflowCount 并丢弃事件——若 ingest 日志无异常但 UI 缺数据，可优先加大 *_BUFFER_SIZE 或 *_TASKS。

如何修改 Ingest 参数（Docker）

适用：一键安装后的单机 Docker 部署（默认目录 /opt/databuff-ai-apm，可用 echo $APM_INSTALL_DIR 确认）。推荐用 docker-compose.override.yml 持久化自定义项（升级不覆盖），完整步骤含 K8s 见参数配置。

备份并编辑 compose 文件

bash

cd /opt/databuff-ai-apm
cp docker-compose.yml docker-compose.yml.bak
vim docker-compose.yml   # 或 nano / VS Code Remote

在 ai-apm-ingest → environment 下追加变量（保留原有 DORIS_*、JAVA_TOOL_OPTIONS 等，仅新增性能项）：

yaml

  ai-apm-ingest:
    environment:
      # ... 原有项 ...
      INGEST_TRACE_TASKS: "8"
      INGEST_TRACE_BUFFER_SIZE: "2048"
      INGEST_DORIS_FLUSH_INTERVAL_MS: "3000"

Docker 编辑 ingest 环境变量示例

使配置生效并验证

bash

docker compose up -d ai-apm-ingest
docker exec ai-apm-ingest printenv | grep '^INGEST_'

期望输出包含刚设置的 INGEST_TRACE_TASKS=8 等；若无，检查 YAML 缩进是否在 environment: 下。

观察效果：docker compose logs -f ai-apm-ingest 查看是否仍有 Stream Load 超时；UI 侧对比 Trace 出现延迟是否缩短。

调参顺序建议：先加 INGEST_*_BUFFER_SIZE / *_TASKS 解决丢数据，再微调 INGEST_DORIS_FLUSH_INTERVAL_MS；每次只改 1～2 项便于回滚（docker compose up -d 前保留 .bak）。

Doris 刷盘与 Trace 组装

配置项（YAML）	环境变量（Spring 绑定）	默认值	说明	调大	调小
`ingest.doris.flush-batch-bytes`	`INGEST_DORIS_FLUSH_BATCH_BYTES`	`52428800`（50 MiB）	线程缓冲达到该估算 NDJSON 体积即 hand-off Stream Load	压测/单 BE 优先调大：降低 Stream Load 频率，避免 tablet version 打满 ~2000	过小会高频 load → version 堆积、compaction 跟不上、BE RSS 飙升
`ingest.doris.flush-interval-ms`	`INGEST_DORIS_FLUSH_INTERVAL_MS`	`30000`	定时 flush 间隔（`DorisFlushScheduler` 时间兜底）	进一步降低 load 频率，写延迟上升	更频繁 flush（易触发 version 上限）
`ingest.doris.trace-flush-concurrency`	`INGEST_DORIS_TRACE_FLUSH_CONCURRENCY`	`1`	`trace_dc_span` 同时 in-flight 的 Stream Load 数	多路并行会叠加 version / SegmentCache 压力	单 BE 保持 1
`ingest.doris.flush-timeout-ms`	`INGEST_DORIS_FLUSH_TIMEOUT_MS`	`60000`	单次 Stream Load 等待上限（最小 5000）	容忍慢 BE / 大 50MiB 批次	超时失败更早暴露
`ingest.trace.assembly-check-interval-ms`	`INGEST_TRACE_ASSEMBLY_CHECK_INTERVAL_MS`	`2000`	Trace 片段组装扫描周期	降低 CPU 扫描频率，未完成 trace 滞留更久	更快完成跨 span 组装
`ingest.metric.trace-minute-late-flush-grace-ms`	`INGEST_METRIC_TRACE_MINUTE_LATE_FLUSH_GRACE_MS`	`20000`	分钟指标在 trace 迟到时的宽限	容忍时钟漂移 / 慢 trace	更快落盘分钟桶，可能缺迟到 span 关联

上述 INGEST_DORIS_* / INGEST_TRACE_ASSEMBLY_* 等变量与管道参数相同，写在 ai-apm-ingest 的 environment 中，改完后 docker compose up -d ai-apm-ingest。

3. Doris 存储与保留

表结构见 deploy/common/sql/databuff.sql。Trace、Log 及多数 metric_* 表启用 按日动态分区。

默认保留

sql

"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-30",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p"

属性	含义
`dynamic_partition.start = -30`	保留约 30 个历史日分区（早于该窗口的分区由 Doris 自动删除）
`dynamic_partition.end = 3`	预创建未来 3 天分区
`dynamic_partition.time_unit = DAY`	按天滚动

调整保留天数

对已运行环境，通过 Doris MySQL 协议（FE 端口 9030）执行 DDL——无需重启 FE/BE。

操作步骤：

在能访问 Doris FE 的机器上连接（Docker 宿主机示例）：

bash

mysql -h 127.0.0.1 -P 9030 -uroot

若本机无 mysql 客户端，可用容器：docker run --rm -it mysql:8.4 mysql -h <fe-host> -P 9030 -uroot

查看当前 Trace 分区（确认动态分区已启用）：

sql

USE databuff;
SHOW PARTITIONS FROM trace_dc_span;

将保留从默认 30 天改为 14 天（示例，按磁盘压力调整数值）：

sql

ALTER TABLE trace_dc_span SET (
  "dynamic_partition.start" = "-14"
);

对日志与指标表重复（按需）：

sql

ALTER TABLE log_dc_record SET ("dynamic_partition.start" = "-14");
-- metric_* 表同理，例如：
ALTER TABLE metric_service SET ("dynamic_partition.start" = "-14");

再次 SHOW PARTITIONS 确认；早于新窗口的历史分区会由 Doris 调度逐步删除，不是瞬时清空。

Doris 分区查看与 ALTER 保留天数

新建环境：在首次 start.sh 导入前，直接改 deploy/common/sql/databuff.sql 中各表 dynamic_partition.start，再初始化。

缩短保留可立即降低 BE 磁盘与 compaction 压力；延长保留需同步规划磁盘与内存。

查询性能建议

Trace / Log 表按 startTime / log_time 分区：务必带时间范围，避免跨过多日分区全表扫描。
Trace 表 DISTRIBUTED BY HASH(trace_id)：按 trace_id 点查友好；大范围聚合仍依赖分区裁剪。
Web UI 操作：各 APM 页面右上角时间选择器默认「最近 1 小时」；排查单次问题用 15 分钟～1 小时，趋势分析再用 6 小时/1 天。

如何缩小查询时间范围：

打开 应用性能 → 链路追踪（或服务 / 日志分析等页面）。
点击右上角 「最近 1 小时」（或当前显示的时间文案）。
在弹层中选择预设（如 最近 15 分钟）或填写开始/结束时间后点应用。

链路追踪页与时间选择器入口

选择更短时间窗口（示例：最近 15 分钟）

FE / BE 内存

FE：docker-compose.yml 启动前 sed 将 -Xmx8192m 改为 -Xmx1200m。勿删除该 patch。
BE OOM：Docker 部署不设容器 mem_limit；BE 会使用宿主机可用内存。优先保证主机空闲内存 ≥6–8g，并用 docker stats ai-apm-doris-be --no-stream 观察占用。

若仍 OOM，优先 缩短 dynamic_partition.start 或扩容磁盘，再给主机加内存。

4. Web 查询与告警

参数见 ai-apm-web/src/main/resources/application.yml。

监控任务线程池

配置项	环境变量	默认值	说明	调大	调小
`apm.monitor.pool.core-size`	`APM_MONITOR_POOL_CORE_SIZE`	`4`	告警/监控评估常驻线程	并行评估更多规则	省 CPU，规则多时排队
`apm.monitor.pool.max-size`	`APM_MONITOR_POOL_MAX_SIZE`	`16`	峰值线程上限	突发评估吞吐更高	限制并发，防 Doris 查询风暴
`apm.monitor.pool.queue-size`	`APM_MONITOR_POOL_QUEUE_SIZE`	`100`	等待队列深度	缓冲评估高峰	队列满后任务被拒绝

实现类：MonitorTaskPool.java。

告警调度

配置项	环境变量	默认值	说明
`apm.alarm.lookback-minutes`	`APM_ALARM_LOOKBACK_MINUTES`	`5`	单次规则评估回溯分钟数
`apm.alarm.evaluation-cron`	`APM_ALARM_EVALUATION_CRON`	`0 * * * * ?`	每分钟第 0 秒触发（Spring 6 域 cron）

规则较多且 Doris 压力大时，可适当增大 lookback-minutes 的替代策略是减少规则数量或缩小监控服务范围——增大回看会直接增加每次查询数据量。

HTTP 压缩

server.compression.enabled: true，对 JSON/JS 等大于 1024 字节的响应启用 gzip，有利于大盘与拓扑接口，一般无需关闭。

如何修改 Web 告警线程池（Docker）

告警评估使用 apm.monitor.pool.*；在 web 容器环境变量 中覆盖（与 ingest 相同，改 docker-compose.yml 里 ai-apm-web.environment）。

编辑 /opt/databuff-ai-apm/docker-compose.yml，在 ai-apm-web → environment 追加：

yaml

      APM_MONITOR_POOL_CORE_SIZE: "8"
      APM_MONITOR_POOL_MAX_SIZE: "24"
      APM_ALARM_LOOKBACK_MINUTES: "3"   # 可选，默认 5

docker compose up -d ai-apm-web

修改 Web 线程池环境变量

规则很多时，减少规则数量比无限增大线程池更有效；lookback-minutes 越大，单次 Doris 扫描量越大。

5. OTel SDK / Agent 侧建议

服务端调优前先控制上报量，收益通常最大。接入基础见 OpenTelemetry OTLP 接入。

手段	典型环境变量 / 配置	说明
Head 采样	`OTEL_TRACES_SAMPLER=parentbased_traceidratio`、`OTEL_TRACES_SAMPLER_ARG=0.1`	在 SDK 入口丢弃大部分 trace，直接降低 span/s
Tail 采样	OpenTelemetry Collector `tail_sampling` processor	保留错误/高延迟 trace，需部署 Collector 中转
Metric 导出间隔	`OTEL_METRIC_EXPORT_INTERVAL`（SDK 常见默认 60000 ms）	拉长间隔可降低 metric 条/min
Trace 批大小	`OTEL_BSP_MAX_EXPORT_BATCH_SIZE`、`OTEL_BSP_SCHEDULE_DELAY`	影响网络批次，不减少存储行数
Log 批处理	`OTEL_BLRP_MAX_EXPORT_BATCH_SIZE`、`OTEL_BLRP_SCHEDULE_DELAY`	控制 log 导出批次与频率

生产环境建议：先定采样策略 → 再调 metric 周期 → 最后调 ingest/Doris。

如何配置 OTel 采样（应用侧）

在 业务进程 或 Demo 启动脚本 中设置环境变量（与语言无关，OTel SDK 自动读取）：

bash

export OTEL_TRACES_SAMPLER=parentbased_traceidratio
export OTEL_TRACES_SAMPLER_ARG=0.1          # 约 10% trace
export OTEL_METRIC_EXPORT_INTERVAL=120000   # 指标 120s 导出一次
java -javaagent:opentelemetry-javaagent.jar -jar your-app.jar

Java 也可用系统属性：-Dotel.traces.sampler=parentbased_traceidratio -Dotel.traces.sampler.arg=0.1

OTel 采样环境变量示例

修改后重启应用；在 应用性能 → 链路追踪 中观察 Trace 数量是否下降。接入细节见 OpenTelemetry OTLP 接入。

6. 离线安装与在线安装

二者使用相同镜像与 docker-compose.yml 默认值，无性能差异；离线仅改变分发方式（见离线安装）。性能参数均在安装目录的 docker-compose.yml 中修改，步骤与上文 ingest / web / BE 相同。

7. x86_64 无 AVX2 时绕过安装检测

Doris BE 在 x86_64 / amd64 上依赖 AVX2 指令做向量化查询。在线/离线安装脚本会调用 deploy/common/scripts/check-avx2.sh 中的 ensure_avx2_cpu；若 /proc/cpuinfo 不含 avx2 标志，安装将 exit 1 并提示换机器。

以下情况不会触发检测（脚本直接 return）：

环境	行为
arm64 / aarch64	跳过检测
macOS 等无 `/proc/cpuinfo`	跳过检测（Docker 内 Linux 容器仍会按宿主机 CPU 特性运行 Doris）

推荐：环境变量跳过（v0.1.6+ 脚本）

主仓 check-avx2.sh 支持 DATABUFF_SKIP_AVX2_CHECK=1（或 true）。安装前导出即可绕过检测：

在线安装（curl）：

bash

export DATABUFF_SKIP_AVX2_CHECK=1
curl -fsSL https://databuff.ai/databuff/ai-apm-install.sh | bash

离线安装：

bash

export DATABUFF_SKIP_AVX2_CHECK=1
cd /path/to/databuff-docker-offline-*-amd64
./install-offline.sh

跳过 AVX2 检测环境变量

安装日志会出现一行警告（非错误），提示 Doris 在无 AVX2 上可能不稳定。

备选：改离线包内脚本（无环境变量时）

适用于 CDN/离线包内 check-avx2.sh 尚未包含 DATABUFF_SKIP_AVX2_CHECK 的旧版本：

解压离线包后编辑 scripts/check-avx2.sh
在 ensure_avx2_cpu() 函数第一行加入 return 0（或整段替换为仅 return 0 的空函数）
再执行 ./install-offline.sh

在线 curl 安装若无法改 CDN 脚本，需等待包含跳过逻辑的 check-avx2.sh 发布，或改用离线包并按上法改脚本。

安装后如何确认 CPU 是否真有 AVX2

bash

grep -m1 avx2 /proc/cpuinfo && echo "AVX2: yes" || echo "AVX2: no"

风险说明

项	说明
为何检测	无 AVX2 的 x86_64 上 Doris BE 官方不推荐，可能出现 BE 启动失败、查询极慢或随机崩溃
跳过后果	仅绕过安装脚本拦截；不能改变 Doris 二进制对 AVX2 的依赖
建议	生产环境优先换 Haswell 及以后的 x86_64 或 arm64 机器；跳过仅用于 PoC / 旧 VM 应急

8. 排查清单

现象	检查项	处理方向
ingest 写入延迟高	`INGEST__BUFFER_SIZE`、`_TASKS`；`INGEST_DORIS_FLUSH_INTERVAL_MS` / `FLUSH_TIMEOUT_MS`	适度加大并行与缓冲；略降 flush 间隔需权衡 Doris 负载
ingest 写入失败	`DORIS_FE_HOST`、`DORIS_BE_HTTP_HOST`；ingest / BE 日志	确认 Stream Load 连通；BE 磁盘与 health
Doris BE OOM / 重启	主机空闲内存、保留天数、`be-storage` 使用率	加主机内存或 `ALTER TABLE` 缩短 `dynamic_partition.start`
Doris FE OOM	FE 是否已 patch `-Xmx1200m`	勿去掉 compose 中的 `sed` patch
Web 查询慢	UI 时间范围；Doris 分区裁剪；BE compaction	缩小查询窗口；检查 BE CPU/IO；避免无时间条件的宽查
规则评估拖慢 Web	`apm.monitor.pool.*`；规则数量	控制规则规模；必要时略增 `max-size`
UI 有指标无 trace	Agent 采样率；ingest buffer overflow	提高采样或加大 trace 管道缓冲
安装报 AVX2 / Doris 向量化	`grep avx2 /proc/cpuinfo`；是否误跳过检测	见 §7 x86_64 无 AVX2；换 CPU 或 `DATABUFF_SKIP_AVX2_CHECK=1`

日志入口：

bash

# Docker
docker compose logs -f ai-apm-ingest ai-apm-doris-be ai-apm-web

性能优化与容量规划 ​

1. 容量规划概览 ​

默认架构 ​

宿主机资源建议 ​

遥测量级粗算（估算思路） ​

2. Ingest 管道调优 ​

管道并行与缓冲 ​

如何修改 Ingest 参数（Docker） ​

Doris 刷盘与 Trace 组装 ​

3. Doris 存储与保留 ​

默认保留 ​

调整保留天数 ​

查询性能建议 ​

FE / BE 内存 ​

4. Web 查询与告警 ​

监控任务线程池 ​

告警调度 ​

HTTP 压缩 ​

如何修改 Web 告警线程池（Docker） ​

5. OTel SDK / Agent 侧建议 ​

如何配置 OTel 采样（应用侧） ​

6. 离线安装与在线安装 ​

7. x86_64 无 AVX2 时绕过安装检测 ​

推荐：环境变量跳过（v0.1.6+ 脚本） ​

备选：改离线包内脚本（无环境变量时） ​

安装后如何确认 CPU 是否真有 AVX2 ​

风险说明 ​

8. 排查清单 ​

相关文档 ​

性能优化与容量规划

1. 容量规划概览

默认架构

宿主机资源建议

遥测量级粗算（估算思路）

2. Ingest 管道调优

管道并行与缓冲

如何修改 Ingest 参数（Docker）

Doris 刷盘与 Trace 组装

3. Doris 存储与保留

默认保留

调整保留天数

查询性能建议

FE / BE 内存

4. Web 查询与告警

监控任务线程池

告警调度

HTTP 压缩

如何修改 Web 告警线程池（Docker）

5. OTel SDK / Agent 侧建议

如何配置 OTel 采样（应用侧）

6. 离线安装与在线安装

7. x86_64 无 AVX2 时绕过安装检测

推荐：环境变量跳过（v0.1.6+ 脚本）

备选：改离线包内脚本（无环境变量时）

安装后如何确认 CPU 是否真有 AVX2

风险说明

8. 排查清单

相关文档