-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ofelia eating up my memory, system running out of memory #5807
Comments
Can confirm the bug. System is running in Arch Linux. Since mailcow docker installation hasn't changed before the bug ocurred, maybe a package dependency outside of the container environment causes this faulty behavior? |
This is a known problem (mcuadros/ofelia#157, #4272] that ofelia never fixed. It was suggested a while ago to replace ofelia with its fork chadburn (#4362), but that fork isn‘t receiving much maintenance anymore either. |
edit: now i managed to avoid this issue by increasing |
@sadorowo |
oh yeah i recently added swap too, because other services that I'm running needed more |
After one week my 16 GB are eaten up by this known problem (mcuadros/ofelia#157, https://github.com/mailcow/mailcow-dockerized/issues/4272] I really hope this bug is taken seriously and will be fixed soon. |
ofelia a "crontab for docker" is one of the worst docker tools I have ever seen. A crontab should at most use a few MiB of memory and not multiple GiB. As this apparently a known issue for years with, I petition the mailcow team to switch to something else. Literally anything else, because it can't possibly get worse. My Systems: The screenshot from the alpine instance after 20h of uptime. In ubuntu the memory consumption rises even faster... My current workaround is a script, that I run hourly, that restarts the ofelia container if ofelia uses more than 500MB: #!/usr/bin/fish
cd /opt/mailcow-dockerized/
# Get usage using ps
set usage (ps -o comm,rss | grep ofelia | grep -oPe "[0-9]+(k|m|g)")
# convert lowercase unit to upper-case
set usage (string upper $usage)
# convert human-readable value to bytes
set usage (numfmt --from=iec $usage)
echo $usage
if test $usage -gt 500000000;
docker-compose restart ofelia-mailcow;
else
echo "usage ok"
end
(updated script with input from #5807 (comment)) |
Just to further showcase the severity of this: I was led here by ofelia munching on 27G of memory, maxing out all available memory space it could. Server has 64G total. Somewhat ironically, I guess I'll set up a cron job to regularly restart the ofelia container |
I'm temporarily resolving it with |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Unless this has been resolved, I believe this ticket should stay open. |
We need a way to disable it |
I'm experiencing this issue as well |
Quick note, after implementing the ofelia container restart, my system was still locking up. Creating a similar restart crontab job for the watchdog container did the trick |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Still an issue |
still an issue, occasionally reinstalling mailcow for testing, still having the same problem |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
still an issue |
Contribution guidelines
I've found a bug and checked that ...
Description
Recently, ofelia seems to be eating more and more memory on my machine over time, eventually leading to an out-of-memory situation on my machine. It looks like a memory leak with ~20-30MByte/10minutes (2-3MByte/minute), which is of course not a lot, but with a long runtime I run into trouble on my 16G memory machine.
I am running mailcow on this machine in the same setup since a couple of years already. This issue though seems to be new - I cannot exactly tell since when, but not longer than a couple of weeks for sure. I see there are no changes done on mailcow since Feb 15th, so I would suspect this is an issue within ofelia or docker itself, but I don't know where to start digging, and hope to find other affected users here.
Take a look at the VSZ and RSS columns in the below output, which has been taken from within the ofelia-mailcow container. Basically, we can see that the memory footprint of the ofelia process is increasing over time.
I also checked other logs (e.g. docker-compose log of the ofelia container), but I didn't find anything suspicious (i.e. errors or something like that).
Logs:
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
x86
Operating System:
Arch Linux
Server/VM specifications:
16G memory, 4 cores
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
KVM (Hetzner Cloud Server)
Docker version:
26.0.0 (also happened with 25.0.4, upgraded 2 days ago)
docker-compose version or docker compose version:
latest
mailcow version:
2024-02
Reverse proxy:
Nginx
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check:
The text was updated successfully, but these errors were encountered: