I can´t be sure which application it is. But Iĺl do some stresstests
later today and report more.
Kenneth
could this be a timeout issue? Could it be the app causes a deadlock
in the db? What app is this?
On Jan 11, 10:58 am, Kenneth Lundström<kenneth.t.lundst...@gmail.com>
wrote:
I'm getting the same Premature end of script on a CentOS 5.?, MySQL, WSGI and
Apache.
Never done any stresstests, I'll try later to day.
Kenneth
----- Ursprungsmeddelande -----
Update:
+ There seems to be no web2py error. Thus, no traceback.
+ I don't remember if I got this error Premature end of script
headers: wsgihandler.py ) with sqlite, but having just tested again
with sqlite, I didn't get this error. At the moment, this error only
occurred with postgres (8.6.3 as I'm on Debian Lenny).
+ This error occurred sporadically. Testing with ab ranging from 50
to 200 concurrent connections, I couldn't always duplicate the error.
Sometimes, it occurred. Sometimes, it didn't.
PS: Someone asked about apache bench. It's included in apache2-utils
(which can be installed by apt). Pretty easy to use. I used this: ab
-kc 200 -t 10http://yourdomain.com/to open 200 concurrent requests
in 10 seconds.
On Jan 11, 8:58 am, Massimo Di Pierro<massimo.dipie...@gmail.com>
wrote:
Can I see the error? Is there a traceback? Is the db server on the
machine?
Massimo
On Jan 9, 11:30 am, VP<vtp2...@gmail.com> wrote:
It is indeed the case that there was a segmentation fault, reported
in apache error log.
Perhaps, it's not clear, but this problem occurs under posgres under
debian lenny, not sqlite. I am not running web2py as a CGI script.
I am using the web2py deployment script (for setting up apache and
web2py):
<VirtualHost *:80>
WSGIDaemonProcess web2py user=myusername group=myusername \
display-name=%{GROUP}
WSGIProcessGroup web2py
WSGIScriptAlias / /home/myusername/web2py/wsgihandler.py
....
On Jan 8, 9:59 pm, Graham Dumpleton<graham.dumple...@gmail.com>
wrote:
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.
