Народ всем привет. В Kafka есть механизм Incremental FetchRequests описанный в

KIP-227 (https://cwiki.apache.org/confluence/display/KAFKA/KIP-227%3A+Introduce+Incremental+FetchRequests+to+Increase+Partition+Scalability).

Столкнулся с такой проблемой, что один из клиентов полностью забивает весь пул сессий (NumIncrementalFetchSessions) и в логи валится FETCH_SESSION_ID_NOT_FOUND и большой рейт evictions из кеша этих самых сессий.

Как можно найти клиента, который создает проблему?

Не ужели я один такой? Уверен, что многие сталкиваются с подобной ситуацией. Никто не задавался вопросом как найти “плохого” кансюмера. Подскажите, если кто знает, хотя бы в каком направлении можно двигаться 🙂

встречал такую ошибку на гошном клиенте sarama. Проблема решилась обновлением клиента по комментам на стековерфлоу. Если не найдешь, кто некорректно закрывает соединения, увеличивай параметр на брокерах max.incremental.fetch.session.cache.slots

Ну вот очень не хочется менять настройки не разобравшись. Клиентов гошных первым делом проверили. Спасибо за идеи.

А какие значения у вас для max.incremental.fetch.session.cache.slots ? Сколько партиций в кластере? Я сейчас эксперимента ради выставил 150к при < 1000 партициях и чувствую, что оно также в потолок упрется :(

я выставлял 10к на одном кластере, на котором впервые заметил проблему. После выставления ошибки до конца не ушли, их просто стало меньше. Дальше с этой настройкой уже не экспериментировал, вернул обратно по дефолту, тк после обновления клиента ошибки ушли полностью. Один товарищ тут писал, что он чуть ли не в миллион этот параметр выкручивает Интересует кол-во партиций всего на кластер со всех топиков или только топика, к которому подключался проблемный клиент? Партиций немного, десяток на топик. На кластер меньше сотни

Если увеличение размера не решило проблему, то кол-во топиков не важно :) Пожалуй перечитаю документацию ещё раз, может оно работает не так как я думаю. Спасибо за участие в дискуссии, если появятся новые идеи, дайте знать.