Let us know what you discover.
On May 7, 3:57 pm, David Zejda <[email protected]> wrote: > Yes, vanilla hardware (some dual core Intel). I'm running the latest > web2py now, but it was crashing even with about half year old version > (1.73 or so), so the issue is probably not webserver specific. The > process is in ps ax no more when crashes. Currently the server is > being accessed through Apache proxy. Maybe I'll find a while to test > it with mod_wsgi. > > Thanks :) > > On May 7, 4:00 pm, Timothy Farrell <[email protected]> wrote: > > > Is this standard hardware? The only place I've seen Python crash is on > > non-standard hardware (AS400) with a non-supported build of Python. > > > Web2py recent switched from Cherrypy's wsgiserver to Rocket (which I > > wrote) as of version 1.77.2 (I think). Which version are you running? > > > With built-in web-servers, the listening for connections and the > > response processing all happens in the same Linux Process. So if it > > stops listening, do you still see the process in 'top' or 'px ax'? If > > so, then, Yes, the whole process crashed (in which case it is more > > likely the Python interpreter); otherwise, there would likely be a bug > > somewhere in web2py that we can address. > > > You could also try Apache+mod_wsgi to see if that changes things. > > > -tim > > > On 5/7/2010 8:36 AM, David Zejda wrote: > > > > AFAIK web2py uses cherrypy webserver, which listens as a daemon on > > > certain port. With crashing I mean that the listening process (web2py > > > with cherrypy at the background) suddenly terminates. I use standard > > > Python v 2.5.2 as packaged for Debian. > > > > David > > > > On May 7, 2:52 pm, Timothy Farrell<[email protected]> wrote: > > > >> Can you be more specific on what you mean by "crashing"? Interpreted > > >> languages shouldn't crash and generally if they do it's something wrong > > >> with the interpreter. Are you using cPython? > > > >> On 5/7/2010 1:48 AM, David Zejda wrote: > > > >>> Hi, > > > >>> my web2py instance (about 10000 pageviews, 300000+ ajax requests > > >>> daily) crashes about daily. As a workaround I have a script which > > >>> (re)starts the server when either memory usage exceeds certain > > >>> threshold or when the server is completely down. I run the script from > > >>> cron every minute. > > > >>> #! /bin/sh > > > >>> A=`netstat -tlnp | grep 8000` > > >>> TIME=`date` > > >>> LOG='/var/log/web2py/keepalive.log' > > > >>> if [ "$A" ]; > > >>> then > > >>> B=`echo $A | cut -d " " -f 7` > > >>> PID=${B%/*} > > >>> MEM=`ps -p $PID -o vsz | tail -n 1` > > >>> if [ "$MEM" -gt 2000000 ]; > > >>> then > > >>> echo "$TIME $PID $MEM MEMORY">> $LOG > > >>> echo "Web2py memory $MEM on $TIME => restart." | mail > > >>> [email protected] -s 'Web2py fail!' > > >>> /etc/init.d/web2py restart > > >>> else > > >>> echo "$TIME $PID $MEM OK">> $LOG > > >>> fi > > >>> else > > >>> echo "$TIME FAIL">> $LOG > > >>> echo "Web2py failed on $TIME" | mail [email protected] -s 'Web2py > > >>> fail!' > > >>> /etc/init.d/web2py restart > > >>> fi > > > >>> I know I should find time to try to examine cause of memory leaking > > >>> with guppy-heapy. But I think the crashing is another issue, not > > >>> directly related to the leaking. Access logs revealed no direct > > >>> relation to any particular controller or function. Also, after web2py > > >>> upgrade it has not changed. > > > >>> Do you have any idea how to reveal the cause of crashing? > > > >>> Thanks! > > >>> David
