Hello! On Wed, Mar 27, 2019 at 02:54:41PM -0400, wkbrad wrote:
> Combine all of that with the fact that this issue happens on all systems and > that the direct competitor doesn't have this issue, that makes me think this > is something that Nginx needs to address directly. If by "direct competitor" you mean Apache you've previously mentioned in this thread, note that: - Apache doesn't try to provide a safe configuration reload, and will be in an unusable state if something goes wrong while loading the new configuration (not to mention that Apache can't do a configuration reload while processing ongoing requests at the same time, and instead pauses all processing till reload is complete). This is not something nginx can afford, and hence we do it differently. While our approach may need more memory, this is something we are ready to pay to make sure no requests will be lost. - And, really, nginx and Apache are not direct competitors. If Apache works for you - use it, it is a reputable server we all love and use or used in the past. Though it doesn't scale good enough to thousands of connections, and that's why nginx was written in the first place. And it also cannot handle upgrades and configuration reloads seamlessly, so it cannot be used as a frontend server on loaded sites unless you have a way to direct traffic to a different server. Nevertheless, even on loaded sites Apache can be (and often is) used as a backend server behind nginx, and it does this just fine. What nginx does to keep configuration reloads seamless certainly require additional resources, but this is something we do for a good reason. And this particular problem is relatively easy to mitigate by keeping a configuration small (the other side of the problem is that you anyway need about 2x memory on the server, including various client-related buffers, so nginx will be able to start two sets of worker processes during the configuration reload, and this is something you can't mitigate at all; the good part is that this memory is not wasted but used for page cache between reloads). Also, if you really think this is a major problem, you may want to start working on improving system allocators to handle this better, it is something certainly possible. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
