<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Agree,</div><div class=""><br class=""></div><div class="">I work as performance architect , specializing in improving the performance </div><div class="">of trading applications and high traffic web sites. When I first began tuning </div><div class="">Apache (and then nginx) I realized the the internet was full of “helpful suggestions” </div><div class="">about <i class="">why you should set configuration X to this number.</i></div><div class="">What took me more than ten years to learn was that 95% of these tips are </div><div class="">useless, because they are ideas that made sense in one setting </div><div class="">at one time that got copied and passed down year after year without people </div><div class="">understanding them. So be skeptical about anything that anyone suggests, including me.</div><div class=""><br class=""></div><div class="">Regarding one of these settings: max_requests.</div><div class="">This is a very old setting inherited from apache that originally allowed you to </div><div class="">recycle apache worker processes after they had handled N requests. </div><div class=""><b class=""><br class=""></b></div><div class=""><b class="">Why would you do this?</b></div><div class=""><br class=""></div><div class="">If your worker included a module that leaked memory then over time worker processes</div><div class=""> would grow in size - this setting would mean that each worker would get killed eventually, </div><div class="">at different time, so a new fresh process could be started to take its place, avoiding a </div><div class="">catastrophe where all of your your workers consume all the memory on the host.</div><div class=""><br class=""></div><div class="">In 2017 you can absolutely set iit to zero, provided you keep track of the size of your processes.</div><div class="">In fact we can confirm this idea just from your <i class="">top</i> output. </div><div class=""><br class=""></div><div class=""><div class=""><font face="Courier" class="">ID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND</font></div><div class=""><span style="font-family: Courier;" class="">3135 nginx 20 0 393108 12112 3832 R 7.3 0.0 10:30.35 php-fpm: pool www</span></div><div class=""><font face="Courier" class="">6839 nginx 20 0 392804 11832 3828 R 7.3 0.0 10:37.57 php-fpm: pool www</font></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">See how process 3135 has been running fro 10 minutes 30 seconds whilst process 6839 has been running for 10 minutes 37 seconds.</div><div class="">But the longer running process has a <b class="">smaller</b> resident set size (RSS = memory in use)</div><div class=""><br class=""></div><div class="">If you look at all of the lines its easier to see that there is no trend of memory increasing over time:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">NewiMac:Records peter$ cat phpOutput.txt | grep php-fpm | awk '{print $11,$6}' | head -15 | awk '{print $2}' | average -M</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">11852</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">NewiMac:Records peter$ cat phpOutput.txt | grep php-fpm | awk '{print $11,$6}' | tail -15 | awk '{print $2}' | average -M</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">11876</span></div></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 17, 2017, at 12:39 AM, agriz <<a href="mailto:nginx-forum@forum.nginx.org" class="">nginx-forum@forum.nginx.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Sir reading some info, i guess i cant tell any number blindly without test.<br class=""><br class="">I think <br class="">I can first try to give these values<br class=""><br class="">max_children = 100<br class="">start server = 34<br class="">spareserver min and max = 20 & 50<br class=""><br class="">We have around 20GB free Ram all the time. Why can't we use it for php-fpm?<br class="">Are those values safe to check?<br class=""><br class="">But max_requests, why should we limit the numbers to 500 or 2500? Why cant<br class="">we have unlimited? What is wrong in setting it to zero?<br class=""><br class="">Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?2,276892,276907#msg-276907" class="">https://forum.nginx.org/read.php?2,276892,276907#msg-276907</a><br class=""><br class="">_______________________________________________<br class="">nginx mailing list<br class=""><a href="mailto:nginx@nginx.org" class="">nginx@nginx.org</a><br class="">http://mailman.nginx.org/mailman/listinfo/nginx<br class=""></div></div></blockquote></div><br class=""></body></html>