Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suspected memory leak in KafkaThrottledLatestProcessedCommit #2623

Open
tilakchowdary opened this issue May 17, 2024 · 13 comments
Open

Suspected memory leak in KafkaThrottledLatestProcessedCommit #2623

tilakchowdary opened this issue May 17, 2024 · 13 comments
Labels

Comments

@tilakchowdary
Copy link

tilakchowdary commented May 17, 2024

I have observed that our heap slowly increasing with KafkaThrottledLatestProcessedCommit

Here is the heap map
Screenshot 2024-05-17 at 1 54 35 PM
Any inputs are greatly appreciated

@cescoffier
Copy link
Contributor

We would need to see the application. There is a poison pill mechanism that makes sure we do not accumulate too much.

So make sure your messages are acknowledged.

@ozangunalp
Copy link
Collaborator

Yes, probably your messages are not acknowledged properly, so not cleared from tracked messages.

@tilakchowdary
Copy link
Author

@cescoffier @ozangunalp Thanks for the suggestion. As I understand if it was due to messages are not being acknowledged properly it would result in TooManyMessagesWithoutAckException. However, In our case we don't see this issue and we see uninterrupted records consumption. From heap analysis only the processedOffsets field was leaking.
I suspect concurrency usage of KafkaThrottledLatestProcessedCommit.
Methods processed(long offset) and clearLesserSequentiallyProcessedOffsetsAndReturnLargestOffset() - Calling these concurrently by multiple threads resulting inconsistent view of processedOffsets.

@cescoffier
Copy link
Contributor

Aren't these methods getting called from event loops ?

@tilakchowdary
Copy link
Author

@cescoffier Thanks for clarification. Yes they are. Now I am not sure where is the issue. Will try to come up with a test case.

@ozangunalp
Copy link
Collaborator

If you've specific logs linked to this issue it can be handy. Otherwise, I don't see why this might happen.

@cescoffier
Copy link
Contributor

@ozangunalp maybe if concurrency > 2, so multiple event loops. But still, should not lead to a leak.

@ozangunalp
Copy link
Collaborator

I've thought of that, but with concurrency > 2 sub-channels have their own copy of the commit handler and their own context acting on tracked records.

@cescoffier
Copy link
Contributor

Yeah, that's what I just saw.

@tilakchowdary
Copy link
Author

I think issue is that with IncomingKafkaRecordBatch only latestOffsetRecords of that batch are stored in OffsetStore.receivedOffsets and subsequently removed from processedOffsets. But processedOffsets will have all Offsets not just the latestOffsetRecords.

@ozangunalp
Copy link
Collaborator

I'll verify batch consuming for leaks. Are you acking individual messages and not the batch as a whole?

@tilakchowdary
Copy link
Author

@ozangunalp Yes acking individual messages

@ozangunalp
Copy link
Collaborator

I didn't have time to reproduce this but acking individual messages in batch mode should be the reason for Offset tracking not getting cleaned

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants