azurIt wrote: > Are you sure it will take so much resources ?
Yep, if you have 100 processes in the process of shutting down, and you start up another 100 processes before the first 100 have finished shutting down, you've now potentially doubled your RAM footprint. If you infrastructure is under strain already, that will probably make things worse. > Apache processes are starting/ending all the time and i can't see any > problems with this. Under normal circumstances, Apache processes shouldn't be starting/ending all the time, they are designed to be long running. Apache processes that are in the process of starting and shutting down most of the time are crucially not serving requests, and sounds like a symptom of a badly tuned server. > Isn't there any module, which implements this behavior so we can test > it ? 10 seconds without accepting connections is just too much :( That sounds like a tuning issue to me. What is running within the httpd processes that makes them so heavy? > Anyway, why processes needs to be shutdown on reload at all ? Cannot > they just re-read the configuration file/s ? Thnx for explanation. Because of copy-on-write. Under normal circumstances, a parent process reads the config file just once, and then spawns threads and processes as required, each of which inherit this common config. On condition you make no attempt to write to this config (and httpd makes a point of doing this), the OS gets clever, and stores just one memory resident copy of the config, all shared by the same 100 processes. If each process decided to reload the config as you suggest, not only would we have 100 child processes parsing 100 configurations (instead of 1 parent process parsing 1 configuration), but 100 child processes will store 100 separate copies of 100 configuration trees in memory, with a memory footprint 100 times larger than we have now. It makes a big performance difference. Regards, Graham --
