Compaction task被阻塞住

[xiaobingxia-at]

由于各种原因，需要单个cluster支持50000partition，产生大量的segment。在cluster 2.5.1， 我将compaction的并发度调高，并降compaction trigger的条件变的更加严苛，希望出现segments时，及时compact。
我的cluster设定如下：

    mixCoord:
        replicas: 1
        resources:
            limits:
                cpu: 29.4
                memory: 54Gi

    dataNode:
        replicas: 6
        resources:
            limits:
                cpu: 4.9
                memory: 40Gi

    queryNode:
        replicas: 12
        resources:
            limits:
                cpu: 14.7
                memory: 120Gi

    indexNode:
        replicas: 6
        resources:
            limits:
                cpu: 4.9
                memory: 9Gi

compaction有关设定如下：

        enableCompaction: true
        compaction:
            enableAutoCompaction: true
            indexBasedCompaction: false # If true, compaction will be triggered only if segment is indexed
            maxParallelTaskNum: 24 # The maximum number of compaction tasks that can be executed in parallel for the entire cluster
            taskQueueCapacity: 100000
            gcInterval: 3600
            dropTolerance: 86400 # the compaction task will be dropped if it is not executed within this time - 24 hours
            min:
                segment: 3
            mix:
                triggerInterval: 30
            levelzero:
                triggerInterval: 10
                forceTrigger:
                    deltalogMinNum: 2 # The minimum number of deltalog files to force trigger a LevelZero Compaction
                    deltalogMaxNum: 3 # pick up at most 3 deltalog files to compact
            single:
                ratio:
                    threshold: 0.05 # The ratio threshold of a segment to trigger a single compaction, default as 0.2
                deltalog:
                    maxsize: 2097152 # The deltalog size of a segment to trigger a single compaction, default as 16MB
                    maxnum: 2 # The deltalog's binlog files number of a segment to trigger a compaction, default as 200. 
                expiredlog:
                    maxsize: 2097152 # The expired log size of a segment to trigger a compaction, default as 10MB

        slot:
            clusteringCompactionUsage: 16 # slot usage of clustering compaction job.
            mixCompactionUsage: 8 # slot usage of mix compaction job. If data node's slotCap is 16, meaning each data node can run 2 mixCompaction tasks in parallel
            l0DeleteCompactionUsage: 8 # slot usage of l0 compaction job.

    dataNode:
        slot:
            slotCap: 32

但是出现了两个问题，第一个问题是，compaction并没有及时触发。
我将其compaction手动触发后，compaction task被阻塞住
[2024/12/31 16:40:58.941 +00:00] [INFO] [datacoord/compaction.go:154] ["compaction states"] [state=Executing] [executingCnt=5] [pipeliningCnt=252] [completedCnt=43] [failedCnt=0] [timeoutCnt=0] [analyzingCnt=0] [indexingCnt=0] [cleanedCnt=0] [metaSavedCnt=0] [2024/12/31 16:40:58.941 +00:00] [INFO] [datacoord/services.go:1196] ["success to get compaction state"] [traceID=68e0c5cf15dcd7267a22e1e37d4160d7] [compactionID=454988264100012942] [state=Executing] [executing=257] [completed=43] [failed=0] [timeout=0]
有5个task一直处于executing状态已经好几个小时。然后252个在waiting。只完成了43个。

请问：

1. 我的设置是否有问题？
2. 能否解释一下mix compaction，l0 compaction和single compaction
   谢谢。

[xiaobingxia-at]

另外，2.5.1 目前推荐上production用嘛 （50000 partition per cluster)...

[xiaobingxia-at]

粗读了一遍code，compaction变成多线程会不会死锁。。。

[xiaofan-luan]

2.5.1有一个锁泄漏的的bug，目前已经修复了，预计本周就会发版本，你可以看看符不符合你的场景。
#38856

建议的几个点：

1. 所有删除/upsert操作，都走partiton，而不要用collection级别
2. mix compactiin min -> 可以从3调整到5，降低小compaction发生的数目
3. single compaction -> 不要动参数，减少single compaction的发生，不然这么多segment会频繁做single compaction，datanode工做很高多。

在你的case，性能不是最关键的。不需要特别频繁的合并。首要任务是保证L0 compaction能把消费掉，其次是保证mix compaction能够很好的合并segment，最后才是做single compaction清理删除这些

[xiaobingxia-at]

@xiaofan-luan 非常感谢详细建议。因为我之前做的假设是，大量的segment会让coordinator变得很忙，出现各种问题。比如，我recreate cluster时，或者replace query node，需要处理大量segment，换一个query node要几个小时直接卡住。因此我才会想方设法频繁合并，降低segment数目，我的初衷是，宁肯多花费一些data node的资源，也要把segment数目降下来。这样一个cluster本来能支持50k个partition，现在就可以支持100k个了。

请问以上这个理论是否正确？segment的数目同以下几件事是否有关系： 1） Load/Release Collection/Partition非常非常慢，最后timeout 2）replace一个query node，需要花几个小时的时间才能migrate data到另一个新的query node。

[xiaofan-luan]

1. segment load是有一些优化空间的，等这些优化全部merge了，十万级别的segment恢复速度应该是在十分钟以内。更加长期的优化，需要靠2.6的lazy load来优化了。目前看load的主要瓶颈已经到了磁盘带宽上。
2. 我们的目标是把每个partition控制在平均三个segment以下就可，这里的假设是大部分partition是不会一起更新的。即使采用默认的compaction的参数，应该也是可以达成3个的目标的，如果过于激进的compaction，可能会导致因为一些额外的compaction工作导致datanode/indexnode被占满，影响正常compaction的工作。

整体来看，目前这些优化应该都会进到2.5.3版本中。下周我们会给出1w collection， 1000collection * 1000partition还有单表16384partition的测试报告。目前我们的测试还比较简单，每个partition就放几百条数据。我们会在引入一些upsert做一些比较长期的测试。

@bigsheeper @yanliang567

[xiaobingxia-at]

@xiaofan-luan 再次感谢。这里compaction有个问题。默认的compaction设置，compaction比较慢。我们在最坏情况下，每小时会更新上10w个分区。对于如何加速compaction有没有什么好的建议。谢谢。

[xiaofan-luan]

这个只能多加node增加并发了。10w个Segment听起来并不算很多。尤其是比较小的segment，连compaction带建索引，应该是10秒级别的。如果追不上很可能还是调度问题。

[xiaofan-luan]

不过频繁导入生成大量小文件并不是符合milvus设计的场景，这个往后风险会比较大，partitionkey还是比较推荐。
Zilliz cloud里面有一个partitionkey isolation模式，把不同租户的向量直接建索引了。目前开源还没有这个方案，不过我们已经决定在后续版本在开源索引也开源这个方案了，如果不是特别急还是等等这个方案。

[xiaobingxia-at]

好嘞，再次感谢！