Sortie étrange du process httpd d'apache exécutant django avec mod_wsgi

J'ai environ 12 process httpd en cours d'exécution pour une boîte RHEL aws que personne ne frappe dans le browser (boîte de développement de l'équipe partagée). Ces process représentent set plus de 1,8 Go sur la boîte de développement, et je l'ai vu jusqu'à 6 Go à la production. Chacun de ces process consum environ 800 Mo par ps aux. J'ai fait une contrainte sur l'un d'entre eux et l'ai laissé un moment pour find:

<venv>/django/consortingb/flatpages/templatetags/analytical 0x7fff37ef41a0) = -1 ENOENT (No such file or directory) <venv>/django/consortingb/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) 

Il y a; sans blague, des milliers de ces messages ENOENT sur une durée de seulement 5 minutes. Tous les types de files différents.

Une strace de 3 autres process montre quelque chose d'aussi intéressant

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

Une façon de savoir quelle ressource est référencée ici?

Je ne suis pas un expert en programmation OS, mais je présume que ce n'est pas normal? Une idée de la façon dont je peux savoir ce qui cause cela? Comment l'empêcher?

Curieusement, ce raven.py est bien sûr vraiment un file manquant, mais nous avons une bibliothèque de tiers dans l'env virtuel appelé

 raven (3.5.1) 

One Solution collect form web for “Sortie étrange du process httpd d'apache exécutant django avec mod_wsgi”

Bien que toujours pas vraiment sûr de pourquoi tant d'ENOENT, il y avait une mauvaise compréhension de la configuration d'apache. J'ai supposé que mod_wsgi fonctionnait comme un démon, lorsqu'il fonctionnait en mode embedded. La section apache worker.c a défini le nombre de process à 8 avec une extension de 25 et c'est pourquoi il y avait tant de process de rechange.

Chaque process réservait environ 800 Mo d'espace VM et environ 120 Mo de RAM. Une fois que mod_wsgi a été changé en un démon, ces nombres sont descendus à environ 200 Mo pour l'espace VM et 8 Mo pour RAM! La consommation globale de memory par apache est passée de plus de 1 Go à 64 Mo!

  • Des centaines de process zombies shornent puis meurent
  • Est-il possible d'get l'état de sortie du process zombie à partir du shell?
  • Que puis-je faire lorsque mon server web (Apache / 2.2.3 sur Centos 5.5) prend plus de 10 secondes pour répondre à une request Web nagios sur le port 80
  • Supprimer un process zombie de la table de process
  • Comment puis-je éviter que mon server ne soit bloqué par des zombies de ce travail Ubuntu Cron pour supprimer les sessions PHP?
  • Analyse de crash du kernel Linux. Processus bloqués, IO et attente ininterrompue
  • Comment libérer un port ouvert par process mort?
  • Que se passe-t-il lorsque pid_max est atteint
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.