如何修复：java。lang.OutOfMemoryError：flink kafka消费者中的直接缓冲区内存

Question

我们正在kubernetes上运行一个5节点flink集群（1.6.3），具有5个分区Kafka主题源。从该主题读取5个作业（具有不同的消费组），每个作业的并行度=5。

每个任务管理器都使用10Gb的ram运行，任务管理器堆大小限制为2Gb。摄取负载相当小（每秒100-200 msgs），平均消息大小约为4-8kb。所有作业都可以正常运行几个小时。经过一段时间，我们突然看到一个或多个作业失败：

ava.lang.OutOfMemoryError: Direct buffer memory
    at java.nio.Bits.reserveMemory(Bits.java:666)
    at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
    at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
    at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:241)
    at sun.nio.ch.IOUtil.read(IOUtil.java:195)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
    at org.apache.kafka.common.network.PlaintextTransportLayer.read(PlaintextTransportLayer.java:110)
    at org.apache.kafka.common.network.NetworkReceive.readFromReadableChannel(NetworkReceive.java:97)
    at org.apache.kafka.common.network.NetworkReceive.readFrom(NetworkReceive.java:71)
    at org.apache.kafka.common.network.KafkaChannel.receive(KafkaChannel.java:169)
    at org.apache.kafka.common.network.KafkaChannel.read(KafkaChannel.java:150)
    at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:355)
    at org.apache.kafka.common.network.Selector.poll(Selector.java:303)
    at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:349)
    at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:226)
    at org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:1047)
    at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:995)
    at org.apache.flink.streaming.connectors.kafka.internal.KafkaConsumerThread.run(KafkaConsumerThread.java:257)

flink重新启动作业，但在该异常情况下仍会失败。我们已经尝试减少这里建议的民意调查记录：Kafka消费者扔java。lang.OutOfMemoryError：直接缓冲区内存我们还尝试增加kafka堆的大小，建议如下：Flink kafka，java。并行时lang.OutOfMemoryError

失败的原因可能是什么？我们还应该检查什么？

谢谢

Answer 1

您可能低估了一件事，即并行度为5意味着有5 4 3 2 1=18对组合。如果我们将其与链接线程进行比较，可能有3 2 1=6种组合。

在链接线程中，通过将max poll records设置为250来解决问题，因此我的第一个想法是在这里将其设置为80（甚至设置为10），看看这是否解决了问题。

（我不确定需求是否是这样形成的，但唯一值得注意的区别是从3到5的平行度，因此这似乎是一个很好的补偿点）。