On 2 April 2011 07:32, Kent <[email protected]> wrote:
> I am hoping you might gracefully suggest what we might be able to do
> to improve our problem of memory usage being consumed by apache.
>
> We have a turbo gears type web server with 2GB ram which is running a
> point of sale system for about 15 or 18 stores.
>
> We are running mod_wsgi 2.5, but about to upgrade to 3.3.
>
> Is it typical for one process (wsgi:rarch) to consume virtually all
> the CPU and memory consumption while the remaining apache children
> seem to not be doing much?
With your configuration yes, that would be expected.
> Is it typical for memory consumption to increase throughout a day?
No, but that is going to be an issue with TurboGears, how you use it,
or your specific application code.
> I've been reading the release notes, was lazy initialisation of Python
> interpreter already existent with version 2.5?
That would reduce a little the memory used by the other processes, but
not your main fat one.
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 444 apache 25 0 1682m 1.1g 10m S 26.0 58.2 35:54.74 httpd
> ...
>
>
> apache .conf file:
Is this serious all you have in your apache.conf file, or have you
only shown the relevant bits?
I know some people promote the idea of throwing away the complete
Apache configuration and only adding back in the bits thought to be
necessary, but I disagree with that as the underlying C code defaults
for configuration don't actually match what Apache configuration files
setup, so removing the configuration delivered with Apache could have
unknown consequences.
> =========
> LoadModule wsgi_module modules/mod_wsgi.so
> AddHandler wsgi-script .wsgi
The AddHandler line is not needed if using WSGIScriptAlias.
> WSGIPythonHome /home/rarch/tg2env
> WSGIPythonEggs /home/rarch/tg2env/lib/python-egg-cache
You shouldn't need WSGIPythonEggs as you are using python-eggs option
to WSGIDaemonProcess directive below. The WSGIPythonEggs directive
only applies to embedded mode but you are delegating everything to a
daemon mode process.
> WSGIDaemonProcess rarch threads=15 display-name=%{GROUP} python-eggs=/
> home/rarch/tg2env/lib/python-egg-cache
> WSGIProcessGroup rarch
> WSGISocketPrefix run
I suspect that this value of WSGISocketPrefix is going to live the
socket listener files in the wrong place. If you do need to override
it like that, it would be:
WSGISocketPrefix run/wsgi
With what you have, would be left in the Apache root directory and not
in the 'run' subdirectory and not with a 'wsgi' prefix to the socket
files.
> WSGIRestrictStdout Off
>
> # we'll make the root directory of the domain call the wsgi script
> WSGIScriptAlias /tg /home/rarch/trunk/src/appserver/wsgi-config/wsgi-
> deployment.py
>
> # make the wsgi script accessible
> <Directory /home/rarch/trunk/src/appserver/wsgi-config>
> Order allow,deny
> Allow from all
> </Directory>
>
> <Location /tg/_debug>
> AuthType Basic
> AuthName "For your company's security, this link is for
> retailarchitects.com support only. Please copy the Server Debug link
> and email it to your administrator."
> AuthUserFile /home/rarch/trunk/src/appserver/debugpasswd
> Require valid-user
> </Location>
> ================
>
> Thank you so very much for any time you spare to point me in the right
> direction, documentation regarding memory management with mod_wsgi,
> etc.
TurboGears is known to have a large base memory foot print to begin
with. The size of your process though appears to be the result of
application code performing caching and not purging the cache
properly. Alternatively, objects in application and creating reference
count cycles between objects which the Python garbage collector can't
break and so they hang around.
I would probably suggest you ask about your memory problems on the
TurboGear mailing list.
Other than that, the only place that memory leaks usually come from
Apache itself are when mod_python is also loaded, but since only one
process has memory problems and certain other bits of configuration
are working, you don't appear to be doing that.
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.
