BTW, are you using a VPS. Wander is related issue to one I know about,
resulting from how VPS handles virtual memory allocations.

Documentation on original issue at:

  
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Memory_Constrained_VPS_Systems

Graham

2009/2/19 Graham Dumpleton <[email protected]>:
> 2009/2/19 simon <[email protected]>:
>>
>> Just like to share some findings I've had over the past week with a
>> django site that does a reasonable amount of traffic, up to 15k pages
>> per hour. I thought I'd try switching to apache 2.2 worker with
>> modwsgi in embedded mode for the lot, both django and media. If we can
>> thread it these days, why not let it serve media with keep alives and
>> all. Under this configuration, I suspect the extra of apache vs
>> lighty, nginx etc for serving media would be negligible. Previously,
>> we used to run lighttpd for media with 2.0 prefork modpython for
>> django.
>>
>> Anyway, when we first went live with modwsgi, the server kept buckling
>> under load.
>>
>> Turned out to be ThreadStackSize. I reckon that could be spelt out a
>> little louder in the docs (which are otherwise fantastic, btw). We're
>> on debian lenny. So here it is --
>>
>> ThreadStackSize 524288
>>
>> For now I seem to have settled on this --
>>
>>    StartServers          4
>>    MaxClients          256
>>    MinSpareThreads     256
>>    MaxSpareThreads     256
>>    ThreadsPerChild     64
>>    MaxRequestsPerChild 10000
>>    ThreadStackSize 524288
>>
>> That's with embedded mod wsgi under worker mpm. Keepalive timeout 5
>> seconds, which seems long enough to me.
>>
>> I've compared this against various combinations of running daemonised,
>> prefork/processes vs theads etc but this seems to provide both lower
>> cpu and higher throughput.
>
> Hmmm, I am a bit surprised that thead stack size mattered. Unless
> operating systems are different, the thread stack size should only
> matter as far as virtual memory size reserved, at least initially.
> This would only convert to physical memory if the stack was actually
> used, but if it went as far as allocating significant amounts of the
> stack to be an issue, then would have expect smaller stack size to be
> a problem due to being too small.
>
> I'll have to do some reading about what thread stack size in operating
> systems really means. The only reason I can think of where large stack
> size would be an issue, if not actually being physically allocated, is
> that it creates a sparser image in virtual memory. Thus the context
> switcing behaviour may be quite a bit different.
>
> My operating system memory management knowledge is very very rusty
> though, so my idea of what is going on is probably very wrong and
> doesn't fit with modern operating systems.
>
> If anyone has good pointers to sites which explain how stack
> allocation works in Linux or other modern operating systems, would be
> appreciated. Up to know I believe the thread stack size to only be an
> issue where VPS system counted virtual memory into VPS limits.
>
> BTW, are you attempting to use WSGIImportScript to preload your WSGI
> script and therefore Django code modules?
>
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to