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

PinnedBuffer causes large heap when used continuously for reading #2100

Open
wiktork opened this issue Aug 23, 2024 · 1 comment
Open

PinnedBuffer causes large heap when used continuously for reading #2100

wiktork opened this issue Aug 23, 2024 · 1 comment

Comments

@wiktork
Copy link
Member

wiktork commented Aug 23, 2024

We are collecting and reading a continuous session of trace data (in this case logs and metrics) from EventSource using TraceEvent. While this works correctly, and strictly speaking there is no memory leak, we are seeing a very large amount of PinnedBuffer objects, with pinned memory regions. This in turn causes the GC operations to not be able to compact memory properly and as a result the heap size increases. Most of the heap is free space.

Ideally, we would want PinnedBuffers to be determinstically cleaned up (unpinned) or use a pool of pinned buffers that gets rented and diposed as necessary, instead of constantly allocating a new pinned buffer.

Some RAW GC data

!dumpheap -type PinnedBuffer

Statistics:
          MT Count TotalSize Class Name
7137a85bfbb8 2,071    66,272 Microsoft.Diagnostics.Tracing.EventPipe.PinnedBuffer
Total 2,071 objects, 66,272 bytes

!gchandles -type pinned

Statistics:
              MT    Count    TotalSize Class Name
00007137a37e5ac8        1           24 System.Object
00007137a3a893f0      978      4528747 System.Byte[]
Total 979 objects

@wiktork
Copy link
Member Author

wiktork commented Aug 23, 2024

Thanks to @Maoni0 for the analysis, thanks to @noahfalk for the fix suggestion

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

1 participant