> 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/troubleshooting/performance/redismemory.md). # Redis memory utilization Reading what the Redis cache is using, whether it has a memory cap, and what the broker does when it reaches one. | Symptom | Likely cause | Resolution | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------- | | The host is running short of memory and Redis is a suspect | The cache has grown, and on a deployment with no cap it grows until the host is full | Read `used_memory_human` and `maxmemory` below | | Writes to the cache fail while Redis is still running | Redis has reached its cap under a policy that refuses writes rather than evicting | Read `maxmemory_policy` below | ## Read the memory figures Redis needs its password, which lives in the secret store rather than in a file: {% code overflow="wrap" %} ```bash sudo /usr/local/openiam/utils/vault/vault.fetch.property.sh vault.secret.redis.password ``` {% endcode %} Then ask Redis for its memory section: {% code overflow="wrap" %} ```bash redis-cli -a info memory ``` {% endcode %} {% hint style="warning" %} **A password given with `-a` is visible to anyone who can list processes, and lands in your shell history.** Redis warns about it on every invocation. On a shared host, export it to the environment for the command rather than typing it inline, and clear the history entry afterwards. {% endhint %} ### The four fields worth reading The output is long. These are the ones that answer a memory question: | Field | What it tells you | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `used_memory_human` | What the cache is holding now | | `maxmemory` | The cap. **`0` means no cap** — Redis will grow until the host has nothing left | | `maxmemory_policy` | What happens at the cap. `noeviction` **refuses writes** rather than making room; `allkeys-lru` discards the least recently used keys instead | | `mem_fragmentation_ratio` | Allocated against what the OS sees. Comfortably above 1 means memory is held but not usefully used | {% hint style="info" %} **The policy is not the same on every deployment.** The Kubernetes charts set `allkeys-lru`, so the cache evicts and keeps serving. A deployment reporting `maxmemory:0` with `noeviction` has neither a cap nor an eviction strategy — it will grow unbounded, and then fail writes rather than shed data. Read your own output rather than assuming either. {% endhint %} {% code overflow="wrap" expandable="true" %} ``` used_memory:3269568 used_memory_human:3.12M used_memory_rss:16863232 used_memory_rss_human:16.08M used_memory_peak:4749904 used_memory_peak_human:4.53M used_memory_peak_perc:68.83% used_memory_overhead:2549598 used_memory_startup:791016 used_memory_dataset:719970 used_memory_dataset_perc:29.05% allocator_allocated:3356656 allocator_active:4268032 allocator_resident:9441280 total_system_memory:33506660352 total_system_memory_human:31.21G used_memory_lua:53248 used_memory_lua_human:52.00K used_memory_scripts:6520 used_memory_scripts_human:6.37K number_of_cached_scripts:7 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:1.27 allocator_frag_bytes:911376 allocator_rss_ratio:2.21 allocator_rss_bytes:5173248 rss_overhead_ratio:1.79 rss_overhead_bytes:7421952 mem_fragmentation_ratio:5.22 mem_fragmentation_bytes:13634680 mem_not_counted_for_evict:0 mem_replication_backlog:0 mem_clients_slaves:0 mem_clients_normal:1741894 mem_aof_buffer:0 mem_allocator:jemalloc-5.1.0 active_defrag_running:0 lazyfree_pending_objects:0 ``` {% endcode %} ## Watch it over time A single reading does not show whether the cache is growing. `--stat` prints a line a second: {% code overflow="wrap" %} ```bash redis-cli -a --stat ``` {% endcode %} {% code overflow="wrap" %} ``` ------- data ------ --------------------- load -------------------- - child - keys mem clients blocked requests connections 152 3.20M 105 0 76133 (+0) 488 152 3.24M 105 0 76135 (+2) 488 152 3.20M 105 0 76136 (+1) 488 152 3.32M 105 0 76156 (+20) 488 ``` {% endcode %} `keys` and `mem` holding steady while `requests` climbs is a cache working normally. `mem` climbing without `keys` climbing is fragmentation or growing values rather than more entries. --- # 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/troubleshooting/performance/redismemory.md?ask=&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.