Конфигурации Kafka могут быть довольно сложными. Обычно в Kafka несколько конфигураций могут работать вместе для достижения результата. Это дает гибкость, но за гибкость приходится платить.
Из документации fetch.max.bytes
:
Записи загружаются потребителем партиями, и если первая партия записей в первый непустой раздел выборки больше, чем это значение, пакет записи все равно будет возвращен, чтобы гарантировать, что потребитель может добиться прогресса.
Только на стороне потребителя существуют дополнительные конфигурации, которые следует учитывать для ограничения использования памяти потребителя, включая:
max.poll.records
: ограничивает количество записей, извлекаемых в один призыв к опросу. По умолчанию 500. max.partition.fetch.bytes
: ограничивает количество байтов, выбираемых на раздел. Это не должно быть проблемой, так как по умолчанию это 1 МБ.
Согласно информации в KIP-81 , на практике использование памяти должно быть примерно как min(num brokers * max.fetch.bytes, max.partition.fetch.bytes * num_partitions)
.
Кроме того, в том же KIP:
Потребитель (Сборщик) откладывает распаковку до тех пор, пока записи не будут возвращены пользователю, но из-за max.poll.records это может закончиться удерживая распакованные данные из одного раздела в течение нескольких итераций.
Я бы посоветовал вам также настроить эти параметры, и, надеюсь, это приведет вас в желаемое состояние.