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.
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.