You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After running into OOM-crashes/quits consistently this patch with swap configured I did some investigating where I found some interesting behaviour, which i believe should be mentioned in the troubleshooting/OOM section of the wiki (or if more consistently observable, possibly introducing a solution via the helper that does this for the game process/service automatically):
Note: i was not able to find any systemd oom-manager on my system, so most likely it is the kernel oom-manager
Swap was not fully utilized, and with z-ram configured not utilized at all.
The source of the oom-killer being invoked seemed to stem from the way memory accounting was being done to define the maximum usable memory, through the CGroup resource-restrictions. systemctl show <star citizen process slice / service> showed the following:
In certain conditions, this configuration, even though MemoryHigh and MemoryMax are set to infinity, the oom-killer will get invoked once - EffectiveMemoryMax/High | Physical Memory - is reached.
The solution to override this behaviour was to explicitly set values for MemoryHigh and MemoryMax for the user slice: systemctl edit user.slice
### Editing /etc/systemd/system/user.slice.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
[Slice]
MemoryAccounting=yes #cautionary setting, was reporting as yes before as well
MemoryMax=52G #Physical + swap (or your preference)
MemoryHigh=52G
...
I do not know if there is a way to calculate a value dynamically for these entries. Feel free to edit if so.
After applying the rules with sudo systemctl daemon-reexec and sudo systemctl restart user.slice OR restarting the system, the oom-killer is no longer being invoked and star citizen happily claims memory and swap (observed up to 42G+, where performance becomes questionable but still preferable to a hard-crash)
I am unfortunately not profitient enough in kernel systems to give a more precise answer/reason. If you need more information, feel free to ask.
A note from my own system:
My user.slice is configured to set EffectiveMemoryMax/High to 32GB, but inspecting Star Citizen while it's running shows that both are getting set to infinity for the game.
It would seem there's some other piece somewhere making that change and I'd like to know what is doing that. I suspect whatever that is would be the more "proper" place to make the configuration change.
Are you able to get some help from our discord tech support folks to investigate this a bit further?
After running into OOM-crashes/quits consistently this patch with swap configured I did some investigating where I found some interesting behaviour, which i believe should be mentioned in the troubleshooting/OOM section of the wiki (or if more consistently observable, possibly introducing a solution via the helper that does this for the game process/service automatically):
Note: i was not able to find any systemd oom-manager on my system, so most likely it is the kernel oom-manager
Swap was not fully utilized, and with z-ram configured not utilized at all.
The source of the oom-killer being invoked seemed to stem from the way memory accounting was being done to define the maximum usable memory, through the CGroup resource-restrictions.
systemctl show <star citizen process slice / service>
showed the following:In certain conditions, this configuration, even though MemoryHigh and MemoryMax are set to infinity, the oom-killer will get invoked once - EffectiveMemoryMax/High | Physical Memory - is reached.
The solution to override this behaviour was to explicitly set values for MemoryHigh and MemoryMax for the user slice:
systemctl edit user.slice
I do not know if there is a way to calculate a value dynamically for these entries. Feel free to edit if so.
After applying the rules with
sudo systemctl daemon-reexec
andsudo systemctl restart user.slice
OR restarting the system, the oom-killer is no longer being invoked and star citizen happily claims memory and swap (observed up to 42G+, where performance becomes questionable but still preferable to a hard-crash)I am unfortunately not profitient enough in kernel systems to give a more precise answer/reason. If you need more information, feel free to ask.
Noteworthy system information:
Physical Memory: 32GB
Kernel: 6.11.0-9-generic
Distribution: Kubuntu 24.10 x86_64
DE: Plasma 6.1.5 - kwin - wayland
CGroup version: 2
The text was updated successfully, but these errors were encountered: