我正在使用项目使用flink （版本-1.4.2 ）将大量数据提取到我的图形数据库（ 剑形图）。数据摄取分为两个阶段，一个阶段是顶点数据摄取，另一个阶段是边缘数据对图db的摄取。 顶点数据提取运行没有问题，但是在边缘提取期间。我收到一条错误消息，说与任务管理器taskmanagerName的连接断开。来自flink-taskmanager-b6f46f6c8-fgtlw的详细错误回溯如下：
2019-08-01 18:13:26,025 ERROR org.apache.flink.runtime.operators.BatchTask
- Error in task code: CHAIN Join(Remap EDGES id: TO) -> Map (Key Extractor) -> Combine (Deduplicate edges including bi-directional edges) (62/80)
org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException: Lost connection to task manager 'flink-taskmanager-b6f46f6c8-gcxnm/10.xx.xx.xx:6121'.
This indicates that the remote task manager was lost.
at org.apache.flink.runtime.io.network.netty.PartitionRequestClientHandler.exceptionCaught(PartitionRequestClientHandler.java:146)
at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:275)
at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:253)
at org.apache.flink.shaded.netty4.io.netty.channel.ChannelInboundHandlerAdapter.exceptionCaught(ChannelInboundHandlerAdapter.java:131)
at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:275)
at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:253)
at org.apache.flink.shaded.netty4.io.netty.channel.ChannelInboundHandlerAdapter.exceptionCaught(ChannelInboundHandlerAdapter.java:131)
at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:275)
at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:253)
at org.apache.flink.shaded.netty4.io.netty.channel.ChannelHandlerAdapter.exceptionCaught(ChannelHandlerAdapter.java:79)
at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:275)
at org.apache.flink.shaded.netty4.io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:253)
at org.apache.flink.shaded.netty4.io.netty.channel.DefaultChannelPipeline.fireExceptionCaught(DefaultChannelPipeline.java:835)
at org.apache.flink.shaded.netty4.io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.handleReadException(AbstractNioByteChannel.java:87)
at org.apache.flink.shaded.netty4.io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:162)
at org.apache.flink.shaded.netty4.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
at org.apache.flink.shaded.netty4.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
at org.apache.flink.shaded.netty4.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
at org.apache.flink.shaded.netty4.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
at org.apache.flink.shaded.netty4.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at org.apache.flink.shaded.netty4.io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:311)
at org.apache.flink.shaded.netty4.io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:881)
at org.apache.flink.shaded.netty4.io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:241)
at org.apache.flink.shaded.netty4.io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:119)
... 6 more
为便于理解，我们说：
flink-taskmanager-b6f46f6c8-gcxnm分别为TM1和
flink-taskmanager-b6f46f6c8-fgtlw为TM2
在调试时，我发现 TM1从TM2请求ResultPartition (RPP)，并且TM2开始将ResultPartition发送到TM1 。但是在检查 TM1 中的日志时，我们发现它等待了很长时间才能从TM2中获取RP ，但是一段时间后它开始注销已接受的任务。我们认为，在Netty远程传输异常导致TM2针对特定作业发送Lost Taskmanager错误之后，取消注册任务。
两个任务管理器都在单独的ec2实例（m4.2xlarge）中运行。我已经验证了两个实例的 cpu和内存使用率，并且能够看到限制范围内的所有指标。
能否请您告诉我为什么taskmanager如此奇怪并解决此问题的方法。
预先感谢
答案 0 :(得分：1)
在上图中，基于信用的流控制机制实际上位于“ Netty Server”（和“ Netty Client”）组件内部，并且RecordWriter写入的缓冲区始终以空状态添加到结果子分区中然后逐渐填充（序列化）记录。但是Netty何时真正获得缓冲？显然，只要有可用字节就不能占用字节，因为这不仅会由于跨线程通信和同步而增加可观的成本，而且会使整个缓冲区过时。
在Flink中，有三种情况使Netty服务器可以使用缓冲区：
向其中写入记录时，缓冲区已满，或者 缓冲区超时命中，或 发送特殊事件，例如检查点障碍。
RecordWriter与当前记录的本地序列化缓冲区一起使用，并将逐步将这些字节写入位于适当结果子分区队列中的一个或多个网络缓冲区。尽管RecordWriter可以在多个子分区上工作，但是每个子分区只有一个RecordWriter向其中写入数据。另一方面，如上所述，Netty服务器正在从多个结果子分区中读取并将适当的子分区多路复用到单个通道中。这是一个经典的生产者-消费者模式，中间是网络缓冲区，如下图所示。 （1）序列化并（2）将数据写入缓冲区后，RecordWriter会相应地更新缓冲区的作家索引。缓冲区完全填满后，记录编写器将（3）从其本地缓冲池中为当前记录的所有剩余字节（或下一记录）获取一个新缓冲区，并将新的缓冲区添加到子分区队列中。如果尚不知道，这将（4）通知Netty服务器可用数据。只要Netty有能力处理此通知，它将（5）提取缓冲区并通过适当的TCP通道发送。
如果队列中还有更多完成的缓冲区，我们可以假定它已经收到通知。
为了支持低延迟用例，我们不能仅依靠缓冲区已满来向下游发送数据。在某些情况下，某些通信通道可能没有太多的记录流过，从而不必要地增加了您实际拥有的几条记录的等待时间。因此，定期处理将刷新堆栈中可用的所有数据：输出刷新器。周期间隔可以通过StreamExecutionEnvironment＃setBufferTimeout进行配置，并充当延迟5的上限（对于低吞吐量通道）。下图显示了它如何与其他组件交互：RecordWriter像以前一样序列化并写入网络缓冲区，但同时，如果Netty尚不知道，则输出刷新程序可以（3,4）通知Netty服务器可用数据（类似到上面的“缓冲区已满”方案）。 Netty处理此通知（5）时，它将使用缓冲区中的可用数据并更新缓冲区的读取器索引。缓冲区保留在队列中-Netty服务器端对该缓冲区的任何进一步操作将在下一次继续从读取器索引中读取。
参考：
下面的链接可能会帮助您。
答案 1 :(得分：0)
您能否检查 TM1 和 TM2 的GC日志，以查看是否存在完整的GC，这可能会导致热跳超时。
