On 4 August 2010 00:16, John-Scott Atlakson
<[email protected]> wrote:
> On Aug 3, 2010, at 9:08 AM, Aljoša Mohorović wrote:
>
>> although i understand that optimization depends on actual hardware and
>> priority of other services on system, i hope that (with restrictions
>> to specific ec2 instance), it's possible to discuss optimization
>> recommendations for this case.
>>
>> my current testing instance has this in config:
>> <IfModule mpm_worker_module>
>>    ServerLimit          64
>>    StartServers         32
>>    MaxClients           150
>>    MinSpareThreads      25
>>    MaxSpareThreads      75
>>    #ThreadLimit          64
>>    ThreadsPerChild      25
>>    MaxRequestsPerChild  0
>> </IfModule>
>>
>> i'm using ab and httpref to test performance but i have very little
>> experience with mpm_worker so any tips/recommendations are
>> appreciated.
>>
>> Aljosa Mohorovic
>
> You should probably leave your ThreadLimit in place. This setting cannot be 
> changed without a full server stop/start and is put in place as a safety 
> precaution/hard upper limit on the number of threads that can be set in 
> ThreadsPerChild (which can be changed without a full stop/start) [1].

The default if not set for worker MPM is 64 anyway.

Note that that is a thread limit per process, not overall.

> MPM worker is multiprocess/multithreaded, so these settings will create 32 
> worker processes on server start, with each set to have 25 threads each.

I am not sure it will actually.

The reason is that the limit on number of process is capped by:

   MaxClients / ThreadsPerChild

Thus, the maximum number of child processes that Apache will allocate
space for in tables and thus maximum it will create is 6.

Snippets of code from worker.c is:

    ap_daemons_limit = max_clients / ap_threads_per_child;

    remaining_children_to_start = ap_daemons_to_start;
    if (remaining_children_to_start > ap_p_daemons_limit) {
        remaining_children_to_start = ap_daemons_limit;
    }

I find it odd that Apache doesn't log a warning about this sort of
configuration error.

> This means you've got 32 processes * 25 threads each which is 800 total 
> threads on startup.
> Given that you've got MaxClients set to 150, this looks like 650 threads too 
> many.

Given I reckon only 6 processes created, is actually 150 threads. The
other processes simply never get started.

> MaxClients should be set to ThreadsPerChild * ServerLimit [2].

Not necessarily.

In default Apache configuration files ServerLimit isn't even set,
meaning it defaults to 16 for worker MPM.

This value is a maximum number of processes that would be allowed. How
many are actually used is based on the formula:

  MaxClients / ThreadsPerChild

That ServerLimit is higher allows for number of processes to be
adjusted by modifying either MaxClients or ThreadsPerChild, without
performing a stop/start of Apache. Although the figure was quite high,
the amount of memory involved is likely minimal as only relates to a
process table and possibly space in a shared memory segment used by
all processes.

I would suggest that configuring it so that you are immediately at
ServerLimit is a bad idea as prevents you from doing those adjustments
without a stop/start. Have the head room and you can do a restart or
graceful restart and so impact on operation of web server not as
significant.

> However, depending on how much RAM you have available for Apache and the RAM 
> requirements of your web application, your current ServerLimit may be way too 
> high.

The issue of memory usage by Apache child server processes hangs on
whether using embedded mode or daemon mode. If using embedded mode
then it comes into consideration, but not really if using daemon mode
as number of processes configured separately for daemon mode. The
Apache server child process will still take up some memory, so still
have to allow for it, but not much.

> As for optimizing, I'm assuming you are running modwsgi in daemon mode. What 
> are your modwsgi settings? How much RAM do you have available for Apache? 
> Will Apache be serving static requests? Other non-modwsgi applications (PHP, 
> etc.)?

Yes, whether you are using embedded mode or daemon mode and how it is
configured needs to be known, as does whether using Apache for
handling static requests, and if not whether Apache is front facing
web server, or hidden behind a proxy or load balancer.

In short though, what StartServers was set to was above what it can
actually be and Apache would have forced it to what formula above
calculated. Because it was forced to that value, the min and max
spares probably became irrelevant and it would have always run at that
value of 6 processes. That the number of processes doesn't vary is
possibly good if using embedded mode, but will explain the mechanics
of why when know if using embedded mode or not.

For a bit of related reading about that latter issue though, see:

  http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html

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