同时执行多个SUBMIT JOB STATS对NebulaGraph的影响及机制问询

一、任务执行机制 #

SUBMIT JOB STATS是用于统计图空间点、边数量的后台任务，在3.1.0版本中的执行逻辑如下：

• 任务由Meta服务统一调度，每个STATS任务会被拆解为多个子任务，分发到对应数据所在的Storage节点
• Storage节点通过后台线程池处理统计子任务，不会阻塞核心的读写服务
• Meta服务会维护每个任务的全生命周期状态（排队、运行、完成、失败），可通过SHOW JOBS命令查看

二、对集群的影响 #

同时提交数十个STATS任务确实会对集群产生资源竞争影响，具体情况分场景：

• 资源占用层面：每个STATS任务需要扫描Storage节点上的SST文件，会消耗CPU、磁盘IO和内存资源。任务数量过多时，磁盘IO使用率会大幅上升，直接导致线上读写请求响应变慢，出现卡顿
• 单机部署场景：所有服务共享同一台机器的硬件资源，CPU、内存、IO的冲突会更明显，整体性能下降幅度较大
• 分布式部署场景：影响相对可控，但如果所有Storage节点同时被分配大量统计子任务，局部节点仍会出现资源紧张，进而影响该节点上的其他业务操作

三、任务执行顺序 #

任务不会严格按照Job ID顺序执行：

• 所有提交的STATS任务会进入Meta的任务队列，Meta会根据集群实时负载调度任务，优先给资源闲置的节点分配子任务
• 即使先提交的任务Job ID更小，如果其对应的Storage节点负载较高，可能会晚于后提交但负载低的任务启动
• 任务完成顺序取决于子任务的执行速度，和Job ID顺序无直接关联

内容的提问来源于stack exchange，提问作者user20209636