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
I've been using this image and getting into deadlocks where the system will just use all of its RAM and become completely unresponsive.
I'm not sure why the Linux OOM Killer is not killing ComfyUI when this happens, but it seems that would be much better than getting an unresponsive instance that you can't do anything with.
When running locally on Windows, if I run a workflow that maxes out the RAM Comfy just gets terminated and I have to restart it which is not the end of the world. However, when this happens on a cloud instance it becomes a big problem as you have to fully restart it, potentially losing data along the way.
There has to be some issues with swap file configuration and OOM Killer configuration for this to happen, I'm running on an instance with a storage with 200GB mostly available space, yet I'm running OOM instead of the system using the swap file.
And that might desirable for performance, but at least when the system maxes out, the OOM killer should take care of Comfy so you can just restart the service instead of the whole instance.
It seems this could be as simple as setting the comfyui service's OOMScoreAdjust to a high value (range is -1000 to 1000). I personnally don't see a reason not to put it at 1000 as it will always be the culprit but my understanding of Linux memory management is very limited.
The text was updated successfully, but these errors were encountered:
I've been using this image and getting into deadlocks where the system will just use all of its RAM and become completely unresponsive.
I'm not sure why the Linux OOM Killer is not killing ComfyUI when this happens, but it seems that would be much better than getting an unresponsive instance that you can't do anything with.
When running locally on Windows, if I run a workflow that maxes out the RAM Comfy just gets terminated and I have to restart it which is not the end of the world. However, when this happens on a cloud instance it becomes a big problem as you have to fully restart it, potentially losing data along the way.
There has to be some issues with swap file configuration and OOM Killer configuration for this to happen, I'm running on an instance with a storage with 200GB mostly available space, yet I'm running OOM instead of the system using the swap file.
And that might desirable for performance, but at least when the system maxes out, the OOM killer should take care of Comfy so you can just restart the service instead of the whole instance.
It seems this could be as simple as setting the comfyui service's
OOMScoreAdjust
to a high value (range is -1000 to 1000). I personnally don't see a reason not to put it at 1000 as it will always be the culprit but my understanding of Linux memory management is very limited.The text was updated successfully, but these errors were encountered: