You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The process uses 16 threads. These show that the leakage is in the backing arena. Further analysis shows that most of the arena memory is spent on allocations with sizes higher than 3000.
Allocation tracking of memory track add 3000 20000 1 jdbfly.txt.tar.gz
More investigations is needed.
The text was updated successfully, but these errors were encountered:
My working assumption is that we do not track/clean up redis parser memory. I see lots of memory allocations coming from there.
maybe even we have a bug that causes the parser to allocate more and more.
A dragonfly process slowly grows in RSS while used memory stays stable.
See the attached files:
info log + arena logs:
info_all_101208.txt
arena_101208.txt
arena_backing_101208.txt
The process uses 16 threads. These show that the leakage is in the backing arena. Further analysis shows that most of the arena memory is spent on allocations with sizes higher than 3000.
Allocation tracking of
memory track add 3000 20000 1
jdbfly.txt.tar.gz
More investigations is needed.
The text was updated successfully, but these errors were encountered: