]
Galder Zamarreño commented on ISPN-1383:
----------------------------------------
One optimisation possible here is to get rid of the rawValue in the decoder once it's
dealt with it. This is a mere reference though as indicated by latest heaps I've seen,
so it shouldn't take up space.
The second optimisation would be to clear and shrink the underlying buffer of the
cumulative buffer used by the replaying decoder. I don't see any easy of doing this,
so I've pinged Trustin to see if he has any ideas around this.
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.BETA1, 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.
For more information on JIRA, see: