Je crée un couple de processus de travail en utilisant le module de multiprocessing de Python 2.6. Dans chaque travailleur, j'utilise le module de journalisation standard (avec rotation du journal et fichier par travailleur) pour garder un œil sur le travailleur. J'ai remarqué qu'au bout de quelques heures, plus aucun événement n'est écrit dans le journal. Le processus ne semble pas tomber en panne et répond toujours aux commandes via ma file d'attente. En utilisant lsof, je peux voir que le fichier journal n'est plus ouvert. Je soupçonne que l'objet de journal peut être détruit par le garbage collector, si oui est-ce que je peux le marquer pour le protéger?Comment puis-je protéger un objet de journalisation du garbage collector dans un processus de multitraitement?
Répondre
Je suis d'accord avec @ THC4k. Cela ne semble pas être un problème du GC. Je vais vous donner mes raisons, et je suis sûr que quelqu'un me rejettera si je me trompe (si c'est le cas, s'il vous plaît laissez un commentaire en soulignant mon erreur!). Si vous utilisez CPython, il utilise principalement le comptage de références, et les objets sont détruits immédiatement lorsque le compteur ref atteint zéro (depuis 2.0, la récupération de place supplémentaire est également fournie pour gérer le cas des références circulaires). Gardez une référence à votre objet de journal et il ne sera pas détruit.
Si vous utilisez Jython ou IronPython, la machine virtuelle sous-jacente effectue le nettoyage de la mémoire. Encore une fois, gardez une référence et le GC ne devrait pas y toucher. De toute façon, il semble que vous ne gardiez pas une référence à un objet que vous devez garder en vie, ou vous avez une autre erreur.
CPython a une marque et un ramasse-miettes. Il utilise le comptage de références comme une amélioration des performances, il n'a donc pas à marquer et balayer les structures de données non circulaires. D'une manière ou d'une autre, la solution est la même si vous ne voulez pas que quelque chose soit collecté, gardez une référence. – stonemetal
@stonemetal: Merci. J'ai édité ma réponse. –
Je n'ai pas encore dépisté le problème, mais pour autant que je sache, il semble que le rapport du gestionnaire de fichiers soit perdu via lsof (htop) était incorrect. Je pense qu'il y a un bug dans l'intégration de htop/lsof :) – Marinus
http://docs.python.org/reference/datamodel.html#object.__del__
Selon cette documentation la méthode del() est appelée sur la destruction des objets et vous pouvez à ce moment créer une référence à l'objet pour l'empêcher d'être collectées. Je ne suis pas sûr de savoir comment faire cela, j'espère que cela vous donne à réfléchir.
Vous pouvez exécuter gc.collect() immédiatement après fork() pour voir si cela entraîne la fermeture du journal. Mais il est peu probable que la collecte des déchets ne prenne effet qu'après quelques heures.
Je doute vraiment que le GC ait quelque chose à voir avec ça ... –