We are using a standalone single node installation of Hazelcast 3.3.5 for storing some user's session info both logged and not logged users.
The map in wich we store the not logged sessions is set like that:
Monitoring with Mancenter we see that the number of entries is stable around 9.500 but "Entry Memory" grows progressively... When Hazelcast is restarted both "Entries" and "Entry Memory" values are "0" then when "Entries" reaches the top of 9500 "Entry Memory" value is 37MB. So far so rigth. 24 hours later, the number of "Entries" is still the same so Eviction Policy is working fine but "Entry Memory" value is 160MB and growing until Hazelcast throws an OutOfMemory exception.
Is there something wrong in our configuration? It seems like GC is unable to free the memory of the removed entries.
Any ideas?
Thanks in advance
I naively tried to use Hazelcast as my primary data storage - replacing a database. Everything was good until I put 40K of 1K records into one of the maps. The first thing I noticed monitoring it in the ManCenter is how much memory it uses for queries. It goes down after the query, but I suspect there is a memory leak or it keeps some data cached to avoid deserialization for future queries. So I made sure I explicitly disabled all near-caches and similar internal caches inside Hazelcast. Explicit e.g. Portable serialization helps to reduce the memory footprint. Look at internal storage format too. 37M for 10K records is pretty high anyway, but that's a separate architecture issue of keeping the session/user context small (under 15K) - storing only the relevant info.
Again, I use it as a database, not cache, so I don't have any eviction. Maybe there is indeed a bug (memory leak) there. I'd try to test it w/o eviction/TTL.