# Memory usage keeps increasing after reaching --maxmemory limit

**URL:** <https://dragonfly.discourse.group/t/memory-usage-keeps-increasing-after-reaching-maxmemory-limit/294>\
**Category:** Dragonfly Technical\
**Created:** [July 14, 2025, 7:42pm UTC](https://dragonfly.discourse.group/t/memory-usage-keeps-increasing-after-reaching-maxmemory-limit/294 "2025-07-14T19:42:17Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![hgorni](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/hgorni/32/116_2.png) [@hgorni](https://dragonfly.discourse.group/u/hgorni)\
**Post date:** [July 14, 2025, 7:42pm UTC](https://dragonfly.discourse.group/t/memory-usage-keeps-increasing-after-reaching-maxmemory-limit/294/1 "2025-07-14T19:42:17Z")

</div>

I recently migrated from Redis to Dragonfly in my production environment, setting an instance with `--cache_mode` and `--maxmemory=160G` . Everything works as expected at first, but as the memory usage approaches the limit, old keys are evicted, yet the **memory usage keeps increasing** instead of stabilizing or decreasing.

**Observed behavior:**

- After restarting the instance, the `.dfs` dump is restored correctly and memory usage drops to normal. But once new writes resume, memory usage starts growing again and eventually exceeds `maxmemory`.
- Running `MEMORY DEFRAGMENT` manually has no visible effect - memory stats don’t change, even if I completely stop new writes.
- Key eviction occurs while writes are active, but stops immediately once I pause writes, even though memory usage remains above the limit.
- After hours of inactivity (no new keys), memory usage remains high and does not reduce.
- I tried increasing `--max_eviction_per_heartbeat` to `200000` (from the default of 100), but that didn’t make a difference.

Here’s how I’m running my Dragonfly instance:

```bash
docker run -d --name "app_cache" \
    --network host \
    --log-driver=gcplogs \
    --log-opt gcp-log-cmd=true \
    -v /data:/data \
    -m "172g" \
    docker.dragonflydb.io/dragonflydb/dragonfly \
    --port "6379" \
    --logtostderr \
    --dir /data \
    --cache_mode
    --maxmemory 160G

```

And these are the instance’s stats:

> 127.0.0.1:6379\> info all
> 
> # Server
> 
> redis\_version:7.4.0  
> dragonfly\_version:df-v1.31.1  
> redis\_mode:standalone  
> arch\_bits:64  
> os:Linux 6.1.0-37-cloud-amd64 x86\_64  
> thread\_count:22  
> multiplexing\_api:epoll  
> tcp\_port:6379  
> uptime\_in\_seconds:3993  
> uptime\_in\_days:0
> 
> # Clients
> 
> connected\_clients:1  
> max\_clients:64000  
> client\_read\_buffer\_bytes:256  
> blocked\_clients:0  
> pipeline\_queue\_length:0  
> send\_delay\_ms:0  
> timeout\_disconnects:0
> 
> # Memory
> 
> **used\_memory:154617454176**  
> **used\_memory\_human:144.00GiB**  
> used\_memory\_peak:154619189920  
> used\_memory\_peak\_human:144.00GiB  
> fibers\_stack\_vms:10256368  
> fibers\_count:157  
> **used\_memory\_rss:176138014720**  
> **used\_memory\_rss\_human:164.04GiB**  
> used\_memory\_peak\_rss:176138014720  
> **maxmemory:171798691840**  
> **maxmemory\_human:160.00GiB**  
> used\_memory\_lua:0  
> object\_used\_memory:96439049648  
> type\_used\_memory\_string:96439049648  
> table\_used\_memory:56645575768  
> prime\_capacity:852799080  
> expire\_capacity:850650360  
> num\_entries:474603534  
> inline\_keys:0  
> small\_string\_bytes:48701660592  
> pipeline\_cache\_bytes:0  
> dispatch\_queue\_bytes:0  
> dispatch\_queue\_subscriber\_bytes:0  
> dispatch\_queue\_peak\_bytes:0  
> client\_read\_buffer\_peak\_bytes:65792  
> tls\_bytes:5664  
> snapshot\_serialization\_bytes:0  
> commands\_squashing\_replies\_bytes:0  
> lsn\_buffer\_size\_sum:0  
> lsn\_buffer\_bytes\_sum:0  
> cache\_mode:cache  
> maxmemory\_policy:eviction  
> replication\_streaming\_buffer\_bytes:0  
> replication\_full\_sync\_buffer\_bytes:0
> 
> # Stats
> 
> total\_connections\_received:426235  
> total\_handshakes\_started:0  
> total\_handshakes\_completed:0  
> total\_commands\_processed:411575  
> instantaneous\_ops\_per\_sec:0  
> total\_pipelined\_commands:0  
> pipeline\_throttle\_total:0  
> pipelined\_latency\_usec:0  
> total\_net\_input\_bytes:55554981821  
> connection\_migrations:0  
> connection\_recv\_provided\_calls:0  
> total\_net\_output\_bytes:7043752  
> rdb\_save\_usec:0  
> rdb\_save\_count:0  
> big\_value\_preemptions:0  
> compressed\_blobs:0  
> instantaneous\_input\_kbps:-1  
> instantaneous\_output\_kbps:-1  
> rejected\_connections:-1  
> expired\_keys:44717  
> evicted\_keys:90086370  
> total\_heartbeat\_expired\_keys:44567  
> total\_heartbeat\_expired\_bytes:4755136  
> total\_heartbeat\_expired\_calls:8634627  
> hard\_evictions:0  
> garbage\_checked:45269533  
> garbage\_collected:150  
> bump\_ups:0  
> stash\_unloaded:4  
> oom\_rejections:0  
> traverse\_ttl\_sec:17887  
> delete\_ttl\_sec:21  
> keyspace\_hits:0  
> keyspace\_misses:0  
> keyspace\_mutations:564734621  
> total\_reads\_processed:1724481  
> total\_writes\_processed:429089  
> huffenc\_attempt\_total:0  
> huffenc\_success\_total:0  
> defrag\_attempt\_total:507013963  
> defrag\_realloc\_total:8012608  
> defrag\_task\_invocation\_total:1417605  
> reply\_count:429089  
> reply\_latency\_usec:0  
> blocked\_on\_interpreter:0  
> lua\_interpreter\_cnt:0  
> lua\_blocked\_total:0  
> lua\_interpreter\_return:0  
> lua\_force\_gc\_calls:0  
> lua\_gc\_freed\_memory\_total:0  
> lua\_gc\_duration\_total\_sec:0
> 
> # Tiered
> 
> tiered\_entries:0  
> tiered\_entries\_bytes:0  
> tiered\_total\_stashes:0  
> tiered\_total\_fetches:0  
> tiered\_total\_cancels:0  
> tiered\_total\_deletes:0  
> tiered\_total\_uploads:0  
> tiered\_total\_stash\_overflows:0  
> tiered\_heap\_buf\_allocations:0  
> tiered\_registered\_buf\_allocations:0  
> tiered\_allocated\_bytes:0  
> tiered\_capacity\_bytes:0  
> tiered\_pending\_read\_cnt:0  
> tiered\_pending\_stash\_cnt:0  
> tiered\_small\_bins\_cnt:0  
> tiered\_small\_bins\_entries\_cnt:0  
> tiered\_small\_bins\_filling\_bytes:0  
> tiered\_cold\_storage\_bytes:0  
> tiered\_offloading\_steps:0  
> tiered\_offloading\_stashes:0  
> tiered\_ram\_hits:0  
> tiered\_ram\_cool\_hits:0  
> tiered\_ram\_misses:0
> 
> # Persistence
> 
> current\_snapshot\_perc:0  
> current\_save\_keys\_processed:0  
> current\_save\_keys\_total:0  
> last\_success\_save:1752515648  
> last\_saved\_file:  
> last\_success\_save\_duration\_sec:0  
> loading:0  
> saving:0  
> current\_save\_duration\_sec:0  
> rdb\_changes\_since\_last\_success\_save:564734621  
> rdb\_bgsave\_in\_progress:0  
> rdb\_last\_bgsave\_status:ok  
> last\_failed\_save:0  
> last\_error:  
> last\_failed\_save\_duration\_sec:0
> 
> # Transaction
> 
> tx\_shard\_polls:0  
> tx\_shard\_optimistic\_total:409898  
> tx\_shard\_ooo\_total:0  
> tx\_global\_total:0  
> tx\_normal\_total:409898  
> tx\_inline\_runs\_total:18655  
> tx\_schedule\_cancel\_total:0  
> tx\_batch\_scheduled\_items\_total:391243  
> tx\_batch\_schedule\_calls\_total:391243  
> tx\_with\_freq:409898,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0  
> tx\_queue\_len:0  
> eval\_io\_coordination\_total:0  
> eval\_shardlocal\_coordination\_total:0  
> eval\_squashed\_flushes:0
> 
> # Replication
> 
> role:master  
> connected\_slaves:0  
> master\_replid:cacbb1d0e0d11212117a0782f6810a744fcccf03
> 
> # Commandstats
> 
> cmdstat\_command:calls=2,usec=12673,usec\_per\_call=6336.5  
> cmdstat\_info:calls=1549,usec=1680434,usec\_per\_call=1084.85  
> cmdstat\_memory:calls=3,usec=1196,usec\_per\_call=398.667  
> cmdstat\_ping:calls=122,usec=3259,usec\_per\_call=26.7131  
> cmdstat\_set:calls=409898,usec=43167388,usec\_per\_call=105.313
> 
> # Modules
> 
> module:name=ReJSON,ver=20000,api=1,filters=0,usedby=[search],using=,options=[handle-io-errors]  
> module:name=search,ver=20000,api=1,filters=0,usedby=,using=[ReJSON],options=[handle-io-errors]
> 
> # Search
> 
> search\_memory:0  
> search\_num\_indices:0  
> search\_num\_entries:0
> 
> # Errorstats
> 
> COMMAND DOCS Not Implemented:1  
> -LOADING Dragonfly is loading the dataset in memory:14665  
> syntax\_error:2
> 
> # Keyspace
> 
> db0:keys=474603534,expires=474187297,avg\_ttl=-1
> 
> # Cpu
> 
> used\_cpu\_sys:405.383363  
> used\_cpu\_user:1968.673714  
> used\_cpu\_sys\_children:0.1299  
> used\_cpu\_user\_children:0.1633  
> used\_cpu\_sys\_main\_thread:16.125300  
> used\_cpu\_user\_main\_thread:88.914462
> 
> # Cluster
> 
> cluster\_enabled:0  
> migration\_errors\_total:0  
> total\_migrated\_keys:0

And the result of `memory malloc-stats`:

```auto
127.0.0.1:6379> memory malloc-stats
___Begin malloc stats___
arena: 14913536, ordblks: 56, smblks: 0
hblks: 0, hblkhd: 0, usmblks: 0
fsmblks: 0, uordblks: 10634416, fordblks: 4279120, keepcost: 197632
___End malloc stats___

___Begin mimalloc stats___
heap stats: peak total freed current unit count   
  reserved: 168.0 GiB 168.0 GiB 0 168.0 GiB                          
 committed: 163.3 GiB 168.0 GiB 4.8 GiB 163.1 GiB                          
     reset: 0      
    purged: 337.5 MiB
   touched: 947.7 KiB 15.1 MiB 163.6 MiB -148.5 MiB ok
  segments: 241 243 2 241 not all freed
-abandoned: 0 0 0 0 ok
   -cached: 0 0 0 0 ok
     pages: 0 0 693 -693 ok
-abandoned: 0 0 0 0 ok
 -extended: 0      
 -noretire: 0      
    arenas: 35      
-crossover: 0      
 -rollback: 0      
     mmaps: 0      
   commits: 0      
    resets: 0      
    purges: 232      
   threads: 44 44 0 44 not all freed
  searches: 0.0 avg
numa nodes: 1
   elapsed: 5828.089 s
   process: user: 2030.446 s, system: 417.763 s, faults: 17, rss: 164.0 GiB, commit: 163.3 GiB
___End mimalloc stats___

```

Any help or insights on what I might be doing wrong in my configuration or how to sort this out are much appreciated.

---

<div class="post-metadata">

**Author:** ![joezhou\_df](https://yyz2.discourse-cdn.com/flex004/user_avatar/dragonfly.discourse.group/joezhou_df/32/82_2.png) [@joezhou\_df](https://dragonfly.discourse.group/u/joezhou_df)\
**Post date:** [July 17, 2025, 2:29pm UTC](https://dragonfly.discourse.group/t/memory-usage-keeps-increasing-after-reaching-maxmemory-limit/294/2 "2025-07-17T14:29:09Z")

</div>

Hi @hgorni, Thanks for reaching out and for the details. I will ask our engineers to check this out.