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

Buffer size #344

Open
IgorMamushin opened this issue Jan 20, 2018 · 14 comments
Open

Buffer size #344

IgorMamushin opened this issue Jan 20, 2018 · 14 comments

Comments

@IgorMamushin
Copy link

My application "eats" 22 MB per client. I found that this is because of the giant buffer size (16777216). How can I set the buffer size?

@StormHub
Copy link
Contributor

That is the default global buffer pool (16 MB) shared by all channels and handlers. If you switch on debug logging, all the heap parameters are reported when DotNetty starts.

@IgorMamushin
Copy link
Author

IgorMamushin commented Jan 21, 2018

If it is global, is it normal that it is created for each client?
And after disconnecting the client, the buffer continues to hang in the memory, causing a leak

@StormHub
Copy link
Contributor

The global buffer pool lasts for the life time of the application and shared across all channels.

@IgorMamushin
Copy link
Author

Okay, I did ChannelOption.Allocator, UnpooledByteBufferAllocator.Default. But the memory is not released after the client is turned off. What can I do?

@StormHub
Copy link
Contributor

The global buffer pool lasts for the entire lifetime of the applications. The idea is to eliminate the GC pressure to improve performance. This is by design. You can tune the size down a bit though.

@nayato
Copy link
Member

nayato commented Jan 22, 2018

what do you mean by this?

memory is not released

If you're not accessing pooled allocator, it should not be used at all and should not allocate. What memory are you referring to here?

@IgorMamushin
Copy link
Author

I meant a memory leak. The buffer is not destroyed with the client turned off. Even if I use UnpooledByteBufferAllocator

@yyjdelete
Copy link
Contributor

yyjdelete commented Jan 25, 2018

@fler
Call this before your first call to DotNetty, on static init of class or somewhere else.
Environment.SetEnvironmentVariable("io.netty.allocator.type", "unpooled");
https://github.com/Azure/DotNetty/blob/dev/src/DotNetty.Buffers/ByteBufferUtil.cs#L19-L42

Or use the below code to lower the memory used by PooledByteBufferAllocator.
Environment.SetEnvironmentVariable("io.netty.allocator.maxOrder", "5");

@nayato
Copy link
Member

nayato commented Mar 21, 2018

@fler could you pls check what holds the buffer? I.e. take a process dump and inspect path to root for the buffer.

@goncalo-oliveira
Copy link

@fler did you manage to solve this issue? I'm also seeing memory not being released after a client disconnects and not being reused.

@goncalo-oliveira
Copy link

Here's what I can see in taking memory in the heap:

  • DotNetty.Buffers.PoolThreadCache+MemoryRegionCache+Entry<Byte[]>[]
  • DotNetty.Common.Internal.MpscArrayQueue<DotNetty.Buffers.PoolThreadCache+MemoryRegionCache+Entry<Byte[]>>
  • DotNetty.Buffers.PoolThreadCache+SubPageMemoryRegionCache<Byte[]>

There's also a big chunk on Action items, being referenced by DotNetty.Common.Concurrency.XThread+<>c__DisplayClass10_0 via DotNetty.Common.Concurrency.XParameterizedThreadStart, which is a bit weird.

I tried setting io.netty.allocator.maxOrder=5 along with io.netty.allocator.type=unpooled and had no change. Also tried `io.netty.noPreferDirect=true', same result.

It's kind of frustrating, as a chunk is allocated every time a new connection comes in, but it isn't released when the connection drops.

Manual calls to the garbage collector don't produce any results either.

@goncalo-oliveira
Copy link

Through the memory dumps, I traced it to here

0:1051> !dumpheap -stat
...
00007fff6a0150f8       75      1230600 System.ArraySegment`1[[System.Byte, System.Private.CoreLib]][]
...

0:1051> !gcroot 2858da22a58
HandleTable:
    000002858bb2ae20 (strong handle)
    -> 000002858d9ff710 System.Object[]
    -> 000002858d9ff988 DotNetty.Common.InternalThreadLocalMap
    -> 000002858d9ffa08 System.Object[]
    -> 000002858da004b0 System.Collections.Generic.List`1[[System.ArraySegment`1[[System.Byte, System.Private.CoreLib]], System.Private.CoreLib]]
    -> 000002858da22a58 System.ArraySegment`1[[System.Byte, System.Private.CoreLib]][]

This is using unpooled allocator.

nshCore added a commit to catalyst-network/Catalyst that referenced this issue Mar 25, 2019
@MetSystem
Copy link

The same question, is there a solution?

@FabianHummel
Copy link

5 years later and it still is not fixed. Why does the memory stay allocated after the connection is dropped? Any solutions?

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

No branches or pull requests

7 participants