You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Darrel Schneider (JIRA)" <ji...@apache.org> on 2019/04/24 23:49:00 UTC

[jira] [Created] (GEODE-6705) client/server messaging can allocate a large amount of memory when serializing small parts

Darrel Schneider created GEODE-6705:
---------------------------------------

             Summary: client/server messaging can allocate a large amount of memory when serializing small parts
                 Key: GEODE-6705
                 URL: https://issues.apache.org/jira/browse/GEODE-6705
             Project: Geode
          Issue Type: Improvement
          Components: client/server
            Reporter: Darrel Schneider


As each part of a client/server message is added to the part array on Message, if it is an object that needs to be serialized it creates a HeapDataOutputStream and tells it to have an initial heap ByteBuffer of size "chunkSize" which defaults to 1024. This buffer ends up hanging around in the part list until the Message is actually sent. The reason for this was to prevent do extra copying of the serialized data. The HeapDataOutputStream could have been asked to convert its data to a byte array that is just big enough for the serialized data but this would have copied the data. But leaving it in the original buffer causes that buffer to live longer risking its promotion by the garbage collector.
I see server's trying to send back to the client a pr put reply that should be pretty small since it does not include the old value. But it does have a version tag which causes a 1k ByteBuffer to be allocated in the server for every put reply. We may be able to make better estimates of the initial buffer size. For example the put reply code knows it is serializing a version tag and if it has not done that before it could remember the size of the first version tag and use that as the initial size in the future.
We should also consider reusing the heap ByteBuffers. For example in a cache server each ServerConnection thread could have a thread local cache of ByteBuffers that it can reuse.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)