Hi guys, since a few days my monitoring alerts me due to RAM usage >80%. I'm running mailcow on a Hetzner VPS with 16GB RAM for some years now and never really went over 60-70%. [upl-image-preview uuid=2a11f600-c668-47c3-af6f-0b8877908208 url=https://community.mailcow.email/assets/files/2026-05-27/1779865282-332798-image.png alt={TEXT?}] So I checked the Docker containers for their RAM usage: ```asd root@mailserver:/opt/mailcow-dockerized# docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}" NAME MEM USAGE / LIMIT MEM % mailcowdockerized-watchdog-mailcow-1 34.3MiB / 15.25GiB 0.22% mailcowdockerized-acme-mailcow-1 6.973MiB / 15.25GiB 0.04% mailcowdockerized-nginx-mailcow-1 17.82MiB / 15.25GiB 0.11% mailcowdockerized-rspamd-mailcow-1 692.4MiB / 15.25GiB 4.43% mailcowdockerized-ofelia-mailcow-1 272.1MiB / 15.25GiB 1.74% mailcowdockerized-postfix-mailcow-1 84.07MiB / 15.25GiB 0.54% mailcowdockerized-dovecot-mailcow-1 172.2MiB / 15.25GiB 1.10% mailcowdockerized-php-fpm-mailcow-1 114MiB / 15.25GiB 0.73% mailcowdockerized-clamd-mailcow-1 1021MiB / 15.25GiB 6.54% mailcowdockerized-mysql-mailcow-1 311.5MiB / 15.25GiB 1.99% mailcowdockerized-postfix-tlspol-mailcow-1 45.9MiB / 15.25GiB 0.29% mailcowdockerized-redis-mailcow-1 7.163GiB / 15.25GiB 46.96% mailcowdockerized-sogo-mailcow-1 411.6MiB / 15.25GiB 2.64% mailcowdockerized-memcached-mailcow-1 12.45MiB / 15.25GiB 0.08% mailcowdockerized-dockerapi-mailcow-1 54.45MiB / 15.25GiB 0.35% mailcowdockerized-unbound-mailcow-1 41.21MiB / 15.25GiB 0.26% mailcowdockerized-olefy-mailcow-1 15.26MiB / 15.25GiB 0.10% mailcowdockerized-netfilter-mailcow-1 33.15MiB / 15.25GiB 0.21% mailcow-logs-app 189.9MiB / 15.25GiB 1.22% mailcow-logs-db 234.6MiB / 15.25GiB 1.50% ``` 7GB+ for Redis, that's crazy! mailcow is running for some years now, and it seems that Redis is configured without limit and eviction policy: ```asd root@mailserver:/opt/mailcow-dockerized# docker compose exec rspamd-mailcow redis-cli -h 172.22.1.249 -p 6379 -a $(grep REDISPASS mailcow.conf | awk -F= '{print $2}') info memory | grep maxmemory Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction ``` Redis collected about 9 million strings so far without ever cleaning up old entries: ```asd root@mailserver:/opt/mailcow-dockerized# docker compose exec rspamd-mailcow redis-cli -h 172.22.1.249 -p 6379 -a $(grep REDISPASS mailcow.conf | awk -F= '{print $2}') --bigkeys Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Scanning the entire keyspace to find biggest keys as well as # average sizes per key type. You can use -i 0.1 to sleep 0.1 sec # per 100 SCAN commands (not usually needed). 100.00% |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Keys sampled: 9186428 -------- summary ------- Total key length in bytes is 448657330 (avg len 48.84) Biggest list found "API_LOG" has 10065 items Biggest hash found "learned_ids" has 34202 fields Biggest string found "MAIN_LOGO_DARK" has 1253950 bytes Biggest set found "rn_LONG_default_bh4p4too_3_ham_set" has 8097 members Biggest zset found "rsrkokqc19wnidi1ou6ndpn4" has 30 members 10 lists with 82208 items (00.00% of keys, avg size 8220.80) 52192 hashs with 103810 fields (00.57% of keys, avg size 1.99) 0 streams with 0 entries (00.00% of keys, avg size 0.00) 9134006 strings with 5690225325 bytes (99.43% of keys, avg size 622.97) 209 sets with 64569 members (00.00% of keys, avg size 308.94) 11 zsets with 49 members (00.00% of keys, avg size 4.45) ``` I wanted to ask around if you are seeing a similar development regarding your memory usage. I'm thinking about setting a maxmemory limit and and eviction policy myself, as in the current state the Redis DB will grow unlimited...

@"DocFraggle"#p32464 If those are sessions they should have been pruned every 3h, can you check this [setting](https://github.com/mailcow/mailcow-dockerized/blob/2ac4b1deaee50e1284d644cecc16dcb0b37e67e2/data/web/inc/vars.inc.php#L158) in your system? This should mark those redis entries whit TTL, you can check if they have TTL, mine does, but i do not use mailcow-logs-viewer.

@"ETNyx"#15735 you are welcome, glad we were able to figure it out :-) @"shlomi"#17681 still worth to to check it out, you may find that, if you will start to reusing connection/session it will boost performance.

Redis RAM usage

DocFraggle

Hi guys,

since a few days my monitoring alerts me due to RAM usage >80%. I’m running mailcow on a Hetzner VPS with 16GB RAM for some years now and never really went over 60-70%.

So I checked the Docker containers for their RAM usage:

root@mailserver:/opt/mailcow-dockerized# docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"
NAME                                         MEM USAGE / LIMIT     MEM %
mailcowdockerized-watchdog-mailcow-1         34.3MiB / 15.25GiB    0.22%
mailcowdockerized-acme-mailcow-1             6.973MiB / 15.25GiB   0.04%
mailcowdockerized-nginx-mailcow-1            17.82MiB / 15.25GiB   0.11%
mailcowdockerized-rspamd-mailcow-1           692.4MiB / 15.25GiB   4.43%
mailcowdockerized-ofelia-mailcow-1           272.1MiB / 15.25GiB   1.74%
mailcowdockerized-postfix-mailcow-1          84.07MiB / 15.25GiB   0.54%
mailcowdockerized-dovecot-mailcow-1          172.2MiB / 15.25GiB   1.10%
mailcowdockerized-php-fpm-mailcow-1          114MiB / 15.25GiB     0.73%
mailcowdockerized-clamd-mailcow-1            1021MiB / 15.25GiB    6.54%
mailcowdockerized-mysql-mailcow-1            311.5MiB / 15.25GiB   1.99%
mailcowdockerized-postfix-tlspol-mailcow-1   45.9MiB / 15.25GiB    0.29%
mailcowdockerized-redis-mailcow-1            7.163GiB / 15.25GiB   46.96%
mailcowdockerized-sogo-mailcow-1             411.6MiB / 15.25GiB   2.64%
mailcowdockerized-memcached-mailcow-1        12.45MiB / 15.25GiB   0.08%
mailcowdockerized-dockerapi-mailcow-1        54.45MiB / 15.25GiB   0.35%
mailcowdockerized-unbound-mailcow-1          41.21MiB / 15.25GiB   0.26%
mailcowdockerized-olefy-mailcow-1            15.26MiB / 15.25GiB   0.10%
mailcowdockerized-netfilter-mailcow-1        33.15MiB / 15.25GiB   0.21%
mailcow-logs-app                             189.9MiB / 15.25GiB   1.22%
mailcow-logs-db                              234.6MiB / 15.25GiB   1.50%

7GB+ for Redis, that’s crazy! mailcow is running for some years now, and it seems that Redis is configured without limit and eviction policy:

root@mailserver:/opt/mailcow-dockerized# docker compose exec rspamd-mailcow redis-cli -h 172.22.1.249 -p 6379 -a $(grep REDISPASS mailcow.conf | awk -F= '{print $2}') info memory | grep maxmemory
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction

Redis collected about 9 million strings so far without ever cleaning up old entries:

root@mailserver:/opt/mailcow-dockerized# docker compose exec rspamd-mailcow redis-cli -h 172.22.1.249 -p 6379 -a $(grep REDISPASS mailcow.conf | awk -F= '{print $2}') --bigkeys
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

100.00% ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Keys sampled: 9186428

-------- summary -------

Total key length in bytes is 448657330 (avg len 48.84)

Biggest   list found "API_LOG" has 10065 items
Biggest   hash found "learned_ids" has 34202 fields
Biggest string found "MAIN_LOGO_DARK" has 1253950 bytes
Biggest    set found "rn_LONG_default_bh4p4too_3_ham_set" has 8097 members
Biggest   zset found "rsrkokqc19wnidi1ou6ndpn4" has 30 members

10 lists with 82208 items (00.00% of keys, avg size 8220.80)
52192 hashs with 103810 fields (00.57% of keys, avg size 1.99)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
9134006 strings with 5690225325 bytes (99.43% of keys, avg size 622.97)
209 sets with 64569 members (00.00% of keys, avg size 308.94)
11 zsets with 49 members (00.00% of keys, avg size 4.45)

I wanted to ask around if you are seeing a similar development regarding your memory usage. I’m thinking about setting a maxmemory limit and and eviction policy myself, as in the current state the Redis DB will grow unlimited…

ETNyx

Hello, i would try to investigate what those 9M strings are to determine this leak. This is my summary,..

10 lists with 81131 items (00.01% of keys, avg size 8113.10)
64466 hashs with 88910 fields (90.38% of keys, avg size 1.38)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
6793 strings with 445888 bytes (09.52% of keys, avg size 65.64)
8 sets with 864 members (00.01% of keys, avg size 108.00)
47 zsets with 94 members (00.07% of keys, avg size 2.00)

Maybe somthink like

docker compose exec redis-mailcow redis-cli -a $(grep REDISPASS mailcow.conf | awk -F= '{print $2}') --scan --count 1000 \
  | awk -F'[_:]' '{print $1}' \
  | sort | uniq -c | sort -rn | head -40

to get most used keys prefixies?

DocFraggle

ETNyx Ah great hint!

root@mailserver:/opt/mailcow-dockerized# docker compose exec redis-mailcow redis-cli -a $(grep REDISPASS mailcow.conf | awk -F= '{print $2}') --scan --count 1000 \
  | awk -F'[_:]' '{print $1}' \
  | sort | uniq -c | sort -rn | head -40
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
9136311 PHPREDIS
  51191 RS
   3803 fuzzy
    707 RR
...

So it’s not RSPAMD, but PHPREDIS. So I investigated further and checked the session entries, it’s most likely the mailcow-logs-viewer API calls, as my RAM graph correlates with my mailcow-logs-viewer implementation date

python-httpx/0.26.0
mailcow_cc_username: "API"
mailcow_cc_role: "admin"

@shlomi could you have a look into this? I’m no Python expert, the AI indicates that there is no session reuse implemented:

🧠 Problem recap (in code terms)
The project most likely does this pattern somewhere:

import httpx

response = httpx.get(url, headers=headers)

👉 This creates a new connection + no cookie reuse → mailcow creates a new PHP session every time.

ETNyx

DocFraggle

If those are sessions they should have been pruned every 3h, can you check this setting in your system?

This should mark those redis entries whit TTL, you can check if they have TTL, mine does, but i do not use mailcow-logs-viewer.

DocFraggle

ETNyx You’re my hero today 😃

A few years back I was annoyed that I had to login again constantly to the admin GUI, so I added this file to override the session lifetime

root@mailserver:/opt/mailcow-dockerized# cat ./data/web/inc/vars.local.inc.php
<?php
// Session lifetime in seconds
$SESSION_LIFETIME = 9999999999;

Thanks a lot!!!

@shlomi forget what I wrote above, totally my fault 🙂

ETNyx

@ETNyx you are welcome, glad we were able to figure it out :-)

@shlomi still worth to to check it out, you may find that, if you will start to reusing connection/session it will boost performance.

shlomi

ETNyx
It depends a lot on which features you have enabled. For example, Logs makes the most requests.