On 10 April 2010 06:36, zbyte <[email protected]> wrote: > We use maximum-requests because the alternative is that if there is a > memory leak, the server will eventually slow down to a crawl and die. > While I'm pretty sure _my_ code doesn't leak, I cannot make such a > guarantee for everything else.
I'd suggest increasing maximum requests and monitor memory usage and work out whether there are memory leaks or not. Also, 500 for maximum requests is rediculously low. If your application leaks so bad that it has to be started up so few requests then you have serious issues. Also, if your application sees periods of inactivity, then instead of using maximum requests, use inactivity timeout instead. That way at least you ensure it is restarted during a period where no requests are happening. Graham > On Apr 8, 3:41 pm, Graham Dumpleton <[email protected]> > wrote: >> Why are you using 'maximum-requests' option to WSGIDaemonProcess? >> >> If your application doesn't experience memory leaks, whether they be >> actual, or due to problems in application caching or object request >> cycles that prevent garbage collection, you should not use that option >> on a production system. >> >> This is because if you have long running requests, you risk >> interrupting activate requests because on process recycling due to >> maximum requests being reached, if the concurrent requests don't >> shutdown within the shutdown timeout period, then the process will be >> forcibly shutdown causing still active requests to be interrupted, >> potentially resulting in that message. >> >> In other words, there is no never ending grace period for active >> requests on process recycling. >> >> You don't see the problem with a single thread, because when maximum >> requests reached, there wouldn't be any concurrent active requests >> running at the same time to hold things up. >> >> Graham >> >> On 9 April 2010 04:42, zbyte <[email protected]> wrote: >> >> >> >> > Hello, I run a number of Django servers and every now and then we get >> > an error in our logs stating something like: >> >> > [Thu Apr 08 17:10:07 2010] [error] [client XXXX] Premature end of >> > script headers: upro_production.wsgi, referer: >> >http://coursefinder.uprogps.com/coursefinder/upro/device/XXXX/ >> >> > These errors are not accompanied by Segmentation faults in the main >> > error.log and are not associated with us gracefully restarting apache. >> > All our servers have nginx proxying to apache and all our static >> > content is served by nginx. >> >> > We experience this error across two sites:www.xterra.comand >> > coursefinder.uprogps.com. Below are some stats: >> >> > == Coursefinder == >> >http://coursefinder.uprogps.com/ >> > Django 1.0.4 >> > 500 max requests >> > 3 processes >> > 20 threads >> >> > === Past 4 Days === >> > 289 Premature end of script headers errors. Many not related to >> > downloading a course >> > ~ 72 Errors a day >> > 7249041 Requests >> > 1 Error for every 25083 Requests >> >> > == Xterra == >> >http://www.xterrawetsuits.com/ >> > Django 1.1.1 >> > 500 max requests >> > 2 processes >> > 10 threads >> >> > === Past 4 days === >> > 22 Premature end of script headers >> > ~ 5 errors a day >> > 810000 Requests >> > 1 Error for every 36818 Requests >> >> > == Dcshoes == >> >http://www.dcshoes.com/ >> > Django 1.0.2 >> > 5 Sites Each configured with: >> > 500 max requests >> > 4 Processes >> > 1 Thread >> > No errors >> >> > === Past 4 days === >> > 473559 Requests >> >> > Because dcshoes.com doesn't experience this problem and only has 1 >> > thread per process, I am beginning to think that this is a threading >> > issue. Supposedly Django 1.0.3 and later is thread safe. >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "modwsgi" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group >> > athttp://groups.google.com/group/modwsgi?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group >> athttp://groups.google.com/group/modwsgi?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
