javahazelcastdistributed-cachingdistributed-cachehazelcast-imap

How does hazelcast perform map entry eviction, in terms of its threading model?


I understand that <min-eviction-check-millis> in hazelcast configuration defines the minimum time in milliseconds which should pass before checking if a partition of this map is evictable or not. So during every configured interval, eviction will be performed in the map as per the configured eviction-policy. I have the following questions related to this area.

Q1. Does the eviction operation run on the operation thread ?

Q2. Will the eviction operation put a lock on the entire partition it is working on ?

Q3. Do I need to expect any performance hit, if I'm to follow the default value of 100ms, (which I believe is a very small value).

Q4. How often will be the eviction operation carried out in the following scenario.

<map name="employees">
    <in-memory-format>BINARY</in-memory-format>
    <backup-count>1</backup-count>
    <max-idle-seconds>1800</max-idle-seconds>
    <eviction-policy>NONE</eviction-policy>
    <time-to-live-seconds>0</time-to-live-seconds>
    <min-eviction-check-millis>1000</min-eviction-check-millis>
    <max-size>0</max-size>
    <eviction-percentage>0</eviction-percentage>
    <merge-policy>com.hazelcast.map.merge.PutIfAbsentMapMergePolicy</merge-policy>

</map>

Note that although there is no eviction policy and percentage configured, max-idle time is set to 1800 seconds.

Answers to the above questions will help me to take an informed decision about the values to be used for these configurations in a large scale deployment.


Solution

  • min-eviction-check-millis is attribute about max-size policy and eviction due to max-size. If you set min-eviction-check-millis=0; then partition thread will check the size on every update. If you set min-eviction-check-millis=1000; then partition thread will check the size on updates if the previous check was earlier than 1 second.

    If you want your map to obey max-size policy more strictly then set it 0. But it will have a overhead of checking the size on every update.

    Q1. Does the eviction operation run on the operation thread ?

    It runs on partition threads. Partition threads executes partition based operations (map.put, map.get, map.remove etc).

    Q2. Will the eviction operation put a lock on the entire partition it is working on ?

    Not an explicit lock. But while partition thread is executing the eviction operation, other operations on this partition will be blocked.

    Q3. Do I need to expect any performance hit, if I'm to follow the default value of 100ms, (which I believe is a very small value).

    It is a size check, but yes it is a overhead.If you tolerate your map exceed max-size; then you can set higher values.

    Q4. How often will be the eviction operation carried out in the following scenario.

    You have not set eviction-policy in this config. So max-size will not be checked. min-eviction-check-millis or max-size have no effect here.

    max-idle-seconds (also ttl) is a different story. We call it expiration. Every get operation first checks if entry is expired. But also periodically; some entries are selected randomly and checked if they are expired. Expired entries are removed.