Je profilene mon serveur tordu. Il utilise beaucoup plus de mémoire que prévu. Son utilisation de la mémoire pousse au fil du temps.
2010-01-15 00:46:05,139 INFO 4 4 17904 36732 9183 25944 2010-01-15 00:47:03,967 INFO 4 4 17916 36732 9183 25944 2010-01-15 00:48:04,373 INFO 4 4 17916 36732 9183 25944 2010-01-15 00:49:04,379 INFO 4 4 17916 36732 9183 25944 2010-01-15 00:50:02,989 INFO 4 4 3700 5256 1314 2260
3 Réponses :
éventuellement en raison de la réservation d'échange / mémoire, sur la base de la définition de PS:
# ps -eo pid,vsz,rss,sz,size,cmd|egrep python PID VSZ RSS SZ SZ CMD 23801 4920 2896 1230 1100 python
HAUTPY (partie de Guppy, que vous utilisez): http://guppy-pe.sourceforge.net/ p> li>
Validateur de mémoire Python http://www.softwareverify.com/python/memory/index.html p> li>
Pysiseur http://pysizer.8325.org/ P> LI> ul>
Bon guide sur le suivi des fuites de mémoire en python à l'aide de PDB et de l'objgraph: p>
http://www.lshift.net/blog/2008/11/14/tracing-python-Memory-leaks p> p>
Mais même je compare 69 Mo avec 10 Mo, c'est trop loin. Quel pourrait être le problème? Et de plus en plus, l'utilisation de la mémoire se développe avec le temps. Au début, le RSS est d'environ 2xMB et il vient à 6 fois maintenant.
Certains des objets rapportés par Guppy pourraient être échangés de sorte que Python pourrait signaler ceux, tandis que RSS n'inclut pas cela. Je ne sais pas pourquoi le processus se réserve tant de mémoire, peut-être des tonnes de libs partagés.
Toutes les bibliothèques sont chargées au démarrage. Il n'utilise que 2 fois MBS dans le champ RSS lorsque le serveur a commencé. Il n'a pas de sens que les bibliothèques occupent une utilisation supplémentaire de la mémoire. Y a-t-il un moyen de savoir quelle est la mesure de la mémoire invisible?
Hmm, sonne comme une mémoire qui fuit quelque part, pouvez-vous essayer Python Memory Validator pour identifier le code attribuant le plus de mémoire?
Comme indiqué au-dessus de la taille du RSS, c'est ce que vous êtes le plus intéressé ici. La taille "virtuelle" comprend des bibliothèques mappées, que vous ne voulez probablement pas compter.
Cela fait longtemps que j'ai utilisé le tas, mais je suis à peu près sûr que les statistiques que les empreintes informatiques n'incluent pas les frais généraux ajoutés par un tas lui-même. Cette surcharge peut être assez significative (j'ai vu un processus RSS de 100 Mo, cultivez une autre douzaine de MB, voir http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst ).
mais dans votre cas, je soupçonne que le problème est que vous utilisez une bibliothèque C qui fuit ou utilise la mémoire de manière à ne pas suivre. Le tas est conscient de la mémoire utilisée directement par des objets Python, mais si ces objets enveloppent des objets C alloués séparément, le tas n'est pas normalement conscient de cette mémoire. Vous pourrez peut-être ajouter un support en tas à vos liaisons (mais si vous ne contrôlez pas les liaisons que vous utilisez, c'est évidemment un problème, et même si vous contrôlez les liaisons, vous ne pourrez peut-être pas le faire en fonction de ce que vous enveloppez. ).
S'il y a des fuites au niveau du niveau C, le mélange perdra également une trace de cette mémoire (la taille du RSS augmentera mais la taille rapportée par le tas restera la même). Valgrind est probablement votre meilleur pari pour les suivre, comme dans d'autres applications C.
Enfin, la fragmentation de la mémoire provoquera souvent une utilisation de votre mémoire (comme on le voit en haut) pour monter mais pas en bas (beaucoup). Ce n'est généralement pas si un problème avec des démons, car le processus réutilisera cette mémoire, il n'est tout simplement pas renoncé au système d'exploitation, de sorte que les valeurs en haut ne reviennent pas. Si l'utilisation de la mémoire (vue par le haut) augmente plus ou moins linéairement avec le nombre d'utilisateurs (connexions), ne revient pas, mais ne continue pas de croître pour toujours tant que vous n'avez pas atteint un nouveau nombre maximum d'utilisateurs, la fragmentation est probablement blâmer.
Ce n'est pas une réponse complète, mais de votre trou d'homme, je suggérerais également d'exécuter manuellement gc.collect () avant de regarder avec ps ou sommet. Guppy montrera le tas alloué, mais ne fait rien à des objets libres de manière proactive qui ne sont plus alloués.