Dave Howorth wrote:
On Mon, 13 Jan 2020 11:24:26 +0100 Per Jessen <per@computer.org> wrote:
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.
Another possibility (which I'm sure would go down like a lead balloon) would be to switch away from PHP to some technology that doesn't start an app for each request. Let me think - Perl had that about twenty years ago? :)
Switching is not an option, the app does not come in any other implementation :-) I guess they could use php fastcgi, but I think they are happy with the system surviving even if clients can't be served. -- Per Jessen, Zürich (5.6°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