J'ai mis un morceau de code dans un boucle infinie while()
while(true)
{
[...]
System.Threading.Thread.Sleep(500);
}
Dans le gestionnaire des tâches, l'utilisation mémoire monte pendant qq
secondes de 3/5mo. puis se stabilise plusieurs secondes, remonte, se
stabilise, remonte et se stabilise finalement...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
adebaene
Delf a écrit :
Bonjour.
J'ai mis un morceau de code dans un boucle infinie while()
while(true) { [...]
System.Threading.Thread.Sleep(500); }
Dans le gestionnaire des tâches, l'utilisation mémoire monte pendant qq secondes de 3/5mo.
Le gestionnaire des taches est pour ainsi dire inutilsiable pour une analyse sérieuse de la consommation mémoire d'une application, oublie le (ce qu'il affiche dépend du working set, donc de la consommation mémoire globale sur ta machine, pas que de ton application).
Utilises perfmon et regardes le compteur "Private bytes" pour ton processus, ainsi que tous les compteurs dans la catégorie "CLR memory" pour ton processus : ca te donnera une image fiable de la consommation mémoire de ton application.
Arnaud MVP - VC
Delf a écrit :
Bonjour.
J'ai mis un morceau de code dans un boucle infinie while()
while(true)
{
[...]
System.Threading.Thread.Sleep(500);
}
Dans le gestionnaire des tâches, l'utilisation mémoire monte pendant qq
secondes de 3/5mo.
Le gestionnaire des taches est pour ainsi dire inutilsiable pour une
analyse sérieuse de la consommation mémoire d'une application, oublie
le (ce qu'il affiche dépend du working set, donc de la consommation
mémoire globale sur ta machine, pas que de ton application).
Utilises perfmon et regardes le compteur "Private bytes" pour ton
processus, ainsi que tous les compteurs dans la catégorie "CLR memory"
pour ton processus : ca te donnera une image fiable de la consommation
mémoire de ton application.
J'ai mis un morceau de code dans un boucle infinie while()
while(true) { [...]
System.Threading.Thread.Sleep(500); }
Dans le gestionnaire des tâches, l'utilisation mémoire monte pendant qq secondes de 3/5mo.
Le gestionnaire des taches est pour ainsi dire inutilsiable pour une analyse sérieuse de la consommation mémoire d'une application, oublie le (ce qu'il affiche dépend du working set, donc de la consommation mémoire globale sur ta machine, pas que de ton application).
Utilises perfmon et regardes le compteur "Private bytes" pour ton processus, ainsi que tous les compteurs dans la catégorie "CLR memory" pour ton processus : ca te donnera une image fiable de la consommation mémoire de ton application.
Arnaud MVP - VC
Guillaume Davion
Et sinon, pour la question de la fuite mémoire, tout dépends de ce que tu fais dans ta boucle.
Si tu gardes des références sur tous les objets instanciés, ou bien si tu ne fais pas appel à la méthode Dispose() pour ceux qui en ont besoin, ca peut être la cause de fuites.
L'autre idée à suivre et celui d'un fonctionnement "normal" du GC, car en fait le Garbage Collector ne libére les ressources que quand il estime que c'est nécessaire et qu'il a le temps. Du coup, si au bout d'un moment la mémoire se libére malgrès tout, c'est que le GC s'est décidé à faire le ménage.
Et sinon, pour la question de la fuite mémoire, tout dépends de ce
que tu fais dans ta boucle.
Si tu gardes des références sur tous les objets instanciés, ou bien
si tu ne fais pas appel à la méthode Dispose() pour ceux qui en ont
besoin, ca peut être la cause de fuites.
L'autre idée à suivre et celui d'un fonctionnement "normal" du GC,
car en fait le Garbage Collector ne libére les ressources que quand il
estime que c'est nécessaire et qu'il a le temps. Du coup, si au bout
d'un moment la mémoire se libére malgrès tout, c'est que le GC s'est
décidé à faire le ménage.
Et sinon, pour la question de la fuite mémoire, tout dépends de ce que tu fais dans ta boucle.
Si tu gardes des références sur tous les objets instanciés, ou bien si tu ne fais pas appel à la méthode Dispose() pour ceux qui en ont besoin, ca peut être la cause de fuites.
L'autre idée à suivre et celui d'un fonctionnement "normal" du GC, car en fait le Garbage Collector ne libére les ressources que quand il estime que c'est nécessaire et qu'il a le temps. Du coup, si au bout d'un moment la mémoire se libére malgrès tout, c'est que le GC s'est décidé à faire le ménage.
Delf
Guillaume Davion wrote:
Et sinon, pour la question de la fuite mémoire, tout dépends de ce que tu fais dans ta boucle.
Je fais des appels à 5 Web services. J'invoque bien la méthode Dispose() sur mes objets proxy. Donc, j'ai regardé ce que faisaient les Web services.
L'un d'entre eux réinitialise une assembly dynamique via une librairie. Faut-il détruire l'assembly (qui est créée dynamiquement) avant de la "redéfinir" ? Si oui, comment ? Point de Dispose()...
L'autre charge la confguration va la BDR, il ferme bien la clé en fin de traitement :
if (Key != null) { Key.Close(); Key = null; }
Si tu gardes des références sur tous les objets instanciés, ou bien si tu ne fais pas appel à la méthode Dispose()
Tout est initialisé dans la boucle (pour les tests).
pour ceux qui en ont besoin, ca peut être la cause de fuites.
Oui, il va falloir que je fasse ça.
L'autre idée à suivre et celui d'un fonctionnement "normal" du GC, car en fait le Garbage Collector ne libére les ressources que quand il estime que c'est nécessaire et qu'il a le temps.
Je trouve ça assez stressant : Merci.
-- Delf
Guillaume Davion wrote:
Et sinon, pour la question de la fuite mémoire, tout dépends de ce
que tu fais dans ta boucle.
Je fais des appels à 5 Web services. J'invoque bien la méthode Dispose()
sur mes objets proxy. Donc, j'ai regardé ce que faisaient les Web services.
L'un d'entre eux réinitialise une assembly dynamique via une librairie.
Faut-il détruire l'assembly (qui est créée dynamiquement) avant de la
"redéfinir" ? Si oui, comment ? Point de Dispose()...
L'autre charge la confguration va la BDR, il ferme bien la clé en fin de
traitement :
if (Key != null)
{
Key.Close();
Key = null;
}
Si tu gardes des références sur tous les objets instanciés, ou bien
si tu ne fais pas appel à la méthode Dispose()
Tout est initialisé dans la boucle (pour les tests).
pour ceux qui en ont
besoin, ca peut être la cause de fuites.
Oui, il va falloir que je fasse ça.
L'autre idée à suivre et celui d'un fonctionnement "normal" du GC,
car en fait le Garbage Collector ne libére les ressources que quand il
estime que c'est nécessaire et qu'il a le temps.
Et sinon, pour la question de la fuite mémoire, tout dépends de ce que tu fais dans ta boucle.
Je fais des appels à 5 Web services. J'invoque bien la méthode Dispose() sur mes objets proxy. Donc, j'ai regardé ce que faisaient les Web services.
L'un d'entre eux réinitialise une assembly dynamique via une librairie. Faut-il détruire l'assembly (qui est créée dynamiquement) avant de la "redéfinir" ? Si oui, comment ? Point de Dispose()...
L'autre charge la confguration va la BDR, il ferme bien la clé en fin de traitement :
if (Key != null) { Key.Close(); Key = null; }
Si tu gardes des références sur tous les objets instanciés, ou bien si tu ne fais pas appel à la méthode Dispose()
Tout est initialisé dans la boucle (pour les tests).
pour ceux qui en ont besoin, ca peut être la cause de fuites.
Oui, il va falloir que je fasse ça.
L'autre idée à suivre et celui d'un fonctionnement "normal" du GC, car en fait le Garbage Collector ne libére les ressources que quand il estime que c'est nécessaire et qu'il a le temps.
Je trouve ça assez stressant : Merci.
-- Delf
Delf
wrote:
Le gestionnaire des taches est pour ainsi dire inutilsiable pour une analyse sérieuse de la consommation mémoire d'une application, oublie le (ce qu'il affiche dépend du working set, donc de la consommation mémoire globale sur ta machine, pas que de ton application).
Utilises perfmon et regardes le compteur "Private bytes" pour ton processus, ainsi que tous les compteurs dans la catégorie "CLR memory" pour ton processus : ca te donnera une image fiable de la consommation mémoire de ton application.
Intéressant, je connaissais pas trop - j'en avais entendu parlé au sujet des ComputerPerformance je crois -
-- Delf
adebaene@club-internet.fr wrote:
Le gestionnaire des taches est pour ainsi dire inutilsiable pour une
analyse sérieuse de la consommation mémoire d'une application, oublie
le (ce qu'il affiche dépend du working set, donc de la consommation
mémoire globale sur ta machine, pas que de ton application).
Utilises perfmon et regardes le compteur "Private bytes" pour ton
processus, ainsi que tous les compteurs dans la catégorie "CLR memory"
pour ton processus : ca te donnera une image fiable de la consommation
mémoire de ton application.
Intéressant, je connaissais pas trop - j'en avais entendu parlé au sujet
des ComputerPerformance je crois -
Le gestionnaire des taches est pour ainsi dire inutilsiable pour une analyse sérieuse de la consommation mémoire d'une application, oublie le (ce qu'il affiche dépend du working set, donc de la consommation mémoire globale sur ta machine, pas que de ton application).
Utilises perfmon et regardes le compteur "Private bytes" pour ton processus, ainsi que tous les compteurs dans la catégorie "CLR memory" pour ton processus : ca te donnera une image fiable de la consommation mémoire de ton application.
Intéressant, je connaissais pas trop - j'en avais entendu parlé au sujet des ComputerPerformance je crois -
-- Delf
Delf
wrote:
Utilises perfmon et regardes le compteur "Private bytes" pour ton processus, ainsi que tous les compteurs dans la catégorie "CLR memory" pour ton processus : ca te donnera une image fiable de la consommation mémoire de ton application.
J'ai regardé côté handle. Ca monte assez vite...
-- Delf
adebaene@club-internet.fr wrote:
Utilises perfmon et regardes le compteur "Private bytes" pour ton
processus, ainsi que tous les compteurs dans la catégorie "CLR memory"
pour ton processus : ca te donnera une image fiable de la consommation
mémoire de ton application.
Utilises perfmon et regardes le compteur "Private bytes" pour ton processus, ainsi que tous les compteurs dans la catégorie "CLR memory" pour ton processus : ca te donnera une image fiable de la consommation mémoire de ton application.
J'ai regardé côté handle. Ca monte assez vite...
-- Delf
adebaene
Delf a écrit :
wrote:
> Utilises perfmon et regardes le compteur "Private bytes" pour ton > processus, ainsi que tous les compteurs dans la catégorie "CLR memory" > pour ton processus : ca te donnera une image fiable de la consommation > mémoire de ton application.
J'ai regardé côté handle. Ca monte assez vite...
Ca, c'est mauvais signe.... Utilises Process Explorer ou handle (www.sysinternals.com) pour regarder à intervalles réguliers quels sont les objets sur lesquels ton processus à des handles ouverts...
Arnaud MVP - VC
Delf a écrit :
adebaene@club-internet.fr wrote:
> Utilises perfmon et regardes le compteur "Private bytes" pour ton
> processus, ainsi que tous les compteurs dans la catégorie "CLR memory"
> pour ton processus : ca te donnera une image fiable de la consommation
> mémoire de ton application.
J'ai regardé côté handle. Ca monte assez vite...
Ca, c'est mauvais signe.... Utilises Process Explorer ou handle
(www.sysinternals.com) pour regarder à intervalles réguliers quels
sont les objets sur lesquels ton processus à des handles ouverts...
> Utilises perfmon et regardes le compteur "Private bytes" pour ton > processus, ainsi que tous les compteurs dans la catégorie "CLR memory" > pour ton processus : ca te donnera une image fiable de la consommation > mémoire de ton application.
J'ai regardé côté handle. Ca monte assez vite...
Ca, c'est mauvais signe.... Utilises Process Explorer ou handle (www.sysinternals.com) pour regarder à intervalles réguliers quels sont les objets sur lesquels ton processus à des handles ouverts...
