https://bz.apache.org/bugzilla/show_bug.cgi?id=53555
--- Comment #12 from [email protected] --- After migrating from worker MPM to event MPM with Apache 2.4.7 we are seeing this same problem. Server version: Apache/2.4.7 (Ubuntu) Ubuntu Trusty 14.04.2 LTS Linux 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux We explicitly moved to event MPM for this workload, which is a proxy of thousands of mostly-idle HTTP Keep-Alive connections - since event MPM doesn't require a thread per Keep-Alive connection. Although our number of clients is fairly consistent, and we have MaxConnectionsPerChild=0, we observe Apache processes going into GGGGGG state until eventually Apache no longer accepts connections. If we set MinSpareThreads and MaxSpareThreads equal to MaxRequestWorkers (so Apache doesn't attempt to scale down processes), the issue goes away (as expected, but validates (maybe?) this has to do with Apache scale-down). Since client connections can be connected for hours or days, Apache processes stay in this state for a very long time, eventually rejecting client connections and becoming wedged. Our clients are not browsers - Apache is being used for a mid-tier load balancer/proxy with client connections that are very long lived (long Keep-Alive times). 248 requests/sec - 0.7 MB/second - 3114 B/request 2 requests currently being processed, 38 idle workers PID Connections Threads Async connections total accepting busy idle writing keep-alive closing 28483 1642 no 0 0 0 1642 0 29672 553 yes 1 19 0 552 0 29696 9 no 0 0 0 9 0 29588 173 no 0 0 0 173 0 29618 1 no 0 0 0 1 0 29644 6 no 0 0 0 6 0 29719 30 no 0 0 0 30 0 29743 237 yes 1 19 0 236 0 Sum 2651 2 38 0 2649 0 GGGGGGGGGGGGGGGGGGGG________W___________GGGGGGGGGGGGGGGGGGGGGGWG GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG GGGGGGGGGGGG________W___________................................ ........ -- 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]
