2010/1/9 Lukasz Szybalski <[email protected]>:
>
>
> 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
You haven't supplied your configuration so don't know how you have set
things up, but are you perhaps mistaking what are mod_wsgi daemon
processes and what is the Apache parent process or Apache server child
processes? If you don't name them, they will all appear as Apache
httpd process.
What you would have is:
1 Apache parent process (quite small)
m Apache server child processes (bigger, but still not that big if not
using embedded mode)
n mod_wsgi daemon process (could be quite bug)
You can identify the parent process by looking at PPID of other
processes. The pid which all but one process has as PPID will be the
parent process.
The mod_wsgi daemon processes you can separate by using the
'display-name' option to WSGIDaemonProcess to name them. Eg.
WSGIDaemonProcess mystuff display-name=%{GROUP}
will see mod_wsgi daemon processes named '(wsgi:mystuff)'.
Do note though that you will not see this name in standard 'top'
program. I believe 'htop' will show it. Otherwise only way to see it
is to use a BSD derived 'ps' program. On latter point, on Solaris for
example, you need to use /usr/ucb/ps and not /usr/bin/ps.
Check that and see what you come up with.
Graham
> 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.
--
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.
