https://bz.apache.org/bugzilla/show_bug.cgi?id=61551
--- Comment #37 from Yann Ylavic <[email protected]> --- Created attachment 35649 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35649&action=edit Patches for 2.4.27 Thanks Nic for testing. There were several changes to mpm_event (and related) since 2.4.27, and I think the above/attached set of 3 patches should be applied for your test to be relevant (all are already or will be part of next 2.4.x). I quickly tested the slowhttptest scenario on 2.4.27 and it seems to work/fail as expected with/without the patches. Please note that according to your mod_security settings (i.e. SecConnReadStateLimit 50), there may still be at most 50 active connections/threads handled by "old gen" processses with other/idle threads in G state, this is the expected behaviour (for mod_security's SecConnReadStateLimit detection and action). There may also be "old gen" processses with no active connection (all threads in G state), depending on your MPM setting (see below), those can/will be reused at any time according to the load. Also, if you expect httpd reloads with active/long-standing connections kept alive, you probably want to "oversize" ServerLimit w.r.t. MaxRequestWorkers and ThreadsPerChild, such that there is room in the scoreboard for gracefully restarting processes (without interfering with the new generation ones). This relaxes the usual/strict "MaxRequestWorkers = ServerLimit * ThreadsPerChild" formula to take reloads into account. For example, if MaxRequestWorkers should be 1000 (adapt to your needs), something like ThreadLimit = ThreadsPerChild = 50 and ServerLimit = 50 (instead of 20) leaves room for 2.5 simultaneous reloads, or one reload and some MaxConnectionsPerChild kicking at the same time. YMMV... -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
