> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/installation/tuning.md).

# Configuration tuning reference

The cache, batch, pool and rate-limit properties OpenIAM exposes for tuning, with their shipped defaults and the property file each one lives in.

OpenIAM exposes a number of **tuning properties** that control cache-refresh intervals, thread-pool sizes, batch sizes, and rate limits across its services. The defaults are sensible for most deployments, and **you should not change them without a specific reason** — most performance issues are better addressed by right-sizing the database and infrastructure first. This page gathers the properties in one place so that, when tuning is genuinely needed, you can find the correct knob and its default.

{% hint style="warning" %}
**This page carries no `appliesTo` or `lastReviewed` because it has not been checked against 2026.8.1.** It was written for an earlier release and is restored here with only its links updated. The property names and defaults were correct when written and are unlikely to have moved, but confirm a value against your own deployment before you change it.

**Sizing for expected load is not here** — that guidance does not exist in this documentation yet. For a capacity question, talk to OpenIAM support. Memory is covered directly below.
{% endhint %}

## Service memory

**No OpenIAM service sets `-Xmx`.** Neither the RPM service definitions nor the Kubernetes chart carries a heap flag, so each JVM sizes its own heap from the memory limit of the container it runs in. The lever is therefore the **container memory limit**, not a JVM option — raising a limit gives the service more heap, and there is no separate heap setting to keep in step with it.

Only some services declare a limit. Anything not listed inherits whatever the namespace or cluster applies.

**RPM** — `conf/starter/services/` in the deployment:

| Service           | Memory limit | Defined in              |
| ----------------- | ------------ | ----------------------- |
| `esb`             | `2560m`      | `backend-services.yaml` |
| `ui`              | `4096m`      | `ui.yaml`               |
| `auth-manager`    | `614m`       | `backend-services.yaml` |
| `idm`             | `614m`       | `backend-services.yaml` |
| `groovy_manager`  | `614m`       | `backend-services.yaml` |
| `synchronization` | `614m`       | `backend-services.yaml` |

**Kubernetes** — the `openiam` chart's `values.yaml`, under each service's `resources.limits`:

| Service                 | Memory limit |
| ----------------------- | ------------ |
| `ui`                    | `1024Mi`     |
| `audit_log_manager`     | `768Mi`      |
| `batch_task_manager`    | `640Mi`      |
| `certification_manager` | `640Mi`      |
| `privacy_manager`       | `640Mi`      |
| `http_source_adapter`   | `128Mi`      |

The two lists name different services, and different values for the one they share — `ui` is `4096m` under RPM and `1024Mi` on Kubernetes. Read the list for the shape you are running; do not carry a figure across.

{% hint style="info" %}
These are the shipped defaults, read from the deployment definitions. They are a starting point, not a recommendation for your load — how much a service actually needs depends on your population size and throughput, which is the sizing guidance that does not exist yet.
{% endhint %}

## Where these properties live

The properties are read from the deployed property files under the OpenIAM configuration path, one per service:

| Service                                | Property file                      |
| -------------------------------------- | ---------------------------------- |
| ESB (`openiam-esb`)                    | `openiam.esb.properties`           |
| Authorization Manager (`auth-manager`) | `application.properties`           |
| Webconsole / SelfService UI            | `openiam.ui.properties`            |
| Email Manager                          | (email-manager service properties) |

{% hint style="warning" %}
Several property names contain **historical misspellings** (for example, `anoymous`). These are marked below. Use the property name **exactly as written** — a corrected spelling is not read by the code.
{% endhint %}

## Cache refresh intervals

Most OpenIAM services hold reference data (roles, policies, metadata, content providers, etc.) in an in-memory cache and periodically re-sync it from the database. These `threadsweep` / `sweeptime` properties control **how often that re-sync runs**, in **milliseconds**. Lowering a value makes changes propagate faster at the cost of more database load; raising it does the opposite.

| Property                                             | Default          | Controls                                                   |
| ---------------------------------------------------- | ---------------- | ---------------------------------------------------------- |
| `org.openiam.authorization.manager.threadsweep`      | `300000` (5 min) | Authorization data (roles, groups, resources).             |
| `org.openiam.authorization.manager.menu.threadsweep` | `300000` (5 min) | Menu tree.                                                 |
| `org.openiam.policy.threadsweep`                     | `30000` (30 s)   | Policies (authentication, password).                       |
| `org.openiam.metadata.threadsweep`                   | `300000` (5 min) | Metadata types.                                            |
| `org.openiam.content.provider.threadsweep`           | `300000` (5 min) | Content providers.                                         |
| `org.openiam.entitlements.threadsweep`               | `30000` (30 s)   | Entitlements.                                              |
| `org.openiam.org.manager.threadsweep`                | `300000` (5 min) | Organizations.                                             |
| `org.openiam.property.value.threadsweep`             | `30000`–`300000` | System property values (30 s in the ESB, 5 min in the UI). |
| `org.openiam.audit.threadsweep`                      | `30000` (30 s)   | Audit log flush interval.                                  |
| `org.openiam.prov.threadsweep`                       | `10000` (10 s)   | Provisioning queue processing.                             |
| `org.openiam.am.uri.federation.threadsweep`          | `30000` (30 s)   | URI federation cache.                                      |
| `org.openiam.federation.ai.threadsweep`              | `30000` (30 s)   | Federation authentication-identity cache.                  |
| `org.openiam.language.provider.threadsweep`          | `300000` (5 min) | Languages.                                                 |
| `org.openiam.cookie.cryptor.threadsweep`             | `300000` (5 min) | Cookie encryption keys.                                    |
| `org.openiam.lucene.reindex.threadsweep`             | `300000` (5 min) | Lucene reindex check.                                      |
| `org.openiam.idm.managed.sys.cache.sweeptime`        | `60000` (1 min)  | Managed system cache (ESB).                                |
| `org.openiam.managed.sys.cache.sweeptime`            | `300000` (5 min) | Managed system cache (UI).                                 |
| `org.openiam.metadata.cache.sweeptime`               | `120000` (2 min) | Metadata cache (UI).                                       |
| `org.openiam.idm.groovy.cache.sweeptime`             | `300000` (5 min) | Groovy script cache (UI).                                  |

## Authorization Manager caches

The Authorization Manager keeps a local (in-process) and a remote (Redis) entitlements cache, plus the graph-ID and edge-ID caches that map OpenIAM entities to their vertices/edges. TTL values here are in **minutes**; sweep times are in **milliseconds**. For the surrounding graph architecture, see [Rebuild the authorization graph](/administration-guide/operations/rebuild-the-authorization-graph.md).

| Property                                                        | Default            | Controls                                               |
| --------------------------------------------------------------- | ------------------ | ------------------------------------------------------ |
| `org.openiam.authorization.manager.cache.local.ttl.minutes`     | `30`               | Local (in-process) entitlements cache TTL.             |
| `org.openiam.authorization.manager.cache.remote.ttl.minutes`    | `60`               | Remote (Redis) entitlements cache TTL.                 |
| `org.openiam.authorization.manager.cache.hit.ttl.minutes`       | `60`               | Cache-hit entry TTL.                                   |
| `org.openiam.authorization.manager.cache.concurrency.level`     | `50`               | Cache concurrency level (expected concurrent writers). |
| `org.openiam.authorization.manager.cache.maximum.size`          | `10000`            | Maximum number of cached entries.                      |
| `org.openiam.authorization.manager.graph.operation.retry.count` | `3`                | Retry count for a failed graph operation.              |
| `org.openiam.graph.id.threadsweep`                              | `300000` (5 min)   | Graph-ID cache refresh.                                |
| `org.openiam.edge.id.threadsweep`                               | `300000` (5 min)   | Edge-ID cache refresh.                                 |
| `org.openiam.graph.cache.sweep.time`                            | `60000` (1 min)    | Graph-ID cache sweeper.                                |
| `org.openiam.edge.cache.sweep.time`                             | `60000` (1 min)    | Edge-ID cache sweeper.                                 |
| `org.openiam.graph.locale.cache.sweep.time`                     | `300000` (5 min)   | Locale cache sweeper.                                  |
| `org.openiam.entitlements.objects.cache.consumer.sweep.time`    | `150000` (2.5 min) | Entitlement-objects cache (consumer side).             |
| `org.openiam.entitlements.objects.cache.producer.sweep.time`    | `300000` (5 min)   | Entitlement-objects cache (producer side).             |
| `org.openiam.graph.id.rabbitmq.fanout.fix.threadsweep`          | `30000` (30 s)     | Graph-ID fanout consistency fix.                       |

## Entitlement and graph processing

These control how the authorization graph is built and how full-entitlement recomputes are parallelized. Increase the pool sizes on capable hardware if a full graph rebuild or a large recompute is slow; reduce them under memory pressure.

| Property                                               | Default | Controls                                                                           |
| ------------------------------------------------------ | ------- | ---------------------------------------------------------------------------------- |
| `org.openiam.graph.batch.size`                         | `100`   | Number of vertices/edges written to the graph database per batch during a rebuild. |
| `org.openiam.full.entitlement.executor.core.pool.size` | `100`   | Core worker threads for full-entitlement recompute.                                |
| `org.openiam.full.entitlement.executor.max.pool.size`  | `250`   | Maximum worker threads for full-entitlement recompute.                             |

## Email throttling

| Property                     | Default | Controls                                                                                                                                                                                                                                                        |
| ---------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `org.openiam.mail.send.rate` | `100`   | Delay in **milliseconds** inserted between consecutive outbound emails. This throttles the send loop so a burst of notifications does not overwhelm the SMTP relay. Raise it if your relay rate-limits or rejects bursts; lower it (toward `0`) to send faster. |

## OTP anti-abuse limits

These limit how many one-time passwords a caller can request, protecting the SMS/email providers from abuse and cost overruns.

| Property                                | Default          | Controls                                                                                                               |
| --------------------------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `org.openiam.otp.anoymous.max.requests` | `3`              | Maximum OTP requests an **anonymous** user may make within the throttling window. **Note the spelling `anoymous`.**    |
| `org.openiam.otp.max.requests.minutes`  | `10`             | The throttling window, in minutes, over which the request count above is enforced.                                     |
| `org.openiam.otp.anoymous.cleanup.time` | `300000` (5 min) | Sweep interval (ms) that purges expired entries from the anonymous-OTP throttle map. **Note the spelling `anoymous`.** |
| `org.openiam.ui.otp.max.resend`         | `3`              | Maximum number of OTP resends offered to the user in the UI.                                                           |

## Groovy script cache

| Property                          | Default         | Controls                                                                                                                                                                                |
| --------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `org.openiam.groovy.cache.ttl.ms` | `60000` (1 min) | Time a compiled Groovy script is cached before it is recompiled from source. Lower it while actively developing scripts so edits take effect sooner; the default is fine in production. |

## Tuning knobs documented elsewhere

Several tuning properties are documented on the pages of the feature they belong to:

* **Reconciliation batch sizes** (`org.openiam.recon.search.batch.size`, `org.openiam.recon.batch.size.user.count`, `org.openiam.recon.batch.size.group.count`) — see [Configure reconciliation](/administration-guide/lifecycle/configure-reconciliation.md).
* **Synchronization batch size** (`Records count in one batch`) — see [Set up a synchronization](/administration-guide/lifecycle/synchronize-and-import-data.md).
* **Workflow (Activiti) JDBC pool** (`org.openiam.idm.activiti.jdbc.max.active.connections`) — see [System configuration](/administration-guide/platform/system-configuration.md).
* **Certification preview executor pools** (`org.openiam.certification.preview.executor.*`) — see [Plan and scope a campaign](/administration-guide/governance/certification/plan-and-scope-a-campaign.md).
* **Connector RabbitMQ consumer tuning** — set on the connector itself, not in these files. Consult OpenIAM support for the consumer counts appropriate to your throughput.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/installation/tuning.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.