同时跑多个渲染任务时耗时暴增，常见的原因有两个方向：一是任务在排队等待资源，二是已运行任务把 CPU、内存或磁盘占满后互相拖慢。DramaClaw 的并发调优，本质上是在这两个方向之间做区分，然后通过调整并发参数观察单任务耗时，找到当前硬件能承受的档位。
渲染任务并发调优的切入点是区分“排队等待”和“资源耗尽”：排队时系统负载通常不高，资源耗尽时负载和内存占用会同步走高。操作上先看队列长度和系统资源，再核对并发配置与核数内存是否匹配，用控制变量逐档调整并发数，每次只改变一个参数并记录单任务耗时，以耗时平稳上升为界限确定合理并发值，最后把基线写入配置文件防止重启失效。
观察渲染队列的阻塞现象和系统负载
排查第一步，是确认耗时暴增发生在“排队”还是“执行”阶段。排队特征明显：任务列表有堆积，但系统 CPU 空闲、内存压力不大；执行阶段资源耗尽则相反，CPU 多核打满或内存接近上限，任务并不是在等队列，而是每个任务都跑得慢。
- Linux 下用
top或htop观察 CPU 占用和 load average；Windows 用任务管理器查看 CPU 使用率和内存趋势。 - 用
vmstat 1 5看 r 列和 si/so 列，r 明显超过核数说明任务在抢 CPU；si/so 持续非零说明内存开始吃紧。 - DramaClaw 自带监控一般有队列长度、运行中任务数、等待中任务数三个指标，优先记录这三项在耗时暴增时刻的取值，能直接判断是排队还是资源争用。
如果队列长度很大但 CPU 和内存都不高，瓶颈通常在任务调度或锁等待；如果资源已经打满，则是并发数设置偏高，先调低再继续排查。
检查当前并发配置与硬件规格是否匹配
并发参数设置得高于硬件承受能力时，系统会在任务间频繁切换，单任务的单位处理时间会被拉长。先确认当前配置项，再和硬件规格做粗略对比。
# 常见命令形如
DramaClaw render `--config` config.yaml `--show-options`
# 或直接查看配置文件中的并发相关项
cat config.yaml | grep -i concurrency
grep -i resource config.yaml配置项名称在不同版本里可能不同：max_concurrent_renders、task_concurrency、max_worker 都是常见命名。使用前建议先跑 DramaClaw render `--help` 确认实际参数名。
并发参数建议先以“CPU 物理核数”和“可用内存”为参照，而不是看逻辑线程数。通常可以按物理核数作为基准：从核数 × 1开始试，内存按每个渲染任务的最大占用做减法。每核配多少内存取决于场景，建议先按 2GB 核占用估算。如果单任务峰值占用超过这个估算，说明并发数需要下调，而不是继续压硬件。
逐步调整并发参数并记录单任务耗时
调并发数必须做单变量控制：一次只改一个参数，测试同一批任务，记录单任务耗时。不能同时改并发数和内存上限，否则无法判断是哪个调整产生了效果。
- 用默认配置跑一组固定任务，记录总耗时和单任务耗时，作为基准。
- 修改并发参数，建议每次调低 1 档或调高 1 档，不要直接翻倍。
- 每档跑同一组任务，观察 CPU、内存、队列长度三项数据。
- 记录单任务耗时最快且资源未打满的档位，候选为合理并发数。
每次测试的记录模板建议包含以下字段，方便横向对比：
| 测试编号 | 并发数 | 任务数 | 单任务平均耗时 | CPU峰值 | 内存峰值 | 队列最大长度 | 结论 |
|---|---|---|---|---|---|---|---|
| 1 | 默认值 | 同一组 | 填写 | 填写 | 填写 | 填写 | 基准 |
| 2 | 核数×1 | 同一组 | 填写 | 填写 | 填写 | 填写 | 对比 |
| 3 | 上一档±1 | 同一组 | 填写 | 填写 | 填写 | 填写 | 对比 |
判断标准只有一个：单任务耗时开始明显上升时，前面一档并发数通常就是当前硬件下的合理解；如果耗时持平而资源未打满，可以继续上调一档观察。
使用日志定位单个任务的资源峰值
调好并发参数后，还要看单个任务内部是否出现资源冒尖。DramaClaw 的任务日志中通常包含资源相关字段，例如：
task_id=task_0123 stage=render status=done
cpu_peak=78 memory_peak=1.8GB io_read=412MB
duration_ms=1240cpu_peak 和 memory_peak 分别表示该任务在运行时占用的 CPU 百分比和内存峰值。如果某个任务的 memory_peak 接近机器可用内存上限，说明当前并发数下多个任务的内存峰值会叠加，存在触发交换或内存不足的风险。
定位具体任务时，先按 duration_ms 排序找出耗时最长的任务，再检查对应任务的 cpu_peak 和 memory_peak。如果长耗时任务内存峰值不高但 CPU 高，优先怀疑资源争用；如果内存峰值特别高，需要结合机器内存判断是否单独这类任务就能压垮并发环境。日志字段名在不同版本可能有差异，以实际输出的键名为准。
建立调优基线并保存为固定配置
找到合理并发数后，把结果写进 DramaClaw 的配置文件，避免每次重启回到默认值。配置写入方式通常如下：
# config.yaml
render:
max_concurrent_renders: 4
max_memory_per_task: 2GB保存后先执行一次配置校验：
DramaClaw render `--config` config.yaml `--check`校验通过后，用刚写入的配置再跑一遍测试任务，确认重启后配置仍被读取。验证时可以用 DramaClaw render `--show-options` 确认当前生效值，也可以直接看日志里是否输出了并发参数。注意固定配置只代表当前硬件和任务类型下的基线，换成更大的场景或机器后，需要重新按上面的步骤确认一次，而不是直接沿用。