keycloak-scim/server_installation/topics/cache/eviction.adoc

[[_eviction]]
=== Eviction and Expiration

There are multiple different caches configured for {project_name}.
There is a realm cache that holds information about secured applications, general security data, and configuration options.
There is also a user cache that contains user metadata.  Both caches default to a maximum of 10000 entries and use a least recently used eviction strategy.
Each of them is also tied to an object revisions cache that controls eviction in a clustered setup.
This cache is created implicitly and has twice the configured size. The same applies for the `authorization` cache, which holds
the authorization data. The `keys` cache holds data about external keys and does not need to have dedicated revisions cache. Rather
it has `expiration` explicitly declared on it, so the keys are periodically expired and forced to be periodically downloaded from external clients or
identity providers.

The eviction policy and max entries for these caches can be configured in the _standalone.xml_, _standalone-ha.xml_, or
_domain.xml_ depending on your <<_operating-mode, operating mode>>. In the configuration file, there is the part with infinispan
subsystem, which looks similar to this:

[source,xml,subs="attributes+"]
----
<subsystem xmlns="{subsystem_infinispan_xml_urn}">
    <cache-container name="keycloak">
        <local-cache name="realms">
            <object-memory size="10000"/>
        </local-cache>
        <local-cache name="users">
            <object-memory size="10000"/>
        </local-cache>
        ...
        <local-cache name="keys">
            <object-memory size="1000"/>
            <expiration max-idle="3600000"/>
        </local-cache>
        ...
    </cache-container>
----

To limit or expand the number of allowed entries simply add or edit the `object` element or the `expiration` element of particular cache
configuration.

In addition, there are also separate caches `sessions`, `clientSessions`, `offlineSessions`, `offlineClientSessions`,
`loginFailures` and `actionTokens`. These caches are distributed in cluster environment and they are unbounded in size by default.
If they are bounded, it would then be possible that some sessions will be lost. Expired sessions are cleared internally
by {project_name} itself to avoid growing the size of these caches
without limit. If you see memory issues due to a large number of sessions, you can try to:

* Increase the size of cluster (more nodes in cluster means that sessions are spread more equally among nodes)

* Increase the memory for {project_name} server process

* Decrease the number of owners to ensure that caches are saved in one single place. See <<_replication>> for more details

* Disable l1-lifespan for distributed caches. See Infinispan documentation for more details

* Decrease session timeouts, which could be done individually for each realm in {project_name} admin console. But this could affect
usability for end users. See link:{adminguide_timeouts_link}[{adminguide_timeouts_name}] for more details.

There is an additional replicated cache, `work`, which is mostly used to send messages among cluster nodes; it is also unbounded
by default. However, this cache should not cause any memory issues as entries in this cache are very short-lived.