Discussion :

[AlexDpars]

Bonjour à tous, je développe depuis 2 ans une aplication de POS (Point of sale) assé complexe avec des controls de Telerik. Ça c'est pour la couche de présentation le back end ce sont des service WCF qui se connectent à ma base de données pour remplire des objet custom. Je n'avais jamais vraiment fait attention a ça jusqu'a aujourd'hui mais mon application lorsqu'elle a roulé plusieurs heures d'afilées monte jusqu'a 400 mb de mémoire. Le seul problème c'est que la business ici roule en terminal server alors vous imaginez ce que ça peut couté comme ressource sur un server 400 mb ... Alors je voulais savoir si quelques uns d'entre vous auraient des idées a me proposer pour que ce sois moin couteux en ressource? (J'utilise déja la fonction dispose pour tout les objets qui implémente l'interface IDisposable)

Merci à tous

[tomlev]

Si l'utilisation de RAM augmente au fil du temps, tu as probablement des fuites mémoire...

La cause la plus fréquente de fuites mémoire en .NET, c'est quand tu crées des objets "temporaires" qui s'abonnent à un évènement d'un objet dont la durée de vie est plus longue, et que tu "abandonnes" ces objets sans les avoir désabonnés de l'évènement. L'objet qui expose l'évènement conserve une référence vers les objets abonnés, via les delegates, ce qui empêche le garbage collector de les récupérer. Ces objets qui étaient supposés être temporaires restent donc indéfiniment en mémoire, jusqu'à ce que l'application soit arrêtée (ou que l'objet qui expose l'évènement soit lui-même collecté)

Vérifie par exemple si tu ne crées pas des fenêtres de dialogue qui s'abonnent à un évènement d'un objet qui a une plus longue durée de vie que la fenêtre. Si c'est le cas, désabonne toi de l'évènement quand la fenêtre est fermée (ou alors réutilise toujours la même fenêtre au lieu d'en créer une nouvelle à chaque fois).

[AlexDpars]

Est ce que c'est seulement dans le cas ou on utilise un delegate pour handler un event? Ou c'est dans le cas de tous les events ?

[tomlev]

Est ce que c'est seulement dans le cas ou on utilise un delegate pour handler un event? Ou c'est dans le cas de tous les events ?

Tu utilises TOUJOURS un delegate pour gérer un event... même si c'est le designer qui le fait pour toi
Mais a priori ce n'est pas à cause des évènements du designer, vu que ceux-ci gèrent les évènements des controles d'une Form, qui ont la même durée de vie que la Form.

[AlexDpars]

Oui mais dans mon cas c'est un user control hoster dans une form qui gere les event (et il n'est jamais fermé jusqu'a la fin et cette application peut-etre utilisée pendant des jours d'afilés ...) et c'est vrai que parfois je fais des open dialog pour ouvrir d'autres form et j'ai remarquer que c'Est justement ça qui prend de la mémoire. J'apprécierais que tu me montres un petit bout de code pour désabonner l'objet de mon event. Si c'est possible ?

[tomlev]

Oui mais dans mon cas c'est un user control hoster dans une form qui gere les event (et il n'est jamais fermé jusqu'a la fin et cette application peut-etre utilisée pendant des jours d'afilés ...) et c'est vrai que parfois je fais des open dialog pour ouvrir d'autres form et j'ai remarquer que c'Est justement ça qui prend de la mémoire. J'apprécierais que tu me montres un petit bout de code pour désabonner l'objet de mon event. Si c'est possible ?

A priori ce n'est pas à cause de ce usercontrol. Le problème, c'est les objets temporaires qui s'abonnent à des évènements et ne s'en désabonnent pas.

Pour se désabonner d'un abonnement, on utilise l'opérateur "-=" (de la même façon qu'on fait "+=" pour s'abonner)

Par exemple :

Code C# :

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
// abonnement :
monObjet.MonEvenement += monObjet_MonEvenement;
 
...
 
// désabonnement :
monObjet.MonEvenement -= monObjet_MonEvenement;
 
 
...
 
// handler
private void monObjet_MonEvenement(object sender, EventArgs e)
{
    ...
}

[AlexDpars]

Hum je pensais que quand tu me parlais d'objets temporaires tu me parlais des ojet declarés dans l'event ... la je ne te suis plus :S En desabonnant l'objet de l'event il va liberé les objets temporaires?

[tomlev]

Reprenons du début

Un évènement, qu'est-ce que c'est ? C'est une liste de méthodes à appeler quand quelque chose se produit. Ces méthodes sont représentées par des delegates.

Un delegate, c'est quoi ? En simplifiant un peu les choses, c'est :
- Une référence vers un objet cible X
- La méthode M à appeler sur cet objet

Supposons que tu t'abonnes à un évènement E d'un objet Z avec la méthode X.M :

Code :

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

Z.E += X.M;

Cela fait que l'objet Z va conserver une référence vers l'objet X (via le delegate). X ne pourra donc pas être collecté par le garbage collector, car il est toujours accessible via Z. X va donc rester en mémoire aussi longtemps que Z...

Prenons un exemple plus concret. Disons que Z est la fenêtre principale de ton application : il a donc une longue durée de vie, puisqu'a priori la fenêtre principale continue d'exister pendant toute l'exécution de l'application. Supposons qu'à chaque fois que tu cliques sur un bouton, tu crées une nouvelle fenêtre de dialogue X, qui s'abonne à un évènement de Z : si X n'est pas désabonnée de l'évènement, elle reste indéfiniment en mémoire. Et à chaque clic sur le bouton, tu crées une nouvelle fenêtre qui va elle aussi rester en mémoire... donc tu utilises de plus en plus de mémoire, alors que les objets qui occupent cette mémoire ne sont plus utilisés. Donc, il faut soit se désabonner de l'évènement pour permettre au GC de récupérer la mémoire occupée par ces objets, soit réutiliser le même objet X à chaque fois, de façon à ne pas créer inutilement plusieurs instances qui occuperont de la mémoire

J'espère que c'est plus clair

[olibara]

et c'est vrai que parfois je fais des open dialog pour ouvrir d'autres form et j'ai remarquer que c'Est justement ça qui prend de la mémoire.

Tu veux dire

Code :

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

ShowDialog()

Et que remarque tu exactement ?
Peux tu dire vraiment que ce sont ces ShowDialog() qui finissent par augmenter la memoire utilisée ?

En tout cas je te conseille vivement de placer ces appels dans un using

Code :

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

1
2
3
4
using (FrmDialog fdlg=new FrmDialog())
{
  fdlg.ShowDialog();
}

[tomlev]

En tout cas je te conseille vivement de placer ces appels dans un using

Ca libèrera les ressources système associées (par exemple les handles de la fenêtre et des contrôles), mais l'objet restera quand même en mémoire s'il est toujours abonné à des évènements... D'ailleurs ça peut être une bonne idée d'overrider Dispose pour se désabonner des évènements

[Laur3nT]

Sans connaître le contexte, j'aurais tendance à penser que des Singleton peuvent également être pertinent.

Imaginons que tu as une fenêtre X qui est appellé n fois dans la vie de ton programme.

Tu retrouves n fois :

Code :

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

1
2
3
 
var form = new form X();
form.ShowDialog();

C'est à dire que tu crées à chaque fois une nouvelle instance de la classe X.

Si maintenant tu viens mettre un singleton :

Code :

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

1
2
3
4
5
6
7
8
9
 
private static X _x;
public static X X {
get {
if (_x==null) {
_x = new X();
}
return _x;
}

Lorsque tu dois ouvrir un fenêtre tu écris :

Code :

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

1
2
 
X.ShowDialog();

Tu n'auras qu'une seule instance, utilisée plusieurs fois.

=> Elle ne passera pas dans le GC, elle sera donc dans la mémoire
=> Tu garanti qu'il n'y a qu'une seule instance dans la mémoire.

Dans l'absolu, tu peux également mettre le Singleton à l'intérieur de la classe X et attaque ShowDialog comme une méthode statique. Pour la forme, à toi de voir ^^

[AlexDpars]

Oui je suis d'accord avec toi mais ça ne me semble pas logique que la mémoire ne se vide pas meme si je fais un .Dispose() Je vous joint un exemple concret de code que je fais.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
Private Sub TxtComQty_KeyDown(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyEventArgs) Handles TxtComQty.KeyDown
        Try
            If e.KeyCode = Keys.F5 Then
                Dim ShowInventory As New ShowInventory(aListOfPartOnLine(0).Inventory)
                ShowInventory.ShowDialog()
            End If
        Catch ex As Exception
            DparsMsgBox(ex.Message, MsgBoxStyle.Critical, "Error")
        End Try
    End Sub

Je Dispose la form dans le code lorsque je dois la quitter. Est ce que c'est mieu de le faire dans le code parent?

Un autre point:

J'ai tester quelques petites choses concernant la mémoire je me suis fais un petit sample ou je fais simplement afficher et fermer des formulaires alors je fais monter le memoire rapidement. Et je me souviens qu'on m'aie dit que les objet ne sont pas libéré tout le long de la duré de vie du controle. J'ai donc essayer quelque chose qui ressemble à ça dans une fonction pour initialisé mon formulaire.

Code :

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

1
2
3
4
5
6
7
 
 
For i as integer = 0 to me.controls.count -1
     me.Controls(0).Dispose
Next
 
InitializeComponent()

Mais absolument rien ... Le niveau de la mémoire n'a pas baissé (il était à 150 mb juste pour mon petit sample). Je sais plus quoi pensé.

Suite a cela j'ai regardé un peu comment je bind mes grids et mes controles avec mon service WCF. J'ai une librairie qui me sert de controleur pour appeler mes services WCF ou j'ai une classe par service dans lesquels il y a un singleton de mon proxy et dans mon application windows j'ai une classe dans lequel il y a des singletons de ces classe la. En theorie je ne pense pas que ce sois ça qui affecte ma mémoire autant car si je test en faisant seulement des calls à mes classes la mémoire monte mais redescent aussitôt je n'ai aucun leak. Le problème c'est quand j'ouvre des forms vriament. J'en parle seulement parce que cela pourrait allumer une lumière à quelqu'un .

J'attends vos avis et je vous en remerci à l'avance

[AlexDpars]

Merci j'avais pas vue ton post ça semble tout à fait logique j'aimerais peut-être que tu me montre ce que j'aurais du faire dans l'exemple plus haut pour le désaboner

Reprenons du début

Un évènement, qu'est-ce que c'est ? C'est une liste de méthodes à appeler quand quelque chose se produit. Ces méthodes sont représentées par des delegates.

Un delegate, c'est quoi ? En simplifiant un peu les choses, c'est :
- Une référence vers un objet cible X
- La méthode M à appeler sur cet objet

Supposons que tu t'abonnes à un évènement E d'un objet Z avec la méthode X.M :

Code :

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

Z.E += X.M;

Cela fait que l'objet Z va conserver une référence vers l'objet X (via le delegate). X ne pourra donc pas être collecté par le garbage collector, car il est toujours accessible via Z. X va donc rester en mémoire aussi longtemps que Z...

Prenons un exemple plus concret. Disons que Z est la fenêtre principale de ton application : il a donc une longue durée de vie, puisqu'a priori la fenêtre principale continue d'exister pendant toute l'exécution de l'application. Supposons qu'à chaque fois que tu cliques sur un bouton, tu crées une nouvelle fenêtre de dialogue X, qui s'abonne à un évènement de Z : si X n'est pas désabonnée de l'évènement, elle reste indéfiniment en mémoire. Et à chaque clic sur le bouton, tu crées une nouvelle fenêtre qui va elle aussi rester en mémoire... donc tu utilises de plus en plus de mémoire, alors que les objets qui occupent cette mémoire ne sont plus utilisés. Donc, il faut soit se désabonner de l'évènement pour permettre au GC de récupérer la mémoire occupée par ces objets, soit réutiliser le même objet X à chaque fois, de façon à ne pas créer inutilement plusieurs instances qui occuperont de la mémoire

J'espère que c'est plus clair

[cinemania]

Les proxy WCF ou Références WCF si tu veux, ne consomment pour ainsi dire aucune mémoire, ce n'est que des classes avec du code, ce n'est pas ce qui fait exploser ta mémoire.

Le databinding lorsqu'il est utilisé de façon non convenable mène souvent à ce genre d'étrangetés.

Avant d'aller plus loin dans l'enquête il faut toutefois avoir plus d'informations sur ton projet et les technologies employées...

tes services WCF chargent des données dans la base et les "map" dans des objets que tu va ensuite faire transiter via ces services...
Est ce que tu utilise un ORM pour ces objets genre NHibernate ou Entity Framework ? ou tu les a développé toi même comme un grand, à la mano en faisant toi même les règles de chargement et de mapping O/R ?

ensuite il faut fenêtrer tes résultats... ainsi si tu doit transférer de grandes quantités d'objets, tu ne va pas tous les récupérer pour nourrir la DataGrid d'un coup, tu va les récupérer par fragment au fur et a mesure que tu en a besoin, et également penser à "nettoyer" (dé-référencer) ceux que tu n'utilisent plus.

Le problème des Winforms, surtout sur les datagrid et autres "méta-contrôles" qui instancies plein d'autres contrôles... c'est qu'ils ont tendance à instancier TOUS les sous contrôles, même lorsque c'est inutile... Ainsi, si ta liste peut afficher 20 items et que tu en bind 3000, il va instancier les 3000 contrôles représentant chacun 1 item et n'afficher forcément que les 20 premiers, et si la personne ne touche pas à cette grid... tu a une consommation mémoire inutile.
Ce problème est moins fréquent en WPF ou en Silverlight où nombre de ces contrôles pour peu que tu autorise la virtualisation, n'allouent les sous contrôles que lorsqu'ils en ont réellement besoin, sacrifiant la vitesse à la mémoire.

Cette application de BI est-elle située sur la même machine que les services WCF (j'espère bien que non et que les services WCF tournent soit sur le serveur de données, soit sur un autre pour être encore mieux)
Ensuite je trouve assez étrange qu'on laisse une telle appli en mémoire, sur des serveurs d'applicatifs (TSE) Faudrait apprendre aux utilisateurs à fermer proprement leur session lorsqu'ils quittent leur bureau à distance, et aussi de quitter leur bureau à distance, les soirs...
C'est pas bien pour l'environnement de laisser tourner les Work-Station la nuit dans une entreprise, et en plus ca alourdi sa facture d'électricité...
Mais bon passons sur ce détail.

[olibara]

Pourquoi ne juges tu pas utile de suivre mon conseil du using ?
De toute façpn le dsispose doit se faire dans l'objet qui a instancié ta form dialog

Code :

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

1
2
3
4
5
If e.KeyCode = Keys.F5 Then
     Dim ShowInventory As New ShowInventory(aListOfPartOnLine(0).Inventory)
    ShowInventory.ShowDialog()
    ShowInventory.Dispose();        
End If

[ddaime]

Bonjour, j'ai juste une petite question. Qu'est ce que tu utilises comme techno d'accés aux données (DataSet, EF, autres) ? Le probleme peux venir de la, un dataset par exemple, mal utilisé peux consommer beaucoup de mémoire.

[AlexDpars]

Bon bon bon, tout d'abord merci à toutes vos réponses. Je vais vous répondre un à un.

tes services WCF chargent des données dans la base et les "map" dans des objets que tu va ensuite faire transiter via ces services...
Est ce que tu utilise un ORM pour ces objets genre NHibernate ou Entity Framework ? ou tu les a développé toi même comme un grand, à la mano en faisant toi même les règles de chargement et de mapping O/R ?

Voilà comment mon architechture est monté. Tout d'abord j'ai mes models qui sont dans une lirairie de classes et oui j'ai fait tout mes models (entities) moi même comme un grand (Quand j'ai commencé l'entity framework n'existait pas du moin il n'était pas ce qu'il est aujourd'hui...) . Pour les binder j'utilise une database SQL server que j'ouvre avec un Datareader et je bind mes entities avec ça et j'utilise des collection générique pour les stocker (List OF(type). Tout la partie binding est fait dans une autre lirairie de classe c'est ce qui me sert de DAL (Data Access Layer) et cette classe est appelée par mon service WCF. Pour faire un court historique au début on fonctionnait sur une database Access et on a migré sur sql server. Pour les service on utilisais les bon vieux web service des asp .net 2.0 xml et on a migrer ensuite sur WCF. Donc si on a conçue l'architecture comme ça c'Est pour pouvoir migrer vers de nouvelles technologies plus facilement.

Doce deuxieme question:

ensuite il faut fenêtrer tes résultats... ainsi si tu doit transférer de grandes quantités d'objets, tu ne va pas tous les récupérer pour nourrir la DataGrid d'un coup, tu va les récupérer par fragment au fur et a mesure que tu en a besoin, et également penser à "nettoyer" (dé-référencer) ceux que tu n'utilisent plus.

Je présume que tu veux parler ici de paging ... Non je n'ai pas encore toucher à ça mais ce sera fais éventuellement mais pour l'instant je n'amène pas plus de 100 150 objets a la fois donc je ne pense pas que cela puisse me causer des problèmes de mémoire.

Ce problème est moins fréquent en WPF ou en Silverlight où nombre de ces contrôles pour peu que tu autorise la virtualisation, n'allouent les sous contrôles que lorsqu'ils en ont réellement besoin, sacrifiant la vitesse à la mémoire.

Je pense passé à WPF bientôt (d'ici un an)... La migration est elle difficile? ...

Cette application de BI est-elle située sur la même machine que les services WCF (j'espère bien que non et que les services WCF tournent soit sur le serveur de données, soit sur un autre pour être encore mieux)
Ensuite je trouve assez étrange qu'on laisse une telle appli en mémoire, sur des serveurs d'applicatifs (TSE) Faudrait apprendre aux utilisateurs à fermer proprement leur session lorsqu'ils quittent leur bureau à distance, et aussi de quitter leur bureau à distance, les soirs...
C'est pas bien pour l'environnement de laisser tourner les Work-Station la nuit dans une entreprise, et en plus ca alourdi sa facture d'électricité...
Mais bon passons sur ce détail.

Non j'ai 3 serveur physique dont un pro liant dl380 G5 une bonne machine dans laquelle il y a 2 serveur qui roulent sur vmware. Un pour mon SQL Server l'autre comme server web et j'ai un autre server pour mon TS ce sont des thin client qui se loguent et non ce n'est pas très ien de les laissés rouler mais éduquer des néophites de l'informatique c'est pas toujours évident... Et ne t'en fait pas pour l'électricité les thin client en dépensent très peu et ici au queec on la paye pas trop cher lol

Pourquoi ne juges tu pas utile de suivre mon conseil du using ?
De toute façpn le dsispose doit se faire dans l'objet qui a instancié ta form dialog

Merci je ne savais pas la nuance pour le dispose mais je ne pense pas que Using va règler mon problème. Comme les autres ont dit plus tôt tant que l'objet est abonné au event ça ne libèrera pas l'objet. Je crois qu'il faut chercher dans cette direction. JE trouve moi même que Using est très pratique je l'utilise souvent (peut-être pas assé) mais bon c'Est vrai que c'Est une bonne pratique ...

Bonjour, j'ai juste une petite question. Qu'est ce que tu utilises comme techno d'accés aux données (DataSet, EF, autres) ? Le probleme peux venir de la, un dataset par exemple, mal utilisé peux consommer beaucoup de mémoire.

À mort les Datasets lol ça peut être fort utile dans certains cas oui. Mais jamais plus je vais m'en servir pour binder et transporter des données. Parfois pour le bon affichage de certaines grid dans Telerik ils sont necessaire mais c'Est très très rare que je m'en sert.

Merci à tout le monde et continuons comme ça je suis sur qu'on va trouvé la solution.

[AlexDpars]

Pourquoi ne juges tu pas utile de suivre mon conseil du using ?
De toute façpn le dsispose doit se faire dans l'objet qui a instancié ta form dialog

Code :

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

1
2
3
4
5
If e.KeyCode = Keys.F5 Then
     Dim ShowInventory As New ShowInventory(aListOfPartOnLine(0).Inventory)
    ShowInventory.ShowDialog()
    ShowInventory.Dispose();        
End If

Je dois te faire toutes mes excuses mais après test ça fonctionne vraiment. Au début ça me paraissais anodin d'utiliser Using mais je dois dire ça fonctionne. Dans mon sample en tout cas. J'ai eu beaucoup de mal à dépassé les 100 mb et encore la après un moment elle redessent. Comme on dit la solution la plus simple est souvent celle qu'on essaie en dernier en se disant c'est impossible que ce sois seulement ça ... Et oui c'est ça ...

Toutefois cela ne règle qu'une partie de mon problème car il reste de minimes memory leak mais pour l'instant j'arriverai à vivre avec ça. Je fais suivre mes résultats pour ce qui est de mon application. Sinon si vous avez d'autres idées pour l'économie de mémoire faites moi signe.

Et un gros merci à tous.

[olibara]

Je dois te faire toutes mes excuses mais après test ça fonctionne vraiment. Au début ça me paraissais anodin d'utiliser Using mais je dois dire ça fonctionne.

Merci

Il m'avait effectivement semblé que ce sujet partait dans tous les sens en oubliant l'essentiel que tu avais toi meme signalé

et c'est vrai que parfois je fais des open dialog pour ouvrir d'autres form et j'ai remarquer que c'Est justement ça qui prend de la mémoire.

[AlexDpars]

Ça fait une heure que j'ai updater ma nouvelle version et c'est comme un rêve aucune application ne depasse les 100 mb alors qu'avant ça prenais 10 min pour le depasser la mémoire est complètement stable. Un gros merci à tous!!! Je vais essayer de redonner au forum.