Flink检查点会导致背压

Question

我正在使用至少一次检查点模式，这应该是异步化进程。有人能建议吗？我的检查点设置

    env.enableCheckpointing(1800000,
          CheckpointingMode.AT_LEAST_ONCE);
      env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
      env.getCheckpointConfig()
          .enableExternalizedCheckpoints(
              CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
      env.getCheckpointConfig()
          .setCheckpointTimeout(10min);
      env.getCheckpointConfig()
          .setFailOnCheckpointingErrors(
              jobConfiguration.getCheckpointConfig().getFailOnCheckpointingErrors());

我的工作有128个容器。

我想用一个30分钟的检查站看看

Answer 1

任何类型的检查点都会增加计算开销。大多数检查点是异步的（如您所述），但它仍然会增加一般的I/O操作。例如，这些额外的I/O请求可能会阻塞您对外部系统的访问。此外，如果您启用检查点，Flink需要跟踪更多信息（新与已检查点）。

你是否试图为你的工作增加更多的资源？你能分享你的整个检查点配置吗？

Answer 2

太长，读不下去了有时很难分析这个问题。我有两个幸运的猜测/猜测-如果您使用的是RocksDB state backend，您可以切换到FSStateBend-它通常更快，RocksDB对于不适合内存的大状态大小最有意义（或者如果您确实需要增量检查点功能）。第二种是摆弄平行度，增加或减少。

我会怀疑@ArvidHeise写的同样的事情。检查点的大小不是很大，但也不是微不足道的。它可能会增加额外的开销，使工作超出勉强跟上流量的阈值，无法跟上并造成背压。如果您处于背压之下，延迟将不断累积，因此，即使额外开销的百分之几发生变化，也会在毫秒的端到端延迟与无限不断增长的值之间产生差异。

如果您不能简单地添加更多资源，那么您必须html" target="_blank">分析到底是什么增加了额外的资源，以及什么资源是瓶颈。

1. 是CPU吗？检查群集上的CPU使用情况。如果是100%左右，这就是你需要优化的地方
2. 是IO吗？检查集群上的IO使用情况，并将其与您可以实现的最大吞吐量/每秒请求数进行比较
3. 如果两个CPU

在弄清楚瓶颈是什么资源后，下一个问题是为什么？一旦您看到它，它可能会立即显而易见，或者可能需要深入研究，例如检查GC日志、附加分析器等。

回答这些问题可以为您提供您可以在工作中尝试优化的信息，或者允许您调整配置，或者可以为我们（Flink开发人员）提供我们可以在Flink方面尝试优化的额外数据点。