Q:

Accessing Kafka stream's KTable underlying RocksDB memory usage

I have a kafka stream app that currently takes 3 topics and aggregates them into a KTable. This app resides inside a scala microservice on marathon which has been allocated 512 MB memory to work with. After implementing this, I've noticed that the docker container running the microservice eventually runs out of memory and was trying to debug the cause. 
My current theory (whilst reading the sizing guide https://docs.confluent.io/current/streams/sizing.html) is that over time, the increasing records stored in the KTable and by extension, the underlying RocksDB, is causing the OOM for the microservice. Is there any way to find out the memory used by the underlying default RocksDB implementation?

A:

In case anyone runs into a similar issue, setting the environment variable MALLOC_ARENA_MAX=2 seems to have fixed it for me. For a more detailed explanation as to why, please refer to section "Why memory allocators make a difference?" and "Tuning glibc" here: https://github.com/prestodb/presto/issues/8993.

