saída strace estranha do processo httpd do apache executando django com mod_wsgi

Question

Tenho cerca de 12 processos httpd em execução para uma caixa aws do RHEL que ninguém está acessando no navegador (caixa dev compartilhada da equipe). Esses processos juntos estão consumindo mais de 1,8 GB na caixa dev, e eu vi até 6 GB em produção. Cada um desses processos consome cerca de 800 MB como por ps aux. Eu fiz um strace em um deles e deixei por um tempo para encontrar:

<venv>/django/contrib/flatpages/templatetags/analytical  0x7fff37ef41a0) = -1 ENOENT (No such file or directory)
<venv>/django/contrib/flatpages/templatetags/analytical.py, O_RDONLY) = -1 ENOENT (No such file or directory)
<venv>/pagination/templatetags/expert_tags.py, O_RDONLY) = -1 ENOENT (No such file or directory)
<venv>/django/templatetags/raven.py, O_RDONLY) = -1 ENOENT (No such file or directory)
<vevn>/django_extensions/templatetags/raven.py O_RDONLY) = -1 ENOENT (No such file or directory)

Existem; com uma piada, milhares dessas mensagens ENOENT duram apenas 5 minutos. Todos os tipos de arquivos diferentes.

Uma sequência de 3 outros processos mostra algo também interessante

read(4, 0x7fff37efa00f, 1)              = -1 EAGAIN (Resource temporarily unavailable)

Qualquer forma de descobrir qual Recurso está sendo mencionado aqui?

Não sou especialista em programação de sistemas operacionais, mas presumo que isso não seja normal? Alguma idéia de como eu posso descobrir o que está causando isso? Como evitar isso?

Estranhamente, este raven.py é realmente um arquivo perdido, mas nós temos uma biblioteca de terceiros no ambiente virtual chamada

raven (3.5.1)

    

Answer 1

Embora ainda não tenha certeza do porquê de tantos ENOENTs, houve uma falta de compreensão da configuração do apache. Eu fiz uma suposição de que o mod_wsgi estava sendo executado como um daemon, quando ele estava sendo executado no modo incorporado. A seção apache worker.c definiu o número de processos para 8 com uma expansão de 25 e é por isso que havia tantos processos de reserva.

Cada processo reservava cerca de 800 MB de espaço de VM e cerca de 120 MB de RAM. Uma vez mod_wsgi foi alterado para um daemon, esses números desceu para cerca de 200MB para o espaço VM, e 8MB para RAM! O consumo geral de memória do apache caiu de mais de 1 GB para 64 MB!