2009/2/27 Jason Broyles <[email protected]>: > > Sorry about that, I am using Django. I do not know of any URL requests > that may have caused it to jump.
Do you have the obvious of having 'DEBUG' in Django settings file disabled. > The only thing I can think of is > maybe a search engine bot, unsure though. I do have a sitemap that has > about 100,000 pages in it. It is for a housing search application. Is > there a way I can tell this? If you think it may be to do with sitemap, suggest you try and get onto David Cramer on #django IRC. Can supply email address if need be. I remember him complaining about overhead in large sitemaps. Something about it all being generated in memory before being sent back. You may even find reference to it in #django logs. http://www.google.com/search?hl=en&client=safari&rls=en&q=site%3Abotland.oebfare.com+sitemap+DavidCramer&btnG=Search In particular, one grumble at end of: http://botland.oebfare.com/logger/django/2008/09/30/ > The maximum requests was set low to reset the Apache process so the > memory stays down. A just in case thing I did. What should it be? I > will go ahead and take out the process option and add the group in. > > On a completely unrelated note. I just saw this in the Apache > access.log.1 file. I have locked the server down via ssh and use an > RSA key to access it. It would be impossible for anyone else to be on > it. But it looks like someone used lynx in the log and tried to access > localhost admin. Strange.... > > "GET /admin HTTP/1.0" 404 303 "-" "Lynx/2.8.6rel.4 libwww-FM/2.14 SSL- > MM/1.4.1 GNUTLS/2.0.4" If you run: /usr/sbin/apachectl status Then it tries to use lynx to connect to the server. I don't know what URL it tries to use though. Graham > On Feb 26, 6:07 pm, Graham Dumpleton <[email protected]> > wrote: >> 2009/2/27 Jason Broyles <[email protected]>: >> >> >> >> > I have my server setup like the below. For some reason one of the >> > apache processes keeps jumping up to 263mb of ram. Does anyone know >> > why this might be? Also, once I restart Apache, the total memory usage >> > is around 40mb. Then when I access sites each site uses about 24mb of >> > ram. This memory is never released though. Usually if everything is >> > running normal it can run for weeks like that. This is besides the >> > problem of the 263mb process. >> >> Can you provide more information about what the application is >> implemented in, eg. Django, and what the application is doing. Have >> you been able to identify specific URL requests as causing the jump in >> memory usage? >> >> See also comments blow. >> >> >> >> > Apache info >> >> > Architecture: 64-bit >> > Server MPM: Worker >> > threaded: yes (fixed thread count) >> > forked: yes (variable process count) >> >> > Example of one site from httpd.conf >> >> > KeepAlive Off >> > ServerLimit 2 >> >> > <VirtualHost *> >> >> > ServerNamewww.somesite.com >> > ServerAlias *somesite.com >> >> > WSGIDaemonProcess somesite user=webuser group=webuser processes=1 >> >> Don't provide option 'processes=1'. It will default to one process >> anyway and setting this flag has side affect of marking >> wsgi.multiprocess as True rather than False. Yeah, sounds back to >> front, but done for a reason. >> >> > threads=10 maximum-requests=100 >> >> Why is maximum requests so low. >> >> > inactivity-timeout=172800 >> >> Add the option: >> >> display-name=%{GROUP} >> >> This will allow you to use 'ps' command to properly identify the >> process as being the WSGI daemon process. >> >> Otherwise ensure you have LogLevel directive in Apache set to 'info'. >> That will allow you to get pid for WSGI daemon process from Apache >> error logs and identify it as the fat process. >> >> > WSGIProcessGroup somesite >> >> > WSGIScriptAlias / /home/webuser/somesite.com/somesite.wsgi >> >> > </VirtualHost> >> >> Graham > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
