On Jan 7, 3:55 pm, Graham Dumpleton <[email protected]> wrote: > 2010/1/8 Lukasz Szybalski <[email protected]>: > > > Hello, > > I am running trac on modwsgi with over 500 tickets a day entered into > > the system and around 15 people accessing the system. There is a > > memory leak in trac version I am using. The newer version has this > > supposedly fixed but I need to wait until that version is in Debian > > Repository. > > > What I want to know is how can I setup modwsgi to serve this app best. > > What seems to happen on my 3 processes and 10 threads each, is that > > 1st process does most of the work. > > Hmmm, that shouldn't occur. The way the global cross process mutex is > managed for the listener socket means that there should be a > reasonable balancing of requests between processes. If you aren't > seeing that, not sure why at this point. > > > It grows in memory and after > > reaching 30% of the memory it starts to slow down/will halt sometimes, > > while the other 2 processes are barely getting any traffic based on > > their memory consumption. If I could tweak the process/thread count so > > that each process is getting equal amount of traffic then my apache > > reloading could be limited to once a month hopefully instead of every > > 5 days. > > > Any insides on how to configure it so that each process does the work > > evenly. > > Common practice with Python web applications that leak memory is to use: > > maximum-requests=10000
Nice. I will set this up and will see how it goes. > > as option to WSGIDaemonProcess. Pick number of requests as appropriate. > > This will cause daemon process to be automatically restarted after > that many requests being handled by that process. > > That way you can have restarts occurring without you need to intervene > manually at least. > > If applications hosted by a daemon process group aren't used that > often and want to reclaim memory when idle, you can also look at the > option: > > inactivity-timeout=60 > Its not so much inactive processes that take the memory, so I'll stick to the first option. Example right now we had: (out of 3 from top command) apache process 1 - 19.0% memory apache process 2 - 17.5% memory apache process 3 - 4.8% memory Thanks for you help. Lucas > This will cause a daemon mode process to be restarted after 60 seconds > on inactivity. > > Note that if using maximum-requests, always a good idea to use > multiple processes in daemon process group so that other processes can > handle requests while it is restarting. > > If startup cost of loading a Python application is large if done on > first request, also want to consider looking at preloading. For > mod_wsgi 2.X+ look at WSGIImportScript directive. For mod_wsgi 3.X+ > you can also trigger preloading by using both process-group and > application-group options to WSGIScriptAlias instead of separate > WSGIProcessGroup/WSGIApplication. Being bound to WSGIScriptAlias, > mod_wsgi knows where it can preload it. > > 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.
