[
https://issues.jboss.org/browse/ISPN-1383?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1383:
----------------------------------------
To clarify, what has been discovered here is two things:
- HotRodDecoder was keeping references to last stored value which was unnecessary once
data had been stored.
- The Netty replaying decoder internal buffer maintained a ever-growing buffer of data
read which made server side memory consumption duplicate. This is now trimmed.
Data caching multiplying memory requirements of Hot Rod server
--------------------------------------------------------------
Key: ISPN-1383
URL:
https://issues.jboss.org/browse/ISPN-1383
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.1.FINAL
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Labels: hotrod, netty
Fix For: 5.1.0.BETA2, 5.1.0.FINAL
Attachments: ByteArrayConsumption.jpg, NettyBufferPathtToGC.jpg
After inserting a 160MB object in Hot Rod, the memory consumption of the server goes
through the roof. The screenshot shows a couple of interesting things:
1. Both the HotRodDecoder and the DataContainer have a byte[] of approx 160mb each. So,
it seems like it's actually two copies of the same byte[]. It's clear though that
only the cache container should have it, and any cache decoder data should be cleared when
the request is completed.
2. Netty's UnsafeDynamicChannelBuffer is still holding to a byte[] of 268MB approx.
Judging by the 2nd screenshot attached, this appears to be belonging to the underlying
ReplayingDecoder. That should also, if possible, be cleared up. I'll have a look
around in the Netty code and maybe ping Trustin.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira