Memory accumulated in netty PoolChunk

Question

Hi i'm trying to understand why so memory consumption in my app so i have downloaded a heapdump with visualjvm and then have analysed it with eclipse mat. It have found the following problem:

One instance of "io.netty.buffer.PoolChunk" loaded by "jdk.internal.loader.ClassLoaders$AppClassLoader @ 0x7f04ba5b0" occupies 16,793,832 (32.78 %) bytes. The memory is accumulated in one instance of "byte[]" loaded by "<system class loader>".

Could anybody give me some advice on how to fix this issue? What data to look and search for?

My first try was to set -Dio.netty.allocator.type=unpooled param, this have removed this problem suspect related to bytes, but introduced others 2 related to class loaders.

Regards

Mezereum

were you able to solve this issue? – Wartburg

Yep, this was not an issue as explained below. It is how netty allocates memory for ByteBuf when using pool ByteBufAllocator. – Mezereum

But how did you solve it? – Yokoyokohama

How this issue was solved? – Demotic

to disable that behaviour you could play with "-Dio.netty.allocator.type=unpooled", – Mezereum

@Mezereum You mentioned that -Dio.netty.allocator.type=unpooled resolved the problem related to bytes but introduced another 2 related to class loaders. What problems with class loaders did you face exactly? – Granger

Answer 1

Netty uses a pooled ByteBufAllocator by default which allocates memory in "chunks". That what you see here. So it basically allocates a chunk and then slice out memory of this chunk when it needs memory. Once cant fullfill the memory need a new chunk is allocated and so on.

Indreetloire

Answer 2

Adding -Dio.netty.allocator.type=unpooled showed significant reduction in the memory

regarding performance both with and unpooled and pooled performed similar in our case

but little spike in GC - but overall unpooled had better response time

Ma