Utilisation mémoire et optimisation

Salut,

je développe une application en C# sous VS 2005.
Elle permet de récupérer des fichiers de données et de les afficher sous forme de courbes avec Tchart

Je viens de me rendre qu'elle utilise beaucoup de mémoire,
elle s'acrôit assez rapidement (1Mo/minute)
est-ce que c'est normal?

je l'ai vue passée de 30Mo au démarage à plus de 100...
je me demande si la libération se fait correctement...
j'ai remarqué que réduire la fenêtre libérait beaucoup de mémoire (l'appli n'en occupe plus que qq Mo)

auriez vous des conseils pour optimiser tout ça?...

merci

ah oui aussi,
j'ai une ptite appli annexe qui tourne sur le même poste
et qui fait aussi de l'affichage de courbe avec Tchart
et celle-là, c'est plus embêtant prend au bout d'un certain temps (1h ou 2h) tout le CPU...

apparament, c'est l'affichage qui merde...
j'ai un fichier qui arrive toutes les 10s
au lancement, ça marche bien et puis après, ça a de plus en plus de mal à mettre à jour, jusqu'à plus pouvoir du tout...

Il existe différents outils que vous pouvez utiliser pour améliorer votre développement:

• Microsoft Debugging Tools ==> Outils Microsoft Gratuit... MAIS HORRIBLEMENT COMPLEXE.

• CLR Profiler ==> Outil Microsoft Gratuit mais complexe.

• JetBrains dot Profiler ==> Outil payant mais version d'évaluation 10 jours complet gratuites.

Si vous le souhaitez, je peux vous donner un petit coup de main... Je m'occupe de ce genre de soucis dans une multi nationale.

Cordialement

bon,

alors, le souci de charge CPU est réglé...


une petite question :
dans l'ihm de mon appli qui utilise toujours plus de mémoire,
j'ai des ListView,
j'ai paramétré le nombre d'item visibles à 1000,
quand ce nombre est atteint, je fais un ListView.Items.RemoveAt() pour supprimer l'item le plus ancien

et je me demande si la mémoire correspondant à cet item est bien libérée...

qqun aurait-il des infos là dessus?...


parce que j'ai l'impression que le garbage collector ne fait son boulot que quand je réduis la fenêtre...

Le garbage collector fait son boulot qd il veut tant qu'il y a de l'espace mémoire libre. Aprés tout qd l'appli est réduite c'est le bon moment pour faire un garbage collector sans gêner l'utilisateur.

La question est plutot de savoir si ta consommation reste élevée même qd ton systeme commence à être à court de mémoire.

Sans vouloir affirmer, le fait que l'utilisation mémoire diminue lorsque l'application est réduite n'a rien à voir avec le garbage collector. C'est le système d'exploitation qui met une partie des pages mémoires dans le swap quand il détecte qu'elle n'est plus active, pour libérer de la mémoire pour les autres applications en avant plan. Mais ceci est paramétrable au même endroit que la mémoire virtuelle dans les propriétés système.

Concernant le problème de mémoire, un profiling de l'application, avec les outils précédemment cités, te donnera de bonnes pistes pour rechercher.

Citation:

---

Envoyé par SaumonAgile

Sans vouloir affirmer, le fait que l'utilisation mémoire diminue lorsque l'application est réduite n'a rien à voir avec le garbage collector. C'est le système d'exploitation qui met une partie des pages mémoires dans le swap quand il détecte qu'elle n'est plus active, pour libérer de la mémoire pour les autres applications en avant plan. Mais ceci est paramétrable au même endroit que la mémoire virtuelle dans les propriétés système.

Concernant le problème de mémoire, un profiling de l'application, avec les outils précédemment cités, te donnera de bonnes pistes pour rechercher.

---

Effectivement, si la mémoire utilisée par ton appli remonte qd elle n'est plus réduite, c'est le systeme qui swap. D'ailleurs pour connaitre la consommation mémoire d'un process en détail (mémoire vive réellement utilisée, mémoire actuellement sur le disque etc...), outre les compteurs de performances windows je te conseille d'utiliser procexp de sysinternals, bien mieux fichu que le gestionnaire de tâches windows.
Sinon comme mes collègues l'ont dit plus haut certains outils de debuggage te permettent de voir pourquoi ta mémoire n'est pas libérée (en retrouvant quels sont les objets qui gardent des références actives).

Ants m'a également permis de détecter certaines erreurs (14 jours d'évaluation).

en fait, si je réduis la fenêtre, la mémoire diminue beaucoup
et quand je rouvre la fenêtre, elle raugmente mais c'est tjs moins qu'avant...

Bonjour,


BCmDev,
j'ai téléchargé Ants,
pourrais-tu m'en dire un peu plus sur comment je pourrais détécter d'éventuels soucis?...

merci

Une ptite remarque:

le nb de handles et de threads est stable,
c'est plutôt bon signe, nan?

Bonjour,

je reviens demander conseil...
toujours pour ce problème d'utilisation mémoire...

je fais des essais longue durée avec mon appli
elle tourne très bien pendant plusieurs jours,
même si la mémoire ne cesse d'augmenter.
Je précise que le pc n'est utilisé que pour ça.

le soucis c'est qu'à un moment,
y'a des opérations qui mettent un temps fou (pls secondes), alors que d'habitude ça prend qq 10e de secondes...

donc voilà, c'est pas terrible...

auriez-vous des conseils pour résoudre ce pb d'utilisation mémoire?...
merci

Je te renvoie à ma réponse précédente, en précisant: Tu peux faire un minidump de ton appli qd elle utilise beaucoup de ressources avec un outil qui s'appelle adplus.
Ensuite tu peux charger ce dump dans le debugger windbg et utiliser une dll d'extension du debugger, SOS.dll. Tu as ensuite des commandes pour lister les objets encore en vie et des moyens de savoir pourquoi ils sont encore en vie (si le problème vient du code managé, mais il se peut aussi que ça vienne de composants COM si tu en utilises ou de PInvoke...).

Ce sont des outils un peu compliqués et pas trés user friendly, mais aussi trés puissants. Des infos plus précises ici ou encore là. Un autre article d'introduction sur WinDbg ici.

Bonne chance.

PS: ces outils se téléchargent là.

merci, je vais regarder ces outils...

je ne sais pas si adplus, va m'être utile : apparement, ça s'utilise dans le cas où il y a des plantages...
ce n'est pas le cas pour moi...

sinon, il y a des invoke sur des contrôles dans mon ihm,
est-ce que ça peut être une source d'utilisation mémoire?
quelles solutions?...

merci

Citation:

---

Envoyé par melleb

merci, je vais regarder ces outils...

je ne sais pas si adplus, va m'être utile : apparement, ça s'utilise dans le cas où il y a des plantages...
ce n'est pas le cas pour moi...

sinon, il y a des invoke sur des contrôles dans mon ihm,
est-ce que ça peut être une source d'utilisation mémoire?
quelles solutions?...

merci

---

ADPlus est trés pratique pour débuguer des plantages mais il ne sert pas qu'à celà, il peut trés bien aussi effectuer un snap shot de l'appli à n'importe quel moment (qui peut le plus...).

Les invoke sur des contrôles ne sont pas à priori la cause de tes problèmes. Je parlais de PInvoke, les appels à des fonctions de dll non managées, comme des fonctions win32.

je viens de regarder avec ProcExp,

je joins une capture d'écran de ce que j'obtiens,

ça commence vraiment à m'inquiéter ce pb,
mon appli a de plus en plus de ratée...

:help:

Il n'y a que toi qui sais ce que fait exactement ton appli, que toi pour pouvoir juger si cette consommation mémoire est excessive ou normale (c'est d'ailleurs la première question à se poser avant de paniquer).

Tu as des tas d'outils pour t'aider ensuite, en particulier les compteurs de performances qui te permettent de suivre l'évolution de beaucoup d'indicateurs, puis les outils de debuggage pour vraiment mettre les mains dans le cambui.

Bref il n'y a que toi qui puisses t'aider, sauf si t'es prêt(e) à nous envoyer un dump avec tous les pdb qui vont avec, voir même tes binaires puis tes sources ;).

ok ok...

je ne pense pas que ça soit très normal que mes appli, qui, au lancement utilisent 20-30 Mo et qui qq jours plus tard en sont à 200-300 Mo...

pourrais-tu m'en dire un peu plus : en quoi consiste un dump?
comment dois-je m'y prendre?
...

Citation:

---

Envoyé par melleb

je ne pense pas que ça soit très normal que mes appli, qui, au lancement utilisent 20-30 Mo et qui qq jours plus tard en sont à 200-300 Mo...

---

Et moi je trouve pas ça anormal qu'une appli qui démarre et qui n'a encore rien fait consomme moins qu'une appli qui est lancée et travaille depuis plusieurs jours. Bref ce genre de généralité n'est de tte façon pas trés pertinent, tout dépend de ce que FAIT ton appli pendant ces qques jours (à moins que tu sous entendes que pendant ces qques jours ton appli ne fait rien ?).

Citation:

---

pourrais-tu m'en dire un peu plus : en quoi consiste un dump?

---

Un dump c'est l'état de ton appli à un moment donné (état de la mémoire utilisée par l'appli, des piles d'appels des différents threads, des registres des CPu et que sais-je encore...). Adplus te permet de générer un dump.

Citation:

---

comment dois-je m'y prendre?

---

Tu as lu les liens que je t'ai donné précedemment ?

oui, j'ai télécharger les outils,
j'ai essayé de lancer WinDbg, j'ai lancé mon exe avec
mais je vois pas trop comment procéder ensuite...

je vais explorer un peu plus ces liens...

Tu peux ensuite laisser tourner ton appli un moment histoire que sa consommation mémoire augmente. Puis il faut trouver les commandes SOS qui permettent de voir quels sont les objets encore en vie et pourquoi (d'ailleurs faut que tu charges SOS dans windbg, mais ça doit être expliqué dans un des liens).

Je ne pourrais pas être beaucoup plus précis, j'ai peu utilisé ces outils moi même et je ne connais donc pas les commandes par coeur, je ne peux pas non plus te donner une marche à suivre trés précise. Désolé.

Alors ou en es-tu de ce problème ?

bah,
en fait, j'ai un peu de mal à me dépatouiller avec ces outils...

je suis toujours en train de faire des essais avec mon appli
ça fait plusieurs jours qu'elle tourne (je rappelle qu'elle récupère des fichiers de données et affiche des spectres toutes les 10s)
j'ai laissé la fenêtre de l'appli réduite
et là, elle utilise bcp moins de mémoire (environ 15 Mo)

donc je suis en train de me demander
si je ne devrais pas réduire la fenêtre quand au bout d'un certain temps il n'y a eu aucune activité...

mouais, c'est pas vraiment une solution ça.

Ecoute si tu peux laisser un dump de ton appli qd elle bouffe trop de mémoire qque part je veux bien y jeter un oeil, sans garantie aucune par ce que sans les pdb qui vont avec c'est plus dur (un dump de ton appli compilée en debug de préférence).

ok,
je vais essayer de faire ça cet après-m'

je ne sais pas trop comment fonctionne TChart mais est ce que quelqu'un ne s'est pas demandé si la consommation mémoire et les "fuites" ne venaient pas de là.

Autre chose qu'il faudrait savoir c'est si ton appli traite les fichiers meme si la fenetre est réduite... le fait qu'elle ne fait pas l'affichage signifie pas qu'elle ne traite pas le fichier comme si yavait quelque chose à dessiner.

Maintenant si tu te contente toute les 10s de faire un invalidate sur ta zone de dessins et la zone de dessins fait les calculs... c'est normal qui ne se passe rien quand ta fenetre est réduite car les messages WM_PAINT sont ignoré par ta queue de message.

Rien que le fait de savoir cela permettra de savoir où ce situe le problème de cette consommation.
A titre indicatif, réduire une fenetre, NE LIBERE PAS, les handles des composants de la fenetre... ils sont toujours là et occupe toujours de la mémoire et des ressourceS. la seule chose c'est que le thread qui pompe les messages va ignorer tous les messages relatifs aux composants dans une fenetre réduite, logique puisque ces composants ne peuvent obtenir de zone cliente de traçage.

Citation:

---

Envoyé par cinemania

je ne sais pas trop comment fonctionne TChart mais est ce que quelqu'un ne s'est pas demandé si la consommation mémoire et les "fuites" ne venaient pas de là.

---

eh bien, c'est justement là question...


sinon, je ne vois pas comment faire un dump...
help please...