Can you provide further confirmation on what exactly you are seeing. In what you have described so far you keep talking about available free memory for the system as a whole. This generally isn't a helpful measure as UNIX like operating systems do have a tendency to use up all available free physical memory for temporary buffer space for caching stuff from the file system etc. The operating system should though release such temporary buffer space automatically to an extent when the physical memory is running low and real live processes actually want to use it.
In monitoring the Apache and mod_wsgi daemon processes, does the 'RES' figure for resident memory keep growing over time? A figure of 70-80MB is not out of the ordinary for Django applications. Alternatively does the 'VIRT' memory usage grow in a way you are concerned about? It is the increases over time of both these figures for all the Apache processes (child workers and mod_wsgi daemon processes) that is more of a concern in respect of this being attributed to your WSGI application. Now, do also be aware that mod_wsgi 3.2 is very old and out of date. There have been security related fixes since then and for such an old version there is no guarantee that a Linux vendor has back ported the fixes to that old version. Apache 2.2 is also old and how it is implemented in parts can result in the Apache child worker processes growing in memory use in a bad way when dealing with slow HTTP clients. This issue doesn't exist in Apache 2.4. The very latest mod_wsgi versions also have protection against the lack of flow control in Apache 2.2 that causes the increased memory usage. Graham On 10/11/2014, at 4:57 AM, sags <[email protected]> wrote: > Hi Graham, > > I am using apache version 2.2 and mod_wsgi 3.2 > > On doing htop, I am getting the following: > PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command > 23309 apache 20 0 563M 70828 6632 S 0.0 1.8 0:00.38 > (wsgi:main) > 23205 apache 20 0 668M 80128 7660 S 0.0 2.0 0:02.39 > (wsgi:main) > 23204 apache 20 0 563M 70828 6632 S 0.0 1.8 0:02.18 > (wsgi:main) > 23311 apache 20 0 668M 80128 7660 S 0.0 2.0 0:00.37 > (wsgi:main) > 23294 apache 20 0 668M 81332 7656 S 0.0 2.1 0:00.39 > (wsgi:main) > 23206 apache 20 0 668M 81332 7656 S 0.0 2.1 0:02.45 > (wsgi:main) > > > > > On Saturday, November 8, 2014 11:03:16 PM UTC-5, Graham Dumpleton wrote: > > On 09/11/2014, at 6:24 AM, sags <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
