fix: protect mastercontainer from OOM situations

[Copilot]

Sets oom_score_adj: -500 in compose.yaml and adds --oom-score-adj -500 to all docker run commands in the documentation. This instructs the Linux OOM killer to strongly prefer killing other processes before the mastercontainer, keeping the AIO interface accessible even under memory pressure.

Changes Made

• compose.yaml — added oom_score_adj: -500 with an explanatory comment
• readme.md — --oom-score-adj -500 added to Linux and Windows docker run commands; explanation bullet added in the <details> section
• reverse-proxy.md — same: Linux + Windows commands and explanation bullet
• multiple-instances.md, develop.md, php/README.md — --oom-score-adj -500 added to each mastercontainer docker run invocation

[Zoey2936]

I would strongly recommend to NOT do this, it makes no sense giving the mastercontainer a lower value then the hosts init process or docker itself.

[szaimen]

@copilot please change the -1000 value to -500

[Copilot]

@copilot please change the -1000 value to -500

Done. Changed all occurrences of -1000 to -500 across compose.yaml, readme.md, reverse-proxy.md, develop.md, multiple-instances.md, and php/README.md, and updated the explanatory text accordingly (commit 988258b).

[szaimen]

@Zoey2936 is this better now?

[Zoey2936]

At least on my system the oom_score is calculates like this: 666 + ((ram-usage / total-ram-swap) * 666), the first 666 comes from it being a non privileged process. So this means setting the adj to -667 or lower will always make it better then any non-privileged process. I think the score of containers should be similiar to expected memory usage. if you understand

[szaimen]

At least on my system the oom_score is calculates like this: 666 + ((ram-usage / total-ram-swap) * 666), the first 666 comes from it being a non privileged process. So this means setting the adj to -667 or lower will always make it better then any non-privileged process. I think the score of containers should be similiar to expected memory usage. if you understand

I fear I don't really understand. Can you maybe make some suggestions how you would choose the values?

In my opinion the values should be chosen based on the importance of each component for the whole system. Is that not the best approach?

[Zoey2936]

In my opinion the values should be chosen based on the importance of each component for the whole system. Is that not the best approach?

Yes, but we can't assume that users set this value for all services running on the server, which are not managed by AIO

[szaimen]

In my opinion the values should be chosen based on the importance of each component for the whole system. Is that not the best approach?

Yes, but we can't assume that users set this value for all services running on the server, which are not managed by AIO

So what would be your approach to the idea of adding this value to the aio cotnainers and especiall the mastercontainer? Having the value set for the mastercontainer will not automatically kill other applications iirc...

[Zoey2936]

Yes, but in theory the docker daemon could be killed before the master container in theory an example

[szaimen]

Yes, but in theory the docker daemon could be killed before the master container in theory an example

I see so i guess the value here for the mastercontainer should be lower than the value of the docker daemon right?

[Zoey2936]

the docker deamon should be killed after the container

[szaimen]

the docker deamon should be killed after the container

I just checked and the default value for the docker daemon seems to be -500. So having -500 for the mastercontainer should be fine imho. WDYT?

[Zoey2936]

Where do you have the -500 from?

[szaimen]

Where do you have the -500 from?

[Zoey2936]

Ohhh that explains it, my server uses alpine as host os which does not set this value. Maybe this could be connected to an env?