On Feb 19, 12:44 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I did as you suggest, moved apache2-mpm-worker and run a cronjob that
> will restart processes that take more 50% CPU.
> Now it seems to be snappy, steady memory use and it is using less then
> 1/2 of the memory I have (256MB).

As a fail safe for a runaway process, you can set yet another option
to WSGIDaemonProcess to trigger a process shutdown and restart. This
option is:

  cpu-time-limit=300

That is, once the process has consumed a total of 300 seconds of CPU
time it will automatically restart it. This option was added in
mod_wsgi 3.0.

Although it will curtail a blatant runaway process, normal processes
will obviously still eventually accumulate CPU time through normal
use, so it will also act as a periodic restart trigger for a process
even under normal operation. That is similar to how maximum-requests
option would also trigger a restart but based on number of requests.

Graham

> Thank you again.
>
> Massimo
>
> On Feb 18, 6:56 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>
>
>
> > On Feb 19, 11:39 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > You are right. I had
>
> > > Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g mod_wsgi/1.3 Python/
> > > 2.5.2 configured
>
> > > Now I upgraded:
>
> > > Apache/2.2.8 (Ubuntu) mod_wsgi/4.0-TRUNK Python/2.5.2 mod_ssl/2.2.8
> > > OpenSSL/0.9.8g configured
>
> > You probably want to avoid mod_wsgi subversion repository trunk. Use
> > instead:
>
> >  http://modwsgi.googlecode.com/svn/branches/mod_wsgi-3.X
>
> > The trunk is where I develop and play with stuff for next major
> > version. I try not to break things, but always safer to avoid trunk.
>
> > The branch just gets the important fixes applied.
>
> > I will be releasing a mod_wsgi 3.2 tarball soon hopefully with a
> > couple of fixes, but the only one which is known to affect anyway is
> > one for FreeBSD users. Thus you could have just use the mod_wsgi 3.1
> > tarball release.
>
> > Graham
>
> > > and now I see that the process using most of the ram is
>
> > > www-data 30743  1.9 10.1 449980 26732 ?        Sl   00:37   0:00
> > > (wsgi:web2py)     -k start
>
> > > Yes since the BEAUTIFY bug was fixed I cannot say there is a problem
> > > anymore.
>
> > > Thanks for your help.
>
> > > Massimo
>
> > > On Feb 18, 6:04 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> > > wrote:
>
> > > > On Feb 19, 10:36 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > > My setup is exactly the one generated by this file
>
> > > > >http://code.google.com/p/web2py/source/browse/scripts/setup-web2py-ub...
>
> > > > > I did apt-get install mod-mpm-prefork
>
> > > > > I do not know which mod_wsgi I have. How how I check? Id just did apt-
> > > > > get install mod_wsgi on ubuntu 8.04.
>
> > > > Ubuntu still has a quite old mod_wsgi version in the main repository,
> > > > possibly even on mod_wsgi 1.X given you are using ancient ubuntu 8.04.
> > > > The latest mod_wsgi version is 3.1 and if can you should use that.
>
> > > > If you weren't using an ancient version of mod_wsgi I would have
> > > > suggested you change the configuration line:
>
> > > >   WSGIDaemonProcess web2py user=www-data group=www-data
>
> > > > to:
>
> > > >   WSGIDaemonProcess web2py user=www-data group=www-data display-name=%
> > > > {GROUP} maximum-requests=5000 inactivity-timeout=60
>
> > > > The 'display-name' option with that value will cause the process to be
> > > > listed in 'ps' output as '(wsgi:web2py)'. That way is easier to
> > > > identify separately from core Apache server processes. This option was
> > > > only added in mod_wsgi 2.0.
>
> > > > The 'maxiumum-requests' option would cause daemon process to be
> > > > shutdown and restarted after 5000 requests. That way if you do have a
> > > > problem with cache cleaning or Python object reference counting cycles
> > > > which cant be broken by the Python garbage collector, then you at
> > > > least throw everything away and start over again every so often.
>
> > > > The 'inactivity-timeout' option is another way of forcing a process
> > > > shutdown and restart to reclaim memory and start over. In this case if
> > > > no requests are received in 60 seconds since the last request and so
> > > > application is idle, it will shutdown and restart the process. This
> > > > option was only added in mod_wsgi 2.0.
>
> > > > To check which version of mod_wsgi is running you can look at the
> > > > startup messages for Apache, presuming ubuntu hasn't hacked the
> > > > startup message to disable display of Apache module information. The
> > > > message will be of the form:
>
> > > >   Apache/2.2.2 (Unix) mod_wsgi/1.0 Python/2.3.5 configured
>
> > > > If you can't find that in main Apache error log from time when Apache
> > > > last restarted, then you will need to work out which version is
> > > > installed from the ubuntu packaging system.
>
> > > > > Now that fixed the BEAUTIFY but the problem is no longer as severe as
> > > > > before but I do see one process (the multi-threaded one) consume more
> > > > > memory than everything else.
>
> > > > Which is the mod_wsgi daemon process which holds the web2py instance.
> > > > It will obviously be bigger, but if it keeps growing then you likely
> > > > have an issue with the application. There has never been any issue
> > > > with mod_wsgi which would see such memory growth.
>
> > > > If you were using mod_wsgi 2.X (preferably 2.5 or later), then those
> > > > options to WSGIDaemonProcess would at least allow it to recover itself
> > > > whil you sort out what the real problem is.
>
> > > > Graham
>
> > > > > Massimo
>
> > > > > On Feb 18, 4:11 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> > > > > wrote:
>
> > > > > > On Feb 19, 6:40 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > > > > Yes.
>
> > > > > > > I am running apache2 and I see this:
>
> > > > > > > www-data  6215  0.0  0.0 130400   164 ?        S    16:52   0:00 
> > > > > > > /usr/
> > > > > > > sbin/apache2 -k start
> > > > > > > www-data  6250  0.0  0.2 130296   608 ?        S    16:52   0:00 
> > > > > > > /usr/
> > > > > > > sbin/apache2 -k start
> > > > > > > www-data  6312  0.0  0.0 130296   128 ?        S    16:53   0:00 
> > > > > > > /usr/
> > > > > > > sbin/apache2 -k start
> > > > > > > www-data  6320 23.7 57.5 695308 151028 ?       Sl   16:54   0:21 
> > > > > > > /usr/
> > > > > > > sbin/apache2 -k start
> > > > > > > www-data  6663  0.0  0.2 130296   756 ?        S    16:55   0:00 
> > > > > > > /usr/
> > > > > > > sbin/apache2 -k start
> > > > > > > www-data  6665  0.0  0.2 130296   664 ?        S    16:55   0:00 
> > > > > > > /usr/
> > > > > > > sbin/apache2 -k start
> > > > > > > www-data  6666  0.0  0.2 130296   672 ?        S    16:55   0:00 
> > > > > > > /usr/
> > > > > > > sbin/apache2 -k start
> > > > > > > 1000      7070  0.0  0.3   5164   828 pts/0    R+   16:55   0:00 
> > > > > > > grep
> > > > > > > apache
> > > > > > > root     13264  0.0  0.0 130160   156 ?        Ss   15:50   0:00 
> > > > > > > /usr/
> > > > > > > sbin/apache2 -k start
>
> > > > > > > Look at process 6320. It is using way more memory than any other 
> > > > > > > one.
> > > > > > > Eventually it will fill the ram. Seems like a memory leak. Only 
> > > > > > > one
> > > > > > > process does it. I will it and another process takes his place.
> > > > > > > What is going on?
>
> > > > > > > I have never seen this problem before. Looks like a memory leak 
> > > > > > > and
> > > > > > > seems related to this:
>
> > > > > > >http://www.paulstimesink.com/post/2005/05/21/memory-leak-in-apache/
>
> > > > > > Likely unrelated because for you it is affecting only one process.
>
> > > > > > > For now I am following their suggestions and we'll see.
>
> > > > > > Presuming you are now running mod_wsgi, post your Apache 
> > > > > > configuration
> > > > > > snippet for how you set mod_wsgi up.
>
> > > > > > Specifically, confirm that you are using daemon mode? Also indicate
> > > > > > which version of mod_wsgi you are using.
>
> > > > > > If you have an incremental memory growth problem because of web2py,
> > > > > > there are various things one can do in mod_wsgi daemon mode
> > > > > > configuration to combat the issue until you work out the real cause.
>
> > > > > > So long as you are using daemon mode, that you are using prefork MPM
> > > > > > is not a big deal.
>
> > > > > > Graham
>
> > > > > > > Massimo
>
> > > > > > > On Feb 18, 12:22 pm, Geo <ssscript...@gmail.com> wrote:
>
> > > > > > > > Hi guys!
>
> > > > > > > > I've been trying to access the web2py website for the last 
> > > > > > > > couple of
> > > > > > > > days, with very little success. Most of the time I get a "The
> > > > > > > > connection was reset" message, and if somehow I get a 
> > > > > > > > connection, the
> > > > > > > > navigation is very slow.
>
> > > > > > > > Is there some problem on the server side?

-- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en.

Reply via email to