You were possibly using a an old version of sqlite which isn't safe to use 
in a multithreaded configuration.

The MPM settings are not going to help in this case as that error could only 
come about because you are using mod_wsgi daemon mode and so application is 
running in distinct process and not those affected by the MPM or its 
settings.

The only other way you could get that error is that you are actually running 
web2py as a CGI script.

Overall, that specific error message means your daemon mode process that is 
running web2py crashed. You would likely find that there is a segmentation 
fault messages in main Apache error log as well at that time.

Crashing could be because of sqlite thread problems, but could also be 
because you are forcing web2py to run in main interpreter of daemon 
processes and at the same time are using a third party C extension module 
for Python that is not safe for use in sub interpreters.

So, ensure sqlite is up to date. And ensure that you have:

  WSGIApplicationGroup %{GLOBAL}

in configuration to force use of main interpreter.

Graham

On Sunday, January 9, 2011 6:44:14 AM UTC+11, VP wrote:
>
> We occasionally got an Apache error so the page didn't get displayed. 
> So I decided to stress test using Apache Bench (ab).  It seems the 
> site suffered failure up to 50-100 concurrent connection. 
>
> Apache error log showed this error: 
>
> >>>>>>Premature end of script headers: wsgihandler.py 
>
> After digging around, I found similar discussions and change 
> apache2.conf like this: 
>
> # prefork MPM 
> StartServers 5 
> MinSpareServers 5 
> MaxSpareServers 10 
> MaxClients 256 
> MaxRequestsPerChild 500 
> ServerLimit 256 
>
> Didn't seem to help. 
>
> ==== 
>
> A few notes: 
>
> + It appears when I switched to sqlite instead of posgres, I didn't 
> have the problem.   (Sqlite had other problems, such as occasional 
> database locking, which is more serious) 
>
> + I am on a VPS with 768MB with 1GB burstable.   While I'm doing the 
> stress test with Apache Bench (ab), using free on the server revealed 
> memory usage was about 450MB.  (Which is a lot, but is still under 
> limit). 
>
>
> ===== 
>
>
> In summary, memory was available.   But we got this wsgi error in 
> Apache with multiple requests. 
>
> Any idea please? 
>
> Thanks. 
>
>

Reply via email to