[modwsgi] mod_wsgi v3.5 Installation within Python
From reading the Python PyPi Index descriptionon for mod_wsgi v4.3, I understand that mod_wsgi v4.3 can be installed within the Python Interpreter. Can the latest release of mod_wsgi v3.5 be installed within the Python Interpreter as well? If I install mod_wsgi within the Python Interpreter do I need to remove the mod_wsgi3.5.so module reference from the Apache httpd.conf file to prevent versioning and environment issues? Thanks! -- You received this message because you are subscribed to the Google Groups modwsgi group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
[modwsgi] Re: mod_wsgi v3.5 Installation within Python
Some additional Version background on my system environment: - Platform: Windows 7 Pro 32-bit - Python Installation: - Version 2.7.6 32 Bit - (Default Install for Multiple User; User installed had Admin privileges) - LAMP Stack: XAMPP v1.8.2 32-bit - Apache Server: v2.4.7 - mod_wsgi Install: Binary: mod_wsgi‑3.5.ap24.win32‑py2.7.zip On Saturday, November 8, 2014 10:10:24 AM UTC-8, Anthony Dycks wrote: From reading the Python PyPi Index descriptionon for mod_wsgi v4.3, I understand that mod_wsgi v4.3 can be installed within the Python Interpreter. Can the latest release of mod_wsgi v3.5 be installed within the Python Interpreter as well? If I install mod_wsgi within the Python Interpreter do I need to remove the mod_wsgi3.5.so - private http://mod_wsgi3.5.so module reference from the Apache httpd.conf file to prevent versioning and environment issues? Thanks! -- You received this message because you are subscribed to the Google Groups modwsgi group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
[modwsgi] django memory issues
Hi Graham, I am been reading your blogs and posts on mod_wsgi configurations. We build some programming modules using an open source django based application originally developed for MOOCs. We modified the application based on our requirements but we didn't change much underlying frame work of that open source code.The application is running fine but server some time crashed due to out of memory issue. At a time around 30 students use this application in a class. We monitored, using free -m command, approximately 30 students when using the application at the same time, the memory consumption approximately goes down by 200-300 MB. But the problem is once students log out from the sessions, the* memory doesn't seem to get released*. Due to which the memory consumption goes on increasing again and again. For the time being we have wrote a script to clear the cache if memory goes below 500 MB using echo 1 /proc/ .../drop_caches and it seems to be freeing lot of memory. Is there some permanent solution to it. We are using red hat VM server for hosting our application. We except more teachers using this application, which means traffic is going to be high in future. FYI: We are using mod_wsgi deamon mode with processes = 2 and Threads = 15 Is it due to the django or could it be due to OS or httpd configuration issues? I would appreciate your feedback on it. Thanks -- You received this message because you are subscribed to the Google Groups modwsgi group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
Re: [modwsgi] Problem loading django from apache
You need to find the Apache modules directory for your Linux version. I don't know where RedHat keeps it. In that directory look for the mod_wsgi .so file. I am not sure if it will be called mod_wsgi.so or whether the distro changes the name such it has the Python version as part of the name so that mod_wsgi packages for different Python versions don't clash. Whatever you find, run: ldd mod_wsgi.so on it. Changing the name of the file you run the command on to match if the name is different. Then find in the Apache configuration files the LoadModule directive for mod_wsgi and see what it refers to. Post the details of what mod_wsgi .so files exist in the Apache modules directory, what the output of ldd is and what the LoadModule line in Apache says. Graham On 08/11/2014, at 12:32 AM, robert brook software.by.pyt...@gmail.com wrote: These are the components we have on the machine. Can you comment as to whether there may be a mismatch on the versions? And if there is a mismatch, what the next steps should be. Is it an issue theat the version of wsgi appears to be 3.4 and python on the machine is 3.3? Thanks in advance. [root@itd-dv-wt-lap1 jlee]# rpm -qa | grep mod_wsgi mod_wsgi-3.4-1.pulp.el6sat.x86_64 python33-mod_wsgi-3.4-14.el6.x86_64 * Python 3.3.2 (default, Mar 20 2014, 20:25:51) [GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux On Thursday, November 6, 2014 4:26:57 PM UTC-5, robert brook wrote: I have started apache on a Linux Red Hat 6 server, running python3.3 and django1.7 There is also python 2.6.6 on the machine. Red hat places that version their for administrative purposes and cannot be removed. I am getting the following error log. Can anyone give me insight into this error. Is the error referring to an issue with 2.6.6 (reference the 2nd line in the log). Or could the mod_wsgi be wrong? Thanks in advance * [Thu Nov 06 15:51:59 2014] [notice] Digest: done [Thu Nov 06 15:51:59 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_wsgi/3.4 Python/2.6.6 configured -- resuming normal operations [Thu Nov 06 15:53:30 2014] [error] housing.settings [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] mod_wsgi (pid=23433): Target WSGI script '/tmp/housing_x/housing/wsgi.py' cannot be loaded as Python module. [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] mod_wsgi (pid=23433): Exception occurred processing WSGI script '/tmp/housing_x/housing/wsgi.py'. [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] Traceback (most recent call last): [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] File /tmp/housing_x/housing/wsgi.py, line 13, in module [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] from django.core.wsgi import get_wsgi_application [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] File /opt/rh/python33/root/usr/lib/python3.3/site-packages/Django-1.7-py3.3.egg/django/core/wsgi.py, line 2, in module [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] from django.core.handlers.wsgi import WSGIHandler [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] File /opt/rh/python33/root/usr/lib/python3.3/site-packages/Django-1.7-py3.3.egg/django/core/handlers/wsgi.py, line 11, in module [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] from django import http [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] File /opt/rh/python33/root/usr/lib/python3.3/site-packages/Django-1.7-py3.3.egg/django/http/__init__.py, line 2, in module [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] from django.http.request import (HttpRequest, QueryDict, [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] File /opt/rh/python33/root/usr/lib/python3.3/site-packages/Django-1.7-py3.3.egg/django/http/request.py, line 11, in module [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] from django.conf import settings [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] File /opt/rh/python33/root/usr/lib/python3.3/site-packages/Django-1.7-py3.3.egg/django/conf/__init__.py, line 9, in module [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] import importlib [Thu Nov 06 15:53:30 2014] [error] [client 192.168.111.117] ImportError: No module named importlib -- You received this message because you are subscribed to the Google Groups modwsgi group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups modwsgi group. To
Re: [modwsgi] mod_wsgi express: 'mod_wsgi.server' Documentation??
On 08/11/2014, at 1:21 AM, Jon Flash funksw...@gmail.com wrote: I am using 'mod_wsgi' express version with my Django application(s). I was wondering if there is any documentation for the 'mod_wsgi.server' INSTALLED_APP. What in particular are you wanting to know about it? The 'mod_wsgi.server' package is only available if you have done a pip install of 'mod_wsgi' and so installed the mod_wsgi-express script as well. The mod_wsgi.server package mainly exists to support mod_wsgi-express and so also the runmodwsgi management command for Django manage.py when 'mod_wsgi.server' is listed in the installed applications as it uses the same underlying mechanism to configure and launch Apache. The latter works by 'mod_wsgi.server' package having a 'management' sub package which Django looks for management commands to extend what is available for manage.py. There is only minimal documentation for mod_wsgi-express at this point and it can be found at: https://pypi.python.org/pypi/mod_wsgi You can also find descriptions of each command line option to 'start-server' of mod_wsgi-express by running: mod_wsgi-express start-server --help Documentation is lacking right now as I am treating mod_wsgi-express as a bit of a fun project to get myself interested in working on mod_wsgi again after having neglected it for quite some time. Granted I haven't said much publicly about mod_wsgi-express, there also hasn't been a great deal of interest in it yet either to make me feel motivated to focus on the documentation. Also what are the downsides to using mod_wsgi express in production vs the traditional mod_wsgi / Apache installation. The main downside is that how mod_wsgi-express is installed and how it is used will upset system administrators who are overly paranoid and only trust binary packages that come with their operating system. They will also be upset because they are taken out of the loop as far as having to configure Apache themselves, so they will feel that they are loosing a measure of control and so will push back on any desire to use it. Personally I would argue this actually can be a good thing. The first reason why is that binary packages for the Linux distributions are generally woeful out of date. Most of the popular Linux distributions still only ship with mod_wsgi version 3.3 or 3.4 where as the latest version is 4.3.2. So they are more than 16 releases behind. Their argument in using binary packages from the Linux distribution is that they are supported if a LTS release of that Linux variant. That is actually mostly a load of nonsense as I don't personally actively maintain older mod_wsgi versions and the Linux distributions certainly don't. The versions they ship therefore carry bugs which could cause you problems and deny you from using features in newer versions which could make your life easier. But then they will say that the older versions will get security updates. That also is not entirely true. They may get a security fix, but that will only occur if a CERT advisory has been raised and a fix can even be back ported. Even if a CERT advisory is raised, for third party packages like mod_wsgi I know from experience that Linux distributions can take up to 6 months to get around to actually updating the binary package. So the idea that binary packages are somehow better in some way because of a quick turn around on security fixes is a bit of a fallacy. This may be true for main line core packages, but for third party packages they get very little love and you can actually be putting yourself in a bad position by not building the latest from source code yourself. The second reason is I see too many Apache configurations which are done quite badly. You will see some where people feel that the defaults are no good and start over with an empty config believing they can do better. In doing that though, they immediately throw away some of the security that the defaults provide. Even when people retain the default Apache configuration, that defaults are always tailored to static or PHP sites and so the performance for a Python web site can be quite bad as a result and a lot more resources used up than need be if things were setup right for a Python web site. So mod_wsgi-express rather than having downsides, is actually meant to improve on the sad state of affairs that can quite often exist. The idea with mod_wsgi-express is that through my experience of Apache and what makes a good configuration for Python web hosting, I can generate the configuration automatically for you. This approach will probably work for a good majority of people who are running a Python web site. It will not work for everyone though, especially where an Apache instances is shared for other purposes, and in those cases you would still have to fall back to configuring an existing Apache installation yourself. Overall the aim of mod_wsgi-express is to
Re: [modwsgi] mod_wsgi v3.5 Installation within Python
The way of installing mod_wsgi using a setup.py file using 'python' directly, or 'pip', will not be back ported to mod_wsgi 3.X as there is no point when there is a newer version of mod_wsgi available. This style of installation will likely not make its way to Windows either, or not soon. Even if it does, mod_wsgi-express would not be available on Windows. If your concern is the lack of mod_wsgi version 4.X for Windows then I wouldn't be overly concerned as you aren't missing out on much by only having mod_wsgi 3.5 binaries being available for Windows at this point because the majority of changes in 4.X relate to mod_wsgi daemon mode and mod_wsgi-express and so aren't relevant to Windows. As to what is stopping there being binaries available for Windows for mod_wsgi 4.X, it is purely the lack of updated makefiles for the Windows platforms. I don't run a Windows machine any more and can't verify any changes I might make to the makefiles. The mod_wsgi code itself still should support Windows, although with no ability to compile it on Windows myself, there is a greater chance I could be breaking things for Windows as I refactor the code and improve it. That is not intentional though. The current makefiles for the Windows platform are currently in: * https://github.com/GrahamDumpleton/mod_wsgi/tree/develop/win32 The following needs to happen for these to be brought up to date. * Compensate for the fact that the makefiles are now in a sub directory and not the parent directory of the source code. Any path names to source code files need to be changed. * Compensate for the fact that the source code files themselves are now located in the src/server subdirectory and instead of there being only one source code file, there are now many. All these source code files have to be enumerated in the makefiles and any extra build targets created appropriately. * Versions of the makefiles added for Python 3.3 and 3.4 (that for Python 3.1 can be removed). The paths for the required Microsoft C compiler for those Python versions need to be set appropriately. * Versions of the makefiles added for Apache 2.4. As I don't have Windows, what would be great is someone who could come up with the changes. Even better, provide a Python script which can be used to automatically generate the makefiles. This would be preferred as I am continually splitting out the code into more files to make it easier to work on. It would be good if I had a way of regenerating the makefiles based on what is found in the src/server directory, rather than me having to update them by hand. So what is the underlying reason as to why you asked your original question. Graham On 09/11/2014, at 7:31 AM, Anthony Dycks tfdy...@gmail.com wrote: Some additional Version background on my system environment: Platform: Windows 7 Pro 32-bit Python Installation: Version 2.7.6 32 Bit (Default Install for Multiple User; User installed had Admin privileges) LAMP Stack: XAMPP v1.8.2 32-bit Apache Server: v2.4.7 mod_wsgi Install: Binary: mod_wsgi‑3.5.ap24.win32‑py2.7.zip On Saturday, November 8, 2014 10:10:24 AM UTC-8, Anthony Dycks wrote: From reading the Python PyPi Index descriptionon for mod_wsgi v4.3, I understand that mod_wsgi v4.3 can be installed within the Python Interpreter. Can the latest release of mod_wsgi v3.5 be installed within the Python Interpreter as well? If I install mod_wsgi within the Python Interpreter do I need to remove the mod_wsgi3.5.so - private module reference from the Apache httpd.conf file to prevent versioning and environment issues? Thanks! -- You received this message because you are subscribed to the Google Groups modwsgi group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups modwsgi group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
Re: [modwsgi] Custom python paths for each site?
On 08/11/2014, at 3:05 AM, Daniela Hase daniela.hasenbr...@gmail.com wrote: If that's the case (would make sense since it's not working as expected), how can I have different python paths for each virtual host then? You simply shouldn't be using mod_wsgi embedded mode in the first place usually. http://blog.dscpl.com.au/2012/10/why-are-you-using-embedded-mode-of.html When using mod_wsgi daemon mode it becomes a lot simpler as you can customise separately the Python module search path and even the Python virtual environment used, for each mod_wsgi daemon process group. The mechanisms available are touched on in the post: http://blog.dscpl.com.au/2014/09/python-module-search-path-and-modwsgi.html In short, use a mod_wsgi daemon process per site, using the same one across 80/443 if have both http and https access. Presuming you are using a recent mod_wsgi version and not stuck with an ancient version shipped with a Linux distribution, then use the 'python-home' option to WSGIDaemonProcess to attach that daemon process group to a specific Python virtual environment. Set the 'home' option to the project directory which should be the current working directory and which also should be searched for Python modules. Finally, use 'python-path' to set extra Python module search directories, but only if they aren't already covered by the 'python-home' option for the Python virtual environment and the 'home' directory for the project location. Graham -- You received this message because you are subscribed to the Google Groups modwsgi group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
Re: [modwsgi] django memory issues
On 09/11/2014, at 6:24 AM, sags sags...@gmail.com wrote:
Hi Graham,
I am been reading your blogs and posts on mod_wsgi configurations. We build
some programming modules using an open source django based application
originally developed for MOOCs. We modified the application based on our
requirements but we didn't change much underlying frame work of that open
source code.The application is running fine but server some time crashed due
to out of memory issue. At a time around 30 students use this application in
a class. We monitored, using free -m command, approximately 30 students when
using the application at the same time, the memory consumption approximately
goes down by 200-300 MB. But the problem is once students log out from the
sessions, the memory doesn't seem to get released. Due to which the memory
consumption goes on increasing again and again. For the time being we have
wrote a script to clear the cache if memory goes below 500 MB using echo 1
/proc/ .../drop_caches and it seems to be freeing lot of memory. Is there
some permanent solution to it. We are using red hat VM server for hosting our
application. We except more teachers using this application, which means
traffic is going to be high in future.
FYI: We are using mod_wsgi deamon mode with processes = 2 and Threads = 15
Is it due to the django or could it be due to OS or httpd configuration
issues?
I would appreciate your feedback on it.
How are you monitoring memory usage and what processes are specifically taking
up the memory?
I don't understand how:
echo 1 /proc/sys/vm/drop_caches
as described in:
http://linux-mm.org/Drop_Caches
can affect the run time memory usage of specific Python web application
processes.
BTW, in monitoring memory used by Apache, ensure that if using mod_wsgi daemon
mode that you are using the option:
display-name=%{GROUP}
to the WSGIDaemonProcess directive.
By doing this it will result in the process names as shown by 'ps' and 'htop'
being the name of the mod_wsgi daemon process group name. This way you can
distinguish between normal Apache processes and the mod_wsgi daemon process
groups.
For example, for:
WSGIDaemonProcess mysite display-name=%{GROUP} processes=2 threads=15
You will see in 'ps' out:
httpd (or apache2 on some systems) running as root - Apache parent process
httpd (or apache2 on some systems) running as Apache user - Apache child
worker processes
(wsgi:mysite) - mod_wsgi daemon process group processes
if you are pinning it to an Apache processes, which of these is showing
increase memory usage.
Also, what version of Apache and mod_wsgi are you using?
Graham
--
You received this message because you are subscribed to the Google Groups
modwsgi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to modwsgi+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
