-
-
Notifications
You must be signed in to change notification settings - Fork 401
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
Potential virtual memory leak #5189
Comments
Something I forgot to mention - it lists as trying to consume 263G as soon as the process starts -- there's no waiting time. |
So this is VIRT memory usage. This is something that the underlying technology (.net) does. Here’s an explanation dotnet/runtime#9199 but this shouldn’t really be an issue or causing any issues |
Wouldn't have reported it unless it was having issues 😉 Either way, the cron job has kept it alive at the cost of bloating my logs which is tolerable, and I can understand if there's no real fix here if the issue is with the underlying dependency itself. I'm good if you want to close this as can't/won't fix, figured you should be aware at the very least that the process is getting killed by the OOM watch dog on some platforms. |
spent a good bit writing scripts to separate all my logs into separate files under /var/log - it looks like it might have been a database issue, so my earlier assumption that the issue was the OOM protection was likely incorrect. cron seems to run before systemctl, and as a result the mysql service hadn't started. ombi tries to hook into it, and closes itself as a result.
going to wait a few days to make sure there wasn't something else crashing it before closing this out if it is a timing issue, is it possible to put ombi into time limited sleep loop to allow mysql to load? |
Summary
Overview
Ombi seems to be running into an issue where it tries to consume more virtual memory than is physically possible (263G). As a result, it keeps getting flagged by the system resource manager as needing to die, and it gets killed. I've implemented a hotfix via cron, but it's messy and doesn't solve the base issue.
The odd part is that the system itself isn't burdened - memory and CPU are all nominal. For whatever reason, linux thinks that Ombi is chewing up 263G of memory.
Hotfix
/etc/cron.d\# touch oom_disable
/ect/cron.d\# echo '*/1 * * * * root pgrep -f "Ombi\ --storage\ [long storage path]" | while read PID; do echo -17 > /proc/$PID/oom_adj; done'
This just persistently keeps the process from being killed. Not the best solution.
Environment setup
su daemon-ombi -s /bin/bash -c 'cd /home/daemon-ombi/bin && /home/daemon-ombi/bin/Ombi --storage "/media/[long storage path]" --host "http://0.0.0.0:40011" --baseurl "/ombi"' &
Relevant Error logs
2024-11-22 14:49:55.180 -05:00 [INF] Default Quartz.NET properties loaded from embedded resource file
2024-11-22 14:49:55.255 -05:00 [INF] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2024-11-22 14:49:55.255 -05:00 [INF] Quartz Scheduler created
2024-11-22 14:49:55.255 -05:00 [INF] RAMJobStore initialized.
2024-11-22 14:49:55.256 -05:00 [INF] Quartz Scheduler 3.6.2.0 - 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED' initialized
2024-11-22 14:49:55.256 -05:00 [INF] Using thread pool 'Quartz.Simpl.DefaultThreadPool', size: 10
2024-11-22 14:49:55.256 -05:00 [INF] Using job store 'Quartz.Simpl.RAMJobStore', supports persistence: False, clustered: False
2024-11-22 14:49:55.257 -05:00 [INF] JobFactory set to: Ombi.Schedule.IoCJobFactory
2024-11-22 14:49:55.304 -05:00 [INF] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
Relevant Picture
Ombi Version
4.44.1
What platform(s) does this occur on?
Linux
What database are you using?
MySQL
Relevant log output
The text was updated successfully, but these errors were encountered: