What do you get if you run:
ulimit -a
Maybe they have some sort of hard memory limits in place and you are
hitting that.
Graham
2008/9/30 Pigletto <[EMAIL PROTECTED]>:
>
> Now, again, my application is working with the same setup as before
> (without GLOBAL). I don't know why this started without segfault now.
> Nothing has changed.
> I have to mention that the issue that caused I was not able to start
> my application today morning was
> because my memory was over the limit (before this I was disconnected
> while gdb'ing my app on another Apache instance and gdb process was
> hung using too much memory)
> so webfaction killed my processes. After my processes were killed I
> had to start everything and I was not albe to make one of my apps
> running (as you have seen already).
> So, important thing is that there were no changes in application code
> and no changes in apache configuration. Currently it works again and I
> can't do more debugging - it doesn't want to segfault.
>
>
> I've added some print statements as you've suggested but I think that
> wsgi script was imported properlywhen segmentation fault has occured
> becouse LoggingMiddleware had written empty oheaders.. and ocontent..
> files.
>
>
>> Can you explain to me how WebFaction process/memory limits work?
> There are no limits for number of processes only for memory usage.
>
>> If you don't have issues with number of processes and only overall
>> memory usage, then create a separate daemon process group for each
>> application with it being forced to run in main interpreter of its own
>> process. Thus:
>> <Directory /home2/(...)/rek_project-2/>
>> WSGIProcessGroup rek-prod-app-2
>> WSGIApplicationGroup %{GLOBAL}
>> Order deny,allow
>> Allow from all
>> </Directory>
>>
>> </VirtualHost>
>>
>> This would end up with similar memory usage, the difference being that
>> the application instances are in separate processes rather than
>> separate sub interpreters of same process.
> OK I'll try this.
>
> Strange thing is that I had no segmentation faults for two days (since
> my previous post), and today morning I've seen them one after one.
> I think about things like: maximum requests per child setting in
> apache, something with threading in apache, memcached - was not
> started while I was trying to start my application, but when I've
> switched to %{GLOBAL}, memcached was still down and it worked...
> I had segmentation faults before (with locmem caching, so it is not
> issue with memcached). AFAIR I saw some segfaults before using django-
> compress. Maybe this is something nasty in psycopg2. I think about
> adding print statements to all my middlewares and functions. This
> thing is really hard to debug especially on the server that is used by
> real users.
>
> Thank you very much for your help so far.
>
> --
> Maciej Wisniowski
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
