[ https://issues.apache.org/jira/browse/GEODE-6705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Darrel Schneider updated GEODE-6705: ------------------------------------ Labels: performance (was: ) > 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 > Priority: Major > Labels: performance > > 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)