J'ai une application C # qui fonctionne avec priorité en temps réel. Tout allait bien jusqu'à ce que je fasse peu de changements mouvementés au cours des 2 derniers jours. Maintenant, il manque de mémoire en quelques heures.
J'essaie de trouver s'il s'agit d'une fuite de mémoire que j'ai créée, c'est parce que je consommerai beaucoup plus d'objets qu'auparavant et que GC ne peut tout simplement pas les recueillir car il fonctionne avec la même priorité.
Ma question est - Que pourrait-il arriver à GC lorsqu'il essaie de collecter des objets dans l'application avec priorité en temps réel (il y a aussi au moins un fil d'exécution avec la priorité de thread la plus élevée)?
( P.S. Par priorité en temps réel, je veux dire processus.getCurrentProcess (). priorityclass = processtriorityclass.realtime ) )
6 Réponses :
Très probablement GC ne peut pas les recueillir car quelque part vous tenez toujours une référence. Essayez de profiler votre application avec un profileur de mémoire (Redgate a un bon, vous devez essayer la version d'essai) pour trouver pourquoi GC ne collectera pas vos objets.
Êtes-vous sûr que la priorité n'est pas le problème? J'ai utilisé Redgate avant que je suis d'accord c'est bon. Mais cela pourrait prendre un peu de temps.
Je doute vraiment que la priorité en temps réel est la cause de votre problème. Je suppose que dans le couple de changements, vous avez mentionné que vous avez mentionné la mémoire quelque part (qui, en C #, signifie généralement tenir des références à des objets qui ne sont plus nécessaires). Vous pouvez utiliser un profileur de mémoire, utiliser WINDBG avec SOS (voir par exemple http: / /msdn.microsoft.com/en-us/magazine/cc163528.aspx ) Ou simplement jetez un coup d'œil à ces changements et essayez de regarder le regard du globe oculaire.
Le GC fonctionne dans votre processus et a donc la même priorité. Il est capable de collecter n'est pas affecté par le Cette fuite de mémoire est presque certainement causée par vous tenant à la racine d'un graphique d'objet en croissance qui empêche le GC de la collecter. priorityclass avec lequel votre application est exécutée.
Oui merci. Je viens de réaliser que c'était une question stupide comme d'habitude :) Bien sûr, comment les threads GC peuvent être en dehors du domaine de l'application et courir avec une priorité différente :) Crazy :)
Les fils de la collection de déchets différemment en fonction du type de système que vous avez configuré pour fonctionner. Sur une station de travail simple, chaque fil individuel hébergera la collection de déchets, mais un seul peut héberger à la fois. Si sa configuration est configurée sur un serveur, un thread séparé accueillera la collection de déchets.
http://msdn.microsoft.com/en-us /Library/ee787088.aspx#Generations
Mais peut-être que vos objets restent trop longs et arrivent à la génération de longue durée de vie, et la collecte des ordures ne les regarde pas aussi souvent que vous le souhaitez.
Ou peut-être avez-vous un autre problème.
> Sur une station de travail simple, chaque fil individuel hébergera la collection de la poubelle [...] Votre résumé de la liaison n'est pas précis. GC peut exécuter sur n'importe quel fil d'utilisateur un seul utilisateur, mais seulement sur une fois; Sur la collecte des ordures du serveur, plusieurs threads distincts sont exécutés.
Je ne recommanderais sérieusement à gérer aucun programme en tant que priorité en temps réel. Fondamentalement, tout ce qui fonctionne à la priorité en temps réel des courses à une priorité plus élevée que l'interface graphique ou même du gestionnaire de tâches Windows ... et peut donc verrouiller l'utilisateur eux-mêmes.
Il y a aussi un avertissement utile dans les commentaires de cet article également: si vous insistez pour que votre demande soit exécutée en priorité en temps réel, vous devez avoir la demande de détection lorsqu'elle perd la mise au point et, dans cette situation, déposer sa priorité. Sinon, l'utilisateur peut avoir de la difficulté à revenir à l'application de l'application et sera donc forcée de redémarrer leur machine ou d'attendre que l'application s'arrête à l'aide de la CPU (qui peut ne jamais se produire).
Ceci est une application purement serveur et est censée être douce-réel.
Au lieu de changer la priorité du fil et éventuellement verrouillage de votre système, vous devez utiliser un profileur de mémoire pour identifier la cause réelle du problème. Vous pouvez également utiliser Performance Monitor pour vérifier les compteurs de performances de la catégorie mémoire CLR .NET pour voir la quantité de mémoire allouée, combien de survit la collecte des ordures, etc.
Oui, je l'ai identifié. L'API de parti 3D pousse en taille;)
Qu'est-ce que cela a à voir avec c #?
Je l'ai fait sur C # et je ne sais que c #. Si quelqu'un répondra en termes de vb.net ou de CLR ou d'interfaces programmables abstraites dans la sphère vide, je ne comprendrais pas ...... pourquoi?