由于流对齐，检查点端到端持续时间增加
我有一个flink作业，它读取用户事件，使用会话窗口并写回kafka。
我使用的状态后端是s3（没有hdfs集群，只是使用libs）。
问题是，端到端的检查点时间一直在增加，直到检查点被丢弃，而大部分时间都花在“对齐”上。
问题是-为什么？，如何在不将检查点模式设置为至少一次的情况下解决此问题？
共有1个答案
在进一步研究这个问题后，这是由于高GC时间（在检查点期间经常发生）。我们使用的是FS状态后端，虽然它的名称中有FS，它只指检查点的输出位置，而整个状态仍然存储在内存中（与rocksdb状态后端相反）。
不过，由于rocks db high（er）延迟，我们仍在使用FS state后端，这在本应用程序中是不允许的。
-
我使用Android的新Volley框架向我的服务器发出请求。但它会在得到响应之前超时,尽管它确实会响应。 我尝试添加以下代码：
-
现在我的疑虑是： 1）即使当少数检查点状态大小比其它检查点状态小（70-80%小）时，它也需要几分钟（15-20%的时间），而其它检查点状态则需要5-10秒。 2）缓冲区对齐大小有时会增加到7-8GB，而平均为800MB-1GB，但检查点时间不受此影响。我想它应该需要更多时间，因为它应该等待检查点屏障。 4）很少的子任务在hdfs中需要2-3分钟（5-10%的时间），所以98%的子任务在30-50
-
把自己从软件检查员寻常的手工检查工作中解放出来 在开始新项目时，多数人计划在将代码投入生产发行之前审核它们；但是，当提交日程超越了其他因素时，审核常常成为第一个被抛弃的实践。如果能够自动执行其中一些审核，那么情况又会怎样呢？在新系列 “让开发自动化” 的第一篇文章中，开发自动化专家 Paul Duvall 首先将研究如何自动化检查器（例如 CheckStyle、JavaNCSS 和 CPD）、如何
-
我试图建立一个系统与实时流处理与flink具有s3作为源和弹性作为接收器。 我总共尝试了4个检查站案例。 只有一次，检查点对齐 使用未对齐的检查点执行一次 至少\u次，最多1个并发检查点 至少\u次，最多2个并发检查点 带有未对齐的检查点的Exactly\u Once似乎在向接收器发布时具有最小的延迟。 而其余三个的延迟似乎是相似的。 根据文档：At_Least_Once不应该在检查点期间阻塞一个
-
我们有一个应用程序，我们在其中对REST API进行一些内部超文本传输协议调用来获取数据。但是有些请求花费的时间比预期的要长，所以我尝试增加超时持续时间。我尝试了以下操作： RequestConfig RequestConfig=RequestConfig.custom（）。setConnectTimeout（30*1000）。build（）；HttpClient HttpClient=HttpC
-
我有ISO8601格式的持续时间值，我将其转换为时间值为整数秒，如下所示： ISO8601格式的持续时间值＝“P1Y”。 我将该值存储在“时间-单位-秒”中。因此，当我检索的值将是在int，我想转换回ISO8601持续时间格式，所以我应该得到“P1Y”转换后回来。 有没有快速的方法可以做到这一点？或者我必须把时间的int值转换成float，然后通过某种方法把它转换成ISO8601持续时间。