138 votes

Réduire l'utilisation de la mémoire de Django. Le fruit du hasard ?

L'utilisation de la mémoire augmente avec le temps et le redémarrage de Django n'est pas agréable pour les utilisateurs.

Je ne sais pas comment procéder pour établir le profil de l'utilisation de la mémoire, mais des conseils sur la façon de commencer à mesurer seraient utiles.

J'ai le sentiment qu'il y a quelques étapes simples qui pourraient produire des gains importants. S'assurer que le paramètre "debug" est défini sur "False" est un point essentiel.

Quelqu'un peut-il en suggérer d'autres ? Quelle serait l'amélioration de la mise en cache sur les sites à faible trafic ?

Dans ce cas, je fonctionne sous Apache 2.x avec mod_python. J'ai entendu dire que mod_wsgi est un peu plus léger, mais il serait délicat de changer à ce stade, sauf si je sais que les gains seraient significatifs.

Edit : Merci pour les conseils donnés jusqu'à présent. Des suggestions pour découvrir ce qui utilise la mémoire ? Existe-t-il des guides sur le profilage de la mémoire en Python ?

De plus, comme nous l'avons mentionné, il y a quelques éléments qui rendront difficile le passage au mod_wsgi. J'aimerais donc avoir une idée des gains que je peux espérer avant de m'engager dans cette voie.

Edit : Carl a posté ici une réponse un peu plus détaillée qui vaut la peine d'être lue : Déploiement de Django : Réduire la surcharge d'Apache

Edit : L'article de Graham Dumpleton est le meilleur que j'ai trouvé sur les questions relatives à MPM et mod_wsgi. Je suis cependant déçu que personne n'ait pu fournir d'informations sur le débogage de l'utilisation de la mémoire dans l'application elle-même.

Montage final : J'ai discuté de ce problème avec Webfaction pour voir s'ils pouvaient m'aider à recompiler Apache et voici ce qu'ils m'ont dit à ce sujet :

"Je ne pense vraiment pas que vous obtiendrez beaucoup d'avantages en passant à une configuration MPM Worker + mod_wsgi. J'estime que vous pourriez économiser environ 20 Mo, mais probablement pas beaucoup plus que cela."

Cela me ramène à ma question initiale (à laquelle je ne comprends toujours pas grand-chose). Comment faire pour identifier où se situent les problèmes ? C'est une maxime bien connue que vous n'optimisez pas sans tester pour voir où vous devez optimiser mais il y a très peu de tutoriels pour mesurer l'utilisation de la mémoire en Python et aucun spécifique à Django.

Merci pour l'aide apportée par chacun, mais je pense que cette question reste ouverte !

Un autre montage final ;-)

J'ai posé la question sur la liste des utilisateurs de django- et j'ai reçu des réponses très réponses utiles

Honnêtement, la toute dernière mise à jour !

Cela vient d'être publié. C'est peut-être la meilleure solution à ce jour : Profiler la taille des objets de Django et leur utilisation de la mémoire avec Pympler

50voto

nosklo Points 75862

Assurez-vous que vous ne conservez pas de références globales aux données. Cela empêche le ramasseur de déchets de python de libérer la mémoire.

N'utilisez pas mod_python . Il charge un interpréteur dans apache. Si vous avez besoin d'utiliser apache, utilisez mod_wsgi à la place. Il n'est pas difficile de changer. C'est très facile. mod_wsgi est beaucoup plus facile à configurer pour django qu'en état de mort cérébrale mod_python .

Si vous pouvez supprimer apache de vos exigences, ce serait encore mieux pour votre mémoire. spawning semble être le nouveau moyen rapide et évolutif d'exécuter des applications web en python.

EDIT : Je ne vois pas comment le passage à mod_wsgi pourrait être " délicat ". Cela devrait être une tâche très facile. Veuillez préciser le problème que vous rencontrez avec le commutateur.

0 votes

Les développeurs de Django préconisent l'utilisation de mod_python, n'est-ce pas ? Qu'y a-t-il de mal à utiliser Apache ?

4 votes

@Josh : le gonflement et l'utilisation de la mémoire d'Apache sont stupides si vous n'utilisez pas les fonctionnalités propres à Apache. C'est juste une couche inutile.

3 votes

Django soutient toujours mod_python parce que mod_wsgi est encore assez récent et qu'ils veulent être conservateurs. Mais si vous suivez la communauté Django, vous verrez que les gens passent en masse à mod_wsgi. Il ne faudra pas longtemps pour qu'il devienne l'option recommandée.

28voto

Van Gale Points 21982

Si vous vous exécutez sous mod_wsgi, et vraisemblablement sous spawning puisqu'il est compatible avec WSGI, vous pouvez utiliser Dozer pour examiner l'utilisation de votre mémoire.

Sous mod_wsgi, ajoutez simplement ceci au bas de votre script WSGI :

from dozer import Dozer
application = Dozer(application)

Ensuite, dirigez votre navigateur vers http://domain/_dozer/index pour voir une liste de toutes vos allocations de mémoire.

Je vais également ajouter ma voix pour soutenir le mod_wsgi. Il fait une énorme différence en termes de performances et d'utilisation de la mémoire par rapport à mod_python. Le support de Graham Dumpleton pour mod_wsgi est exceptionnel, tant en termes de développement actif que d'aide aux personnes de la liste de diffusion pour optimiser leurs installations. David Cramer à malédiction.com a publié des graphiques (que je n'arrive malheureusement pas à trouver maintenant) montrant la réduction drastique de l'utilisation du processeur et de la mémoire après le passage au mod_wsgi sur ce site à fort trafic. Plusieurs des développeurs de Django ont changé. Sérieusement, c'est une évidence :)

0 votes

Dans ce cas, je vais bientôt poster une question demandant comment obtenir une authentification basée sur les cookies pour les utilisateurs de django accédant à des fichiers statiques...

15voto

Pankrat Points 2145

Ce sont les solutions de profileur de mémoire Python que je connais (sans rapport avec Django) :

Clause de non-responsabilité : j'ai un intérêt dans cette dernière.

La documentation de chaque projet devrait vous donner une idée de la manière d'utiliser ces outils pour analyser le comportement de la mémoire des applications Python.

Ce qui suit est une belle "histoire de guerre" qui donne également quelques conseils utiles :

5voto

zgoda Points 8549

En outre, vérifiez si vous n'utilisez pas de fuites connues. MySQLdb est connu pour laisser échapper d'énormes quantités de mémoire avec Django en raison d'un bogue dans la gestion de l'unicode. En dehors de cela, Barre d'outils de débogage Django pourrait vous aider à traquer les porcs.

0 votes

amix.dk/blog/viewEntry/19420 montre l'utilisation de dozer pour montrer que MySQLdb fuit de la mémoire. MySQLdb 1.2.3c1 et les versions ultérieures corrigent ce problème.

0 votes

Comment django-debug-toolbar de l'aide ?

4voto

Carl Meyer Points 30736

Outre le fait de ne pas conserver de références globales à de gros objets de données, essayez d'éviter autant que possible de charger de gros ensembles de données en mémoire.

Passez à mod_wsgi en mode démon, et utilisez le worker mpm d'Apache au lieu de prefork. Cette dernière étape peut vous permettre de servir beaucoup plus d'utilisateurs simultanés avec une charge mémoire bien moindre.

0 votes

Voir aussi la réponse de Carl ici : stackoverflow.com/questions/488864/

0 votes

De plus, dans les quelques messages que j'ai lus, il semble que le véritable gain réside dans le passage à worker MPM plutôt que dans l'utilisation de mod_wsgi...

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X