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