Sites Python Django no Apache + mod_wsgi com nginx proxy: desempenho altamente flutuante

Question

Eu tenho uma caixa Ubuntu 10.04 rodando várias dezenas de sites Python Django usando mod_wsgi (modo embutido; o modo mais rápido , se configurado corretamente). O desempenho é altamente flutuante. Às vezes rápido, às vezes vários segundos de atraso. Os gráficos de fumaça estão em todo lugar.

Recentemente, também adicionei um proxy nginx para o conteúdo estático, na esperança de que isso curaria o desempenho altamente flutuante. Mas, embora tenha reduzido o número de solicitações que o Apache precisa processar significativamente, isso não ajudou com o problema principal.

Quando você clica em sites enquanto executa o htop, pode ser visto que às vezes os pedidos são quase instantâneos, enquanto às vezes isso faz com que o Apache consuma 100% da CPU por alguns segundos. Eu realmente não entendo de onde vem essa flutuação.

Eu configurei o mpm_worker para o Apache assim:

StartServers          1
MinSpareThreads      50
MaxSpareThreads      50
ThreadLimit          64
ThreadsPerChild      50
MaxClients           50
ServerLimit          1
MaxRequestsPerChild  0
MaxMemFree           2048

1 servidor com 50 threads, com um máximo de 50 clientes. Munin e apache2ctl -t mostram uma presença consistente de trabalhadores; eles não são destruídos e criados o tempo todo. No entanto, ele se comporta como tal.

Isso me diz que, quando um sub intérprete é criado, ele deve permanecer na memória, ainda parece que os sites precisam recarregar o tempo todo.

Eu também tenho uma caixa nginx + gunicorn, que funciona muito bem. Eu realmente gostaria de saber porque o Apache é tão aleatório.

Esta é uma configuração do host virtual:

<VirtualHost *:81>
    ServerAdmin [email protected]
    ServerName example.com

    DocumentRoot /srv/http/site/bla

    Alias /static/ /srv/http/site/static
    Alias /media/ /srv/http/site/media
    WSGIScriptAlias / /srv/http/site/passenger_wsgi.py

    <Directory />
            AllowOverride None
    </Directory>

    <Directory /srv/http/site>
            Options -Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all
    </Directory>

• Ubuntu 10.04
• Apache 2.2.14
• mod_wsgi 2.8
• nginx 0.7.65

Edit: Eu coloquei algum código no arquivo settings.py de um site que grava a data em um arquivo tmp sempre que ele é carregado. Agora posso ver que o site não é recarregado aleatoriamente o tempo todo, portanto, o Apache deve mantê-lo na memória. Então, isso é bom, exceto que isso não me aproxima de uma resposta ...

Editar: acabei de encontrar um erro que também pode estar relacionado a isso:

  File "/usr/lib/python2.6/subprocess.py", line 633, in __init__
    errread, errwrite)

  File "/usr/lib/python2.6/subprocess.py", line 1049, in _execute_child
    self.pid = os.fork()

OSError: [Errno 12] Cannot allocate memory

O servidor tem 600 de 2000 MB livres, o que deve ser suficiente. Existe um limite que é definido no Apache ou WSGI em algum lugar?

    

Answer 1

Eu consertei. Eu converti todos os sites de produção para usar seu próprio processo (e todos os sites de desenvolvimento todos juntos em um processo também), no modo daemon. Os gráficos do Smokeping estão muito melhores agora. O desempenho é estável.

Isso ainda me deixa sem saber por que o modo incorporado teve esses problemas, porque, até onde sei, não tive nenhum processo de criação / destruição, mas pelo menos eu tenho um servidor em execução melhor.

Editar:

Como exemplo em uma configuração de site do apache:

WSGIDaemonProcess mysite12 processes=1 threads=10 display-name=%{GROUP}
WSGIProcessGroup mysite12

E, para sites de baixa prioridade, eu coloco isso em wsgi.conf :

WSGIDaemonProcess developmentsites processes=1 threads=15 display-name=%{GROUP}

E, em seguida, em um conf apache:

WSGIProcessGroup developmentsites

Veja a diferença (também por causa do proxy nginx):

    

Answer 2

Já tentou utilizar o New Relic para tentar identificar se é um problema na sua aplicação web? Nível gratuito disponível e também um teste completo inicial. Visão geral do que pode oferecer:

• link

Se um problema específico com o aplicativo da web de serviço de back-end que é usado não se sobressair como um problema, o relatório de análise de capacidade do servidor WSGI poderá aparecer, assim como você saberá se está esgotando a capacidade. Ele também pode informar se você está sobrecarregado e desperdiçando recursos, o que, na verdade, é bastante frequente.

• link

BTW, em geral, eu recomendaria não usar 50 threads de solicitação em um processo. Você está melhor usando cerca de 5 threads e vários processos. Exatamente o que é melhor, no entanto, realmente depende do aplicativo específico, se ele está realizando muito trabalho vinculado à CPU e quanto precisa lidar com solicitações de longa execução. Se servir muitos arquivos estáticos através do mesmo Apache também pode causar impacto, com o modo daemon do mod_wsgi sendo possivelmente uma solução geral melhor.

Você também está em uma versão mod_wsgi muito antiga, embora não acredite que isso possa causar um problema.

Por fim, para evitar problemas com alguns módulos de extensão C de terceiros para o Python, se esse for o único aplicativo WSGI nesse servidor, defina:

WSGIApplicationGroup %{GLOBAL}