Discussion :

[shaiHulud]

Bonjour,

Mon système de logging conserve ses fichiers ouverts pour ne pas avoir à les réouvrir à chaque write(). J'obtiens de temps en temps l'IOError: [Errno 24] Too many open files, le plus souvent lorsque le profiler appelle dump_stats()
- Comment puis-je changer sous windows le nombre limite de fichiers ouverts par processus ?
- Le patch suivant vise à dénombrer les fichiers encore ouverts à un moment donné. Il m'indique 59 fichiers ouverts au moment ou je catche l'IOerreur. Est-ce vraiment la limite de mon Windows ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
import __builtin__
class DO_PATCH():  
    memory= {}  
    BUITINOPEN= open
    def __init__(self): 
        """ Activates patch of __builtin__.open """       
        def _open(file,*a):                
            o= DO_PATCH.BUITINOPEN(file,*a)
            DO_PATCH.memory[file]= o
            return o
        __builtin__.open= _open
    @staticmethod
    def show_use(opened=None):
        """ Show current state of all file that had been opened since patch """
        d= dict([(k,v.closed) for (k,v) in DO_PATCH.memory.items()])
        def _print(*a):
            print a
        print d
        if opened== None or opened==False:
            f= [k for (k,closed) in d.items() if closed]
            print "CLOSED ", len(f), f      
            [_print(k) for k in sorted(f)]     
        if opened== None or opened==True:
            f= [k for (k,closed) in d.items() if not closed]   
            print "OPENED", len(f), f         
            [_print(k) for k in sorted(f)]    
        return d

[wiztricks]

Salut,

Pourquoi poser des questions d'administration système Windows dans un forum de programmation Python?

- Le patch suivant m'indique 59 fichiers ouverts au moment ou je catche l'IOerreur. Est-ce vraiment la limite de mon Windows ?

De mémoire, c'est plus de 512.
Elle sert a dimensionner une table dans l'espace virtuel des process. La limite est assez grande pour répondre aux besoins de la plupart des applications.
C'est un peu comme le "max recursion limit de Python": il n'est raisonnable de l'augmenter qu'en sachant expliquer pourquoi pas pour masquer des bugs.
- W

[shaiHulud]

Merci Wiztricks,

De mémoire, c'est plus de 512...La limite est assez grande pour répondre aux besoins de la plupart des applications

Je ne vois pas comment j'aurais pu en ouvrir autant (512), et mon patch visait justement à les dénombrer. Voyez vous une raison pour que mon patch soit faux (et ne compte que 59 fichiers ouverts s'il y en a plus) ?

des questions d'administration système Windows

Je préférerais une solution Python pour lire ou éditer cette variable système.

[wiztricks]

Salut,

J’évite d'essayer de décoder un code que je ne comprends pas.
Si je lis, "l'intention"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mon système de logging conserve ses fichiers ouverts pour ne pas avoir à les réouvrir à chaque write().

Je me dis pourquoi pas...
Voyons voir le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
        def _open(file,*a):                
            o= DO_PATCH.BUITINOPEN(file,*a)
            DO_PATCH.memory[file]= o
            return o

Et puis la ça fait *tilt* : comment est code "ne pas avoir à les réouvrir à chaque write()" ?
Quel est le sujet?

J'obtiens de temps en temps l'IOError: [Errno 24] Too many open files, le plus souvent lorsque le profiler appelle dump_stats()

Franchement, je ne vois pas trop le rapport avec le code présente:
c'est pas "open" qui ferme les fichiers. Eventuellement, la référence qui reste dans memory...
Mais vous répondez:

Je ne vois pas comment j'aurais pu en ouvrir autant (512), et mon patch visait justement à les dénombrer

Donc on ne comprends pas trop ce qui se passe.

Voyez vous une raison pour que mon patch soit faux (et ne compte que 59 fichiers ouverts s'il y en a plus) ?.

Testez d'abord le programme "sans" patcher "open".
Fonctionnellement, votre "patch" améliore les performances. Si "ailleurs" votre code fait n'importe quoi: pourquoi se casser les yeux sur ce que vous voulez bien montrer?
Si votre code fonctionne "sans": ce sera probablement un pb. de "race condition" et éventuellement de GC. Descendre la dedans?
Peut être mais pas être confiant d'y trouver quelque chose.

Augmenter la variable "max handle limit" pour se convaincre que le problème n'est peut être pas ce que vous proposez de regarder?
Je ne mets pas 1 cent. la dedans.

- W

[shaiHulud]

Il y a confusion et j'en suis désolé. J'ai indiqué pourquoi je conservais des fichiers ouverts (le loggin) pour être exhaustif, mais le code que je présente n'a rien à voir avec le loggin. Je reprends:

Testez d'abord le programme "sans" patcher "open".

Mon code (à cause, entre autre, de son loggin - qui n'ont rien à voir avec le patch que je présente ici) lève l'IOError "Too many files"

Franchement, je ne vois pas trop le rapport avec le code présente:

Le code que j'ai présenté est un utilitaire de debuggage qui permet justement de savoir combien de fichiers sont ouverts à un moment donné. J'espérais m'en servir pour voir quels fichiers j'avais oublié de fermer, et combien sont ouverts au moment ou j'ai l'erreur.
Sa réponse (mais j'ai encore des doutes sur sa justesse) est 59 fichiers ouverts (qu sont tous censés l’être en l’occurrence, pas d'oubli de ma part)

race condition

-> Pas de threading dans mon code

et éventuellement de GC

-> Même si le GC ne collectait pas les fichiers fermés, çà n'augmenterait pas le nombre de fichiers ouverts (ils ont été close)

[wiztricks]

Sa réponse (mais j'ai encore des doutes sur sa justesse) est 59 fichiers ouverts (qu sont tous censés l’être en l’occurrence, pas d'oubli de ma part)

Et combien de fichier fermes (ou plutôt d’entrées dans le dict memory).
En fait, votre code ne compte pas les ouvertures multiples d'un même fichier: le 59 est sous évalué.
- W

[fred1599]

Il y a une méthode closed de l'objet file, qui permet de connaître l'information "le fichier est-il ouvert ?"

Qui puis-est pourquoi l'utilisation de dictionnaire? Une simple liste où on insère l'objet file, à la rigueur, pourquoi pas?

Je ne comprend pas pourquoi se compliquer la vie pour une question aussi simple telle que : combien de fichiers sont ouverts à un moment donné?

Il y a aussi des conventions vraiment pas respectées, maintenant chacun code comme il veut, soit... Mais rappeler l'attribut d'une classe par classe.attribut ça me gêne vraiment question conceptuelle de la chose. Une classe c'est comme un plan afin de créer un objet, on appelle pas l'attribut du plan mais bien l'attribut de l'objet.

Bref je trouve que ce qui est demandé est beaucoup plus simple que ce qui est présenté, je me trompe? On cherche compliqué ?

[shaiHulud]

Et combien de fichier fermes (ou plutôt d’entrées dans le dict memory).

Plusieurs centaine

En fait, votre code ne compte pas les ouvertures multiples d'un même fichier: le 59 est sous évalué.

Effectivement ! Après correction (en rajoutant une clef unique (fichier,compteur)), je suis à 509 fichier ouverts, et j'ai détecté lesquels j'ai gardé ouverts plusieurs fois.

Je sais donc ce que je dois corriger maintenant que mon patch est corrigé, merci beaucoup Wiztrick !

[shaiHulud]

@fred:

Je ne comprend pas pourquoi se compliquer la vie pour une question aussi simple telle que : combien de fichiers sont ouverts à un moment donné?

Quelle est la solution simple ? Pour ma part, la plus simple à laquelle j'ai pensé est le patch que je présente. Comment puis-je vérifier quels fichiers sont encore ouverts sans tracker tous ceux que j'ai open() ?

Il y a une méthode closed de l'objet file

C'est un attribut et je l'utilise.

pourquoi l'utilisation de dictionnaire? Une simple liste

J'avoue que j'aurais pu accéder au chemin de fichiers depuis les objets file pluot qu'en insérant le chemin en clef de dictionnaire, mais bon ca ne change pas grand chose (et ça me permet éventuellement de weakref les fichiers tout en conservant les chemins que j'ai ouvert)

Il y a aussi des conventions vraiment pas respectées

Mais rappeler l'attribut d'une classe par classe.attribut ça me gêne vraiment question conceptuelle de la chose

Je ne comprends pas vraiment lesquelles ni pourquoi. La seule imprécision de design qui me saute au yeux, c'est que __init__ aurait du être une staticméthode nommée "apply_patch". Mais vu le nom de la classe, un simple call de la class (implémenté via __init__) me semblait moins lourd.

Quelles conventions ne sont pas respectées dans ce code modifié (j'ai juste remplacé __init__ par une staticmethod, corrigé le problème d'ouvertures multiples, et renommé la classe ) ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
class TrackOpenedFiles():  
    """ """
    memory= {}  
    BUITINOPEN= open   
    @staticmethod 
    def ApplyPatch():  
        """ Activates patch of __builtin__.open """
        TrackOpenedFiles.count= 0 # make keys unique for multiple open on same file         
        def _open(file,*a):    
            o= TrackOpenedFiles.BUITINOPEN(file,*a)
            TrackOpenedFiles.memory[(file,TrackOpenedFiles.count)]= o
            TrackOpenedFiles.count= self.count+1
            return o
        __builtin__.open= _open
    @staticmethod
    def ShowUse(opened=None):
        """ Show current state of all file that had been opened since patch """
        d= dict([(k,v.closed) for (k,v) inTrackOpenedFiles.memory.items()])
        def _print(*a):
            print a
        print len(d), d
        f= [k for (k,closed) in d.items() if closed]
        print "CLOSED ", len(f), f      
        if opened== None or opened==False:            
            [_print(k) for k in sorted(f)]     
        f= [k for (k,closed) in d.items() if not closed]   
        print "OPENED", len(f), f   
        if opened== None or opened==True:                
            [_print(k) for k in sorted(f)]    
        return d

[fred1599]

Je ne comprends pas lesquelles ni pourquoi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
o= DO_PATCH.BUITINOPEN(file,*a)
DO_PATCH.memory[file]= o

Eh bien ces deux lignes par exemple... le pourquoi a semble-t-il été expliqué dans mon post précédent.

C'est un attribut et je l'utilise.

Certes mais à part closed, de quoi avoir besoin de plus? Pourquoi une classe?

As-tu pensé à l'utilisation de map pour l'ouverture et la fermeture?

[wiztricks]

Elles vous ont fait quoi les mouches?

Le code qu'on écrit pour chasser un bug n'apporte rien au "fonctionnel".
C'est juste du temps qu'on aurait pu passer a apprendre a utiliser les outils qui viennent avec l'OS.
Pour Windows, Microsoft produit un Process Explorer qui répond a la question en quelques clics. Quand le code du fonctionnel et le code de debug sont écrits par la même personne, nous avons une "estime de soi" qui nous empêche de "voir". C'est humain.

Si on veut "écrire ça proprement", pourquoi pas, mais c'est un autre sujet.
Dans ce cas, je dirais que le gros défaut du code est d’être "brouillon"...

Il est "brouillon" parce "les intentions" ne sont pas claires et ca se lit dans le code.
Si l'intention est d'ajouter des fonctionnalités a un objet Python "file" et il faut oser s/classer l'objet "__builtin__.file" pour traduire ca.
C'est pas complique de commencer par:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
import __builtin__
 
class _file(__builtin__.file):
    def __init__(self, path, *mode):
        print 'open'
        super(_file, self).__init__(path, *mode)
 
    def close(self):
        print 'close'
        super(_file, self).close()

C'est juste une "structure": des "os" a qui on pourra ajouter la viande et la sauce après.
L'avantage est de pouvoir "tester" dans foutre le bazar partout.

Puis on "patche" builtin (un autre objet de type module celui la):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
def patch_builtin():
    __builtin__.open = _file
    __builtin__.file = _file

La structure étant en place, on peut s'amuser a tracer le nombre de fois qu'un fichier est "ouvert".
Comme les fichiers sont identifies par leur nom, çà passe par une association entre os.path.abspath(path) - un identifiant unique - et un "count" incrémente dans __init__, décrémente dans close.
- W

[shaiHulud]

Pourquoi une classe? As-tu pensé à l'utilisation de map pour l'ouverture et la fermeture?

Ma classe sert juste à encapsuler mon patch global, pas à wrapper un fichier par instance.

Le code qu'on écrit pour chasser un bug n'apporte rien au "fonctionnel".
C'est juste du temps qu'on aurait pu passer a apprendre a utiliser les outils qui viennent avec l'OS.

Tout à fait d'accord, et merci pour le lien vers l'outil que je cherchais. Cela étant, à la place d'apprendre cet outil, j'ai appris à patcher une builtin en Python

je dirais que le gros défaut du code est d’être "brouillon"

L'implémentation est brouillon (une classe inutile car utilisée de manière statique), mais l'utilisation est quand même très lisible à mon goût.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
import patch_open
patch_open.DO_PATCH()
...
patch_open.DO_PATCH.ShowUse()

Je n'ai pas sous classé file, seulement patché open, car j'utilise uniquement open().

Eh bien ces deux lignes par exemple

Pourquoi UneClasse.attribut est une mauvaise approche pour implémenter un attribut statique ? J'aurais pu utiliser instance.attribut (qui a priori n'est pas dans instance.__dict__, donc ca ne changeait rien , sauf peut etre les performances), mais UneClasse.attribut permet de préciser dans le code source que attribut n'a aucune raison d’être dans l'instance et que je m'intéresse à un attribut statique uniquement. Pourquoi serait-ce une mauvaise pratique ?

Elles vous ont fait quoi les mouches?

Bzz Bzz... Désolé si j'ai pu paraître sec dans mes réponses, je cherchais juste à comprendre. Dans tous les cas, vos réactions prouvent que mon code n'était pas aussi lisible que je le pensais.

Un grand merci à tous les deux !

[fred1599]

donc ca ne changeait rien

Ça ne change rien au fonctionnement, mais en ce qui concerne la lisibilité et l'idée de concevoir, l'instance est beaucoup plus adapté.
______________________

Pour le reste je suis désolé, mais j'ai beaucoup de mal à voir l'intérêt de la chose, je ne comprend pas cette phrase...

conserve ses fichiers ouverts pour ne pas avoir à les réouvrir à chaque write()

Si on ne close pas le fichier, il reste ouvert non?

Peut-être qu'avec cette explication je comprendrais mieux l'objectif de cet exercice.

[shaiHulud]

en ce qui concerne la lisibilité et l'idée de concevoir, l'instance est beaucoup plus adapté.

je maintiens : UneClasse.attribut permet de préciser dans le code source que attribut n'a aucune raison d’être dans l'instance et que je m'intéresse à un attribut statique uniquement. Ça participe à la lisibilité non ?

Pour le reste

Mon code utilise intensément 30 fichier de logs. J'avais commencé à utiliser le module logging, mais cela ralentissait considérablement mon code. J'ai donc codé mon propre module de logging, et découvert qu'il était beaucoup plus rapide si je conservais les fichiers de log ouverts (car je vais réécrire dans le même fichier un peu plus tard). J’évite ainsi le coût d'ouverture et de fermeture à chaque log().

Cela a malheureusement conduit mon code à emmètre l'erreur "too many open files". Comme il me semble que je suis largement sous la limite autorisée par Windows, j'ai voulu tester mon module de logging en vérifiant quels fichiers étaient ouverts.

Et mon patch, une fois corrigé par Wiztrick, m'a permis de détecté l'erreur dans mon module de logging (à savoir, il ré-ouvre plusieurs fois le même fichier, ce qui n'était pas censé être le cas).

[fred1599]

Eh bien l'essentiel est que tout cela convienne, je vais supposer que vous avez raison étant donné que je n'ai pas vu le code avec le module logging, je fais confiance...

Bonne continuation.

[wiztricks]

Mon code utilise intensément 30 fichier de logs. J'avais commencé à utiliser le module logging, mais cela ralentissait considérablement mon code.

S'il trouve le module "threading" - même si vous n'utilisez pas de threads, le module est dans les librairies Python, par défaut - le FileHandler protège l’accès au structure partagées du module via des acquire/release d'un verrou (appel système).

C'est acceptable car la fonction du module est de remonter des erreurs - a priori pas trop souvent - écrire a toute vitesse dans n'est pas son "job" et ce verrou sérialise "très haut" les écritures dans plein de fichiers.
Écrire dans un seul fichier et trier ensuite via le format des labels dans les messages est plus simple. Il y a même des trucs prêts a l'emploi qui savent trier et dispatcher en temps réel (le fichier étant ouvert en mode 'append' facile de détecter et récupérer les ajouts).

J'ai donc codé mon propre module de logging, et découvert qu'il était beaucoup plus rapide si je conservais les fichiers de log ouverts

s/classer le FileHandler pour supprimer les acquire/release aurait peut être été suffisant. Sinon déléguer les écritures dans un process sépare aurait été envisageable. La documentation montre comment faire. Écrire du code prend du temps et apporte la fierté du "c'est moi qui l'ai fait". En plus "coder" peut devenir un exercice "ludique", une bataille contre la machine!
In fine, ca bouffe pas mal de temps.

Quand on en vient a ré-écrire des fonctionnalités de bases, c'est en général qu'on les utilise en dehors des clous, qu'on utilise pas les plus adaptées, ...
Dans tous les cas, il faut prendre un minimum le temps de repenser au problème a résoudre, envisager les autres solutions disponibles,...

Un minimum car, si on code avec des dead-lines, on est tellement dans son truc que "coder le truc simple attendu" sera plus rapide que se divertir a reformuler son besoin en comprenant comment fonctionne une bibliothèque X ou remettre a plat le design.

Enfin "parfois" car souvent c'est plus difficile que prévu et on s’accommode des dead lines avec des journées un peu longues et le sacrifice de week ends, ...
Pire c'est plus de code a maintenir qui ne sera réutilisable que pour pallier la fonctionnalité de base: i.e. le plus souvent c'est "jamais".

Mais ça veut dire aussi du boulot après le coup de feu pour essayer de s’améliorer i.e. voir comment on aurait pu faire mieux, plus simple si on avait eu plus de temps. Essayer de comprendre le fonctionnement de la biblio. qu'on n'a pas pu utiliser permettra de moins bricoler la prochaine fois (et d’améliorer sa productivité "boulot" pour y sacrifier moins de "loisirs").

Pas facile d'admettre que "programmer" est aussi l'art d’écrire le moins de lignes de code possible.

- W