2010-10-21 16 views
1

J'essaie de comprendre pourquoi l'utilisation de la mémoire dans une application de base que j'écris est excessive. Je suis en train de créer un plan du site MVC dynamique avec environ 25000 nœuds et peuplant d'une table de base de données en utilisant le cadre de l'entité (bien que ce détail est probablement pas important)Le cadre d'entité utilise-t-il ma mémoire?

je le code suivant:

foreach (var c in context.Companies) { }

Avec un point d'arrêt avant cette ligne, webdev.webserver40.exe consomme environ 50mb. Ensuite environ 250mb. J'ai essayé de disposer du contexte, laissant le contexte tomber hors de la portée; appeler GC.Collect() à chaque fois, mais je n'arrive pas à récupérer cette mémoire. NB Je sais que la mémoire n'a pas à être, et normalement n'est pas libérée immédiatement, je veux juste me mettre à l'aise qu'il n'y a pas de fuite de mémoire ici.

Merci

Répondre

0

Pourquoi ne pas Révolutionnez l'un des profileurs de mémoire disponibles dans le commerce (tous ont des essais gratuits) un MemProfiler, comparer 2 instantanés et voir où vous alliez mémoire.

Sans voir votre code, il est difficile de dire si vous avez une fuite de mémoire.

1

J'ai une situation similaire avec presque le même code, sauf que mon contexte est le contexte Entity Framework, et les données proviennent de la base de données. Il semble qu'il s'agisse d'un «pic d'utilisation de la mémoire» et non d'une «fuite» permanente, car la consommation globale de mémoire du processus revient finalement à un niveau normal raisonnable. Ce n'est quand même pas une bonne chose.

Il semble qu'il charge en mémoire les données de colonne entières, y compris une grande colonne de données binaires dans mon cas. Les données sont conservées jusqu'à la fin de la "portée" (par exemple, le contenu sort du cadre). Lors de la mise en boucle, certaines données survivent à la collecte des ordures et sont promues aux générations suivantes, ce qui entraîne une période de rétention plus longue (dans mon cas, la mémoire est libérée environ 10 minutes plus tard).

J'ai essayé plusieurs choses mais je pense que c'est juste un comportement que nous devons adopter.

Dans mon cas particulier, j'utilisais la sérialisation binaire pour sauvegarder l'état de l'objet dans la base de données. Je n'ai pas encore résolu cela mais ma solution pour réduire le pic d'utilisation de la mémoire serait de refactoriser le code afin de ne pas utiliser la sérialisation binaire mais plutôt d'enregistrer les données primitives dans les colonnes de la table de base de données. Le niveau de correction suivant consisterait à utiliser «initialisation paresseuse», puis mise en cache, etc.

Dans votre plan du site, vous pouvez peut-être «segmenter» la vue et charger uniquement le sous-ensemble des nœuds.