我们已经遇到了以生产规模移动应用程序的障碍，希望得到一些指导。应用程序是流处理中非常常见的用例，但确实需要维护大量的键控状态。我们正在处理2条溪流 - 其中一条是每日河水流（通常约50密耳，但在一小时内爆发可达100密耳），而另一条则是每小时约70-80密耳的恒定河流。我们正在使用两个键控流之间的CoProcess函数进行低级连接。 CoProcess函数需要从每日突发流刷新（upsert）状态，并使用来自使用突发流构建的状态的值来不断地装饰流数据。所有逻辑在独立的Dev环境中都运行良好。我们正在为州和大约2-3万的数据流投掷大约500k的突发流量事件。我们在服务器上有1个带有16GB内存的TM，1个带有8 GB内存的JM和16个插槽（服务器上每个核1个）。我们一直在采取保存点，以防我们需要重新启动应用程序以进行代码更改等。应用程序似乎也很好地从状态恢复。根据保存点，生产流程中的总状态量应为25-30GB左右。
然而，在这一点上，我们正在尝试以生产规模部署应用程序。 App还有一个标志，可以在启动时设置忽略数据流，因此我们可以简单地初始化状态。所以基本上我们试图看看我们是否可以先初始化状态并将保存点作为测试。此时我们正在使用10个TM，每个插槽有4个插槽和8GB内存（想法是分配大约3倍的估计状态大小开始）但是TM会因为GC Overhead Limit Exceeded错误而被YARN杀死。我们在Flink管理内存，堆外与堆内存，磁盘溢出，状态后端等方面经历了不少博客/文档。我们尝试以多种方式调整托管内存配置（关/堆，分数，网络缓冲等）但似乎无法找到微调应用程序以避免问题的好方法。理想情况下，我们会在内存中保持状态（我们在生产环境中有足够的容量）出于性能原因并溢出到磁盘（我相信Flink应该开箱即用？）。感觉集群内存中的3倍预期状态量应足以初始化状态。因此，我们希望从专家那里获得一些关于最佳实践的方法以及更好地规划此应用程序的方法，而不是继续增加内存（这可能会或可能没有帮助，因为错误与GC开销有关）。
提前感谢您的输入！