Anton Aylward wrote:
On 12/01/2020 13:10, Per Jessen wrote:
In my experience, the oom killer kills the _best_ process, which is the one that uses the most memory. NOT! My apologies Anton, but that _is_ my experience and that _is_ the default OOM killer behaviour.
Yes, it is the default, just like, elsewhere in this thread, we have the default of the Apache server at 150 threads resulting in a terrible DoS->crash. No-one in that thread was bothered by the idea that what was needed was to configure Apache to limit the number of threads.
Just for completeness - tuning apache only means the system will survive such an attack, but the denial-of-service remains. Adding swap will have the same effect. The firewall could also be tuned to reject more than X new requests per second, same result. The real issue is that the php app is being cranked up for every request, also invalid ones that lead to a 404. The real solution is probably to add some rewriting rules to only have valid requests processed by the php app. That is what I have recommended to the customer.
Why should this be different? What's the object to alter the default behaviour of the OOM_killer so that it kills the process that caused the OOM?
That's no better than the default. Still plenty of options for killing an innocent process. -- Per Jessen, Zürich (4.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org