Thread.Start : exception OutOfMemory [Résolu]

cs_Aurore38 10 Messages postés jeudi 29 décembre 2005Date d'inscription 9 septembre 2009 Dernière intervention - 7 juin 2007 à 11:33 - Dernière réponse : cs_Aurore38 10 Messages postés jeudi 29 décembre 2005Date d'inscription 9 septembre 2009 Dernière intervention
- 27 juin 2007 à 10:39
Le Contexte :
===========
En C# .Net1.1, sous visual studio 2003
nous avons développé un client-serveur en utilisant les fonctionnalités de System.Runtime.Remoting.
a réception de chaque message "nouveau chargement", nous lancons un thread permettant de traiter ce chargement.
ayant des problèmes de mémoire utilisée par notre serveur (application console),
   nous avons ajouté à intervalle régulier l'appel à
        SetProcessWorkingSetSize(System.Diagnostics.Process.GetCurrentProcess().Handle, -1, -1) ;
   et ajouté dans nos structures des fonctions Dispose finissant par :
        GC.SuppressFinalize(this);

Ca semblait fonctionner, en regardant avec le gestionnaire de processus, le % de mémoire utilisé est stable entre 7 et 10Mo...

Le Problème
=========
En voulant rajouter une fonctionnalité à notre serveur, nous avons détecté le problème suivant :
      sur une action Thread.Start nous avons l'exception "OutOfMemory".
      et notre serveur se bloque
      
      Ayant fait un programme de simulation qui envoie des messages au serveur et qui note toutes les 5mn l'état du processus server voila ce que j'obtiens :
      07/06/2007 10:14:38 NbThreads=15 VMem=138 428 416
              UserProcTime=00:00:00.3593750 TotalProcTime=00:00:00.9375000
              PrivateMem=17203200
      07/06/2007 10:19:38 NbThreads=22 VMem=442 904 576
              UserProcTime=00:00:02.7343750 TotalProcTime=00:00:06.7812500
              PrivateMem=30269440
      07/06/2007 10:24:38 NbThreads=21 VMem=715 534 336
               UserProcTime=00:00:04.3906250 TotalProcTime=00:00:11.7812500
               PrivateMem=37363712
      07/06/2007 10:29:38 NbThreads=22 VMem=1 002 844 160
               UserProcTime=00:00:06.2031250 TotalProcTime=00:00:17.3593750                    
               PrivateMem=44703744
      et ca continue de croitre jusqu'à ce que VMem atteigne 2 000 000 000 et que nous ayons outofmemory.      (Vmem Process.VirtualMemorySize, UserProcTime Process.UserProcessorTime, TotalProcTime = Process.TotalProcessorTime
        et PrivateMem =Process.PrivateMemorySize
      
Comme notre serveur est une application console qui lance des thread et que Microsoft (support.microsoft.com : article 828988) conseille de mettre en multithreading
c'est ce que j'ai fait...
[MTAThread]
static void Main
Mais pas mieux...

La Question
============
Quelqu'un pourrait il m'expliquer ce qu'est cette memoire virtuelle ?  et si ca pourrait etre liée à mon problème d'exception ?
Afficher la suite 

Votre réponse

6 réponses

Meilleure réponse
cs_niky 168 Messages postés jeudi 28 juin 2001Date d'inscription 18 octobre 2008 Dernière intervention - 11 juin 2007 à 15:21
3
Merci
Salut,

Pour traquer les fuites mémoire tu peux utiliser un profiler. Il en existe pas mal pour .Net. Microsoft en donne une liste assez complète sur la page http://msdn2.microsoft.com/en-us/vcsharp/aa336818.aspx.
Sinon, les plus connus sont :
http://memprofiler.com/
http://ncover.org/site/
http://www.mertner.com/confluence/display/NProf/Home

Ces logiciels ne sont pas toujours évident à manipuler.

Merci cs_niky 3

codes-sources a aidé 81 internautes ce mois-ci

Commenter la réponse de cs_niky
cs_coq 6366 Messages postés samedi 1 juin 2002Date d'inscription 2 août 2014 Dernière intervention - 8 juin 2007 à 22:39
0
Merci
Salut,

En gros : le fichier de pagination. (Je ne sais plus si VirtualMemorySize ne comprend que la partie pagination ou d'autres compteurs)
Traiter le problème de consommation mémoire par la provocation de l'envoi en fichier de pagination n'est pas vraiment une solution, la preuve : quand c'est plein, c'est plein. Sans parler de l'impact sur les performances.
Il vaudrait mieux déterminer de où vient la fuite mémoire et corriger ce problème là.

/*
coq
MVP Visual C#
CoqBlog
*/
Commenter la réponse de cs_coq
cs_Aurore38 10 Messages postés jeudi 29 décembre 2005Date d'inscription 9 septembre 2009 Dernière intervention - 11 juin 2007 à 09:24
0
Merci
Bonjour,

Ok, j'ai probablement une fuite de mémoire, ca m'apprendra a faire confiance...

Des idées de logiciels pour traquer ma fuite ?

Merci
Commenter la réponse de cs_Aurore38
cs_Aurore38 10 Messages postés jeudi 29 décembre 2005Date d'inscription 9 septembre 2009 Dernière intervention - 12 juin 2007 à 13:34
0
Merci
Merci pour les infos sur les profilers...

j'ai essayé memprofiler il y a qq temps mais la version 3.0 ne correspond pas aux tutoriaux qui sont sur leur site !
Dommage j'avais bien compris le fonctionnement dans les tutoriaux mais avec la version que j'ai je ne vois que les types et pas les classes...
Bref, je continue de bosser la dessus.
Je vais essayer les autres.
Commenter la réponse de cs_Aurore38
cs_Aurore38 10 Messages postés jeudi 29 décembre 2005Date d'inscription 9 septembre 2009 Dernière intervention - 15 juin 2007 à 12:46
0
Merci
(suite de mon problème...)

Après utilisation de MemoryProfiler et CLRProfiler :
de la mémoire virtuelle semble (entre autre) allouée dans l'appel de Open à ma base de données :

en gros je fais :
    using System.Data.Odbc;
    
    OdbcConnection oConn = new OdbcConnection(...);
    OdbcCommand oCmd = MaFonctionCreationCmd(..);
    oConn.Open();
    ... oCmd.Execute(); ...
    oConn.Close();
    oConn.dispose();
    oConn = null;
    
j'ai Firebird 1.5.3.4870, OdbcDriver 1.2.0.69
Je n'arrive pas à définir si mes problèmes viennent des dll C# ou de celles de firebird.
MemProfiler me dit que c'est UnsafeNativeMethods.Odbc32.SQLDriverConnectW qui passe en code non managé...

Avant de faire ce code je ne "disposais" pas des connexions et des odbcommand, j'ai ajouté ce traitement mais ca ne modifie pas mon problème.

A suivre...
Commenter la réponse de cs_Aurore38
cs_Aurore38 10 Messages postés jeudi 29 décembre 2005Date d'inscription 9 septembre 2009 Dernière intervention - 27 juin 2007 à 10:39
0
Merci
Ca y est c'est fini, nous avons trouvé.

Nous utilisons maintenant directement le pilote .net pour acceder à notre base et plus System.data.odbc...

Ca va beaucoup mieux.
Commenter la réponse de cs_Aurore38

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.