Effacer la mémoire CLR

Question

Im se heurtant à un problème où l'outil im utilisant pour le développement (un outil de simulateur) continue à lancer OutofMemoryException, je sais que ce n'est pas mon application, car peu importe ce que le projet im en cours, il arrive. La seule solution que j'ai pour le moment est de redémarrer mon PC, y a-t-il un moyen de vider/effacer l'exécution du CLR afin de ne pas avoir à redémarrer mon PC chaque fois que cela arrive? Les exceptions OutOfMemory n'indiquent pas nécessairement un problème avec le runtime.

Answer 1

Chaque fois que votre système manque de mémoire, peu importe ce qui le consume, cela peut arriver.

Regardez la liste des processus dans le gestionnaire de tâches et voyez ce qui consomme le plus de mémoire.

Answer 2

Chaque processus qui exécute le code managé démarre une copie distincte de l'exécution CLR - et lorsque tout type de processus est terminé, la mémoire qu'il a consommée est récupérée dans le pool général.

Il n'y a rien partagé pour "vider" ou "effacer".

Est-il possible que votre outil de simulation ne se bloque pas «complètement» - que le processus reste dans un état défectueux?

Answer 3

Il semble que ce soit un outil tiers. Donc, je vais déposer une demande de bogue avec eux.

Mais comme d'autres l'ont dit, le problème sera contenu dans un processus du système d'exploitation. En utilisant le gestionnaire de tâches, vous devriez être capable d'identifier le processus incriminé et de le tuer. Cela va récupérer la mémoire et effacer l'ardoise. Vous devrez ensuite redémarrer votre simulation.

Si ce problème vous empêche de terminer votre simulation, alors je déposerais une demande de bogue urgente (mais pas fâchée).

Answer 4

Un processus en mode utilisateur x86/32 bits sous Windows dispose uniquement d'un espace de mémoire virtuelle adressable de 2 Go. Un processus x64/64 bits a 16 To de mémoire virtuelle adressable. Vous n'avez pas dit si votre processus était de 32 ou 64 bits - mais je suppose que c'est 32 bits. Une fois qu'un processus 32 bits commence à s'aventurer dans la zone de plus de 1,5 Go de mémoire virtuelle ou engagée, vous jouez avec le feu et il est temps que l'application se bloque. Il n'y a pas de nombre précis sur le moment où il va se bloquer car chaque application est différente. Parlons donc du "2GB" de l'espace adressable ... la mémoire utilisée par votre application n'a PAS accès à l'ensemble des 2Go de mémoire. Il est en tête utilisé par beaucoup de morceaux que le CLR a besoin pour exécuter une application:

1. Les 8 tas différents pour une application .NET - voir ma réponse à .NET process memory usage = 5x CLR Heap Memory?
2. en tête du noyau pour l'exécution du processus en mode utilisateur
3. Threads
4. etc.

vous pouvez avoir des concerts de mémoire disponible sur votre système, mais une application peut facilement tomber en panne si elle est x86 et proche de la limite décrite ci-dessus.

J'ai posté un peu de réponses et d'informations sur la mémoire CLR ici sur StackOverflow décrivant comment beaucoup de cela fonctionne. Cherchez mon nom et vérifiez quelques-unes des autres réponses. Cela pourrait aider à éclaircir un peu les choses.

HTH