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!

  • Nagios Créer beaucoup de process zombie
  • La meilleure façon de tuer les processus d'état Zombie et D dans linux
  • Zombie process bloquant le port lors du redémarrage de Hadoop (Secondary) Namenode
  • Comment libérer un port ouvert par process mort?
  • La meilleure façon de tuer les process d'état Zombie et D dans linux
  • Est-il possible d'get l'état de sortie du process zombie à partir du shell?
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.