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).
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.
