https://bz.apache.org/bugzilla/show_bug.cgi?id=58799
--- Comment #4 from Tomaž Šolc <[email protected]> --- Hi I'm also seeing unexpected behavior regarding the FcgidMinProcessesPerClass setting. In a test environment, if I momentarily load a server, it will correctly spawn many (i.e. more than FcgidMinProcessesPerClass) workers, but after FcgidIdleTimeout, it will also kill all of them (server-status page says "Exiting (idle timeout)"). However, in practice, I usually see between 0 and FcgidMinProcessesPerClass processes running, even if idle times of some of them are above FcgidIdleTimeout. Documentation for FcgidIdleTimeout says that "Application processes [...] will be terminated, if the number of processes for the class exceeds FcgidMinProcessesPerClass". From this I expect that idle timeout will not kill all idle processes, but only kill as many as necessary to keep at least FcgidMinProcessesPerClass processes running. Looking at the source: idle timeout for processes is detected in scan_idlelist(). This then checks number of running processes against FcgidMinProcessesPerClass in is_kill_allowed(). It seems to me the problem is that the process count is not updated while processes are selected for termination in scan_idlelist(). The count in current_node->process_counter is only updated later in a second pass, when the processes are actually killed in scan_errorlist(). This is consistent with the behavior I'm seeing. After bursty loads, you will have all processes reach the idle timeout at once. Process count will be above FcgidMinProcessesPerClass and all will be killed. With more random loads, you will have idle processes reach the timeout at different times, meaning process count will be updated between each run of the scan_idlelist(). -- 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]
