Envoyé de mon iPhone
On 8 janv. 2010, at 21:33, Graham Dumpleton
<[email protected]> wrote:
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
.
--
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.
