2009-04-04 11 views
13

Welchen maximalen Speicherplatz kann man in .NET Managed Code erreichen? Kommt es auf die tatsächliche Architektur an (32/64 Bit)?Maximaler verfügbarer .NET-Speicher?

+0

Ja, es ist .. Geben Sie ihm einen Schuss und beobachten Sie die Laufzeit bomb out bei etwa 900MB auf 32-Bit-Architekturen .. Oder einfach einen anständigen, nicht einmal großen, Dataset ausführen .. traurig wirklich. –

+0

Mehr Fakten wären nett. –

+0

Nun, wenn Sie eine Tatsache benötigen, dann laden Sie es besser und achten Sie auf OutOfMemory Ausnahme, wenn es erreicht wird .. Das Problem ist, müssen Sie nur ein paar solcher Anwendungen (Sie wissen, anständige Größe) und voila: CLR Effiziente Theoretiker bekommen alles schlau. –

Antwort

2

Ja, in einer 32-Bit-Umgebung sind Sie auf einen 4-GB-Adressraum beschränkt, aber Windows beansprucht etwa die Hälfte. Auf einer 64-Bit-Architektur ist es, naja, viel größer. Ich glaube, es 4G ist * 4G

Und auf der Compact Framework ist es in der Regel in der Größenordnung von einigen hundert MB

+2

Sagen 4G * 4G wird Leute irreführen, um 16G zu denken. Wirklich, 4G ist 2^32 Bytes, also fast 4 Milliarden. und das 64-Bit-Limit ist 2^64 = (2^32) * (2^32), was (4 Milliarden) * (4 Milliarden) ist und das ist viel mehr als 16G. – Karl

11

Es gibt keine harten, genaue Zahl für .NET-Code.

Wenn Sie auf 32-Bit-Windows ausführen; Ihr Prozess kann bis zu 2 GB, 3 GB, wenn du die/3GB auf Windows Server 2003

Wenn Sie auf einem 64-Bit-Feld Ihres Prozess einen 64-Bit-Prozess ausgeführt verwendet wird bis zu 8 adressiert TB Adressraum, wenn soviel RAM vorhanden ist.

Dies ist jedoch nicht die ganze Geschichte, da die CLR einige Overhead für jeden Prozess benötigt. Zur gleichen Zeit wird .NET versuchen, neuen Speicher in Blöcken zuzuweisen; Wenn der Adressraum fragmentiert ist, kann das bedeuten, dass Sie nicht mehr Speicher reservieren können, obwohl einige verfügbar sind.

+0

Das ist nicht wahr. Windows auf x86 beschränkt die Benutzermodus-Partitionsgröße auf 8 TB (8192 GB). –

+1

"kann den gesamten 64-Bit-Adressraum adressieren, wenn so viel RAM vorhanden ist", ist das nicht korrekt und sollte bearbeitet werden. –

+1

32-Bit-Prozess unter 64-Bit-Windows kann auf 4 GB Benutzerraum zugreifen (mit großen Adresse bewusst ... das gleiche Kriterium, um auf 3GB unter/3GB-Schalter zugreifen). – Richard

7

In C# 2.0 und 3.0 gibt es auch eine 2G-Beschränkung für die Größe eines einzelnen Objekts in verwaltetem Code.

0

Ich denke, andere Antworten sind ziemlich naiv, in der realen Welt nach 2 GB Speicherverbrauch wird sich Ihre Anwendung wirklich schlecht verhalten. Nach meiner Erfahrung gehen GUIs in der Regel massiv klobig und nach vielen Speicherverbräuchen nicht mehr zu gebrauchen.

Dies war meine Erfahrung, offensichtlich eigentliche Ursache für diese kann Objekte zu groß werden, so dass alle Operationen auf diese Objekte zu viel Zeit braucht.

5

Für 64-Bit-Windows beträgt die Größe des virtuellen Arbeitsspeichers 16 TB, die zu gleichen Teilen zwischen Benutzer- und Kernelmodus aufgeteilt sind, sodass Benutzerprozesse 8 TB (8192 GB) adressieren können. Das ist weniger als der gesamte Platz, der mit 64 Bits adressierbar ist, aber es ist noch viel mehr als das, was wir mit 32 Bits gewohnt sind.

3

Die .NET-Laufzeitumgebung kann den gesamten freien Speicher für Programme im Benutzermodus auf dem Host zuweisen. Beachten Sie, dass dies nicht bedeutet, dass der gesamte Speicher für Ihr Programm reserviert ist, da einige (relativ kleine) Teile für interne CLR-Datenstrukturen reserviert sind. In 32-Bit-Systemen sollten Sie unter der Annahme einer 4 GB oder mehr Konfiguration (selbst wenn PAE aktiviert ist) in der Lage sein, die Ihrer Anwendung maximal zugewiesenen 2 GB zu erreichen. Auf 64-Bit-Systemen sollten Sie 1 TB bekommen können. Weitere Informationen zu Windows-Speicherbeschränkungen finden Sie unter this page. Jede dort genannte Zahl muss durch 2 geteilt werden, da Windows die höhere Hälfte des Adressraums für die Verwendung durch Code reserviert, der im Kernel-Modus läuft (Ring 0). Beachten Sie bitte, dass, wenn für ein 32-Bit-System das Limit 4GB überschreitet, die Verwendung von PAE impliziert ist und Sie die 2GB-Grenze daher nicht wirklich überschreiten können, außer das Betriebssystem unterstützt 4gt. In diesem Fall können Sie bis zu 3GB erreichen .

7

Die Größe des Speichers, den Ihr .NET-Prozess adressieren kann, hängt davon ab, ob er auf einem 32/64-Bit-Computer ausgeführt wird und ob er als CPU-agnostischer oder CPU-spezifischer Prozess ausgeführt wird.

Standardmäßig ist ein .NET-Prozess CPU-unabhängig und wird daher mit dem Prozesstyp ausgeführt, der für die Windows-Version selbstverständlich ist. In 64 Bit wird es ein 64-Bit-Prozess sein, und in 32 Bit wird es ein 32-Bit-Prozess sein.Sie können jedoch einen .NET-Prozess erzwingen, der auf eine bestimmte CPU abzielt, und sagen, dass sie als 32-Bit-Prozess auf einer 64-Bit-Maschine ausgeführt werden soll.

Wenn Sie die große Adresse bewusst Einstellung ausschließen, die folgenden sind die verschiedenen Pannen

  • 32-Bit-Prozess kann 2 GB adressieren
  • 64-Bit-Prozess kann 8TB Adresse

Hier ist ein Link auf die vollständige Aufschlüsselung des adressierbaren Speicherplatzes basierend auf den verschiedenen Optionen, die Windows bietet.

http://msdn.microsoft.com/en-us/library/aa366778.aspx

0

Die folgenden Blog-Post hat Erkenntnisse auf x86 und x64 Max-Speicher detailliert beschrieben. Es hat auch ein kleines Werkzeug (Quelle verfügbar), das eine einfache Ausrichtung der verschiedenen Speicheroptionen ermöglicht: http://www.guylangston.net/blog/Article/MaxMemory.

5

Ich habe vor kurzem umfangreiche Profiling um Speicher Grenzen in .NET auf einem 32-Bit-Prozess. Wir alle werden von der Idee bombardiert, dass wir in einer .NET-Anwendung bis zu 2,4GB (2^31) zuweisen können, aber unglücklicherweise ist das nicht wahr :(. Der Anwendungsprozess hat so viel Platz zu verwenden und das Betriebssystem macht einen großen Englisch: www.openbsd.dk/faq/pf//queuing.html .NET selbst scheint jedoch einen eigenen Overhead aufzuweisen, der für typische Anwendungen in der realen Welt, die das Speicherlimit überschreiten, etwa 600-800MB ausmacht, das heißt, sobald Sie ein Array von ganzen Zahlen zuweisen, das ungefähr dauert 1.4GB, sollte man eine OutOfMemoryException() erwarten.

Offensichtlich in 64bit tritt diese Grenze viel später auf (lass uns in 5 Jahren chatten :)), aber die allgemeine Größe von allem im Speicher wächst auch (Ich finde es ist ~ 1,7 bis ~ 2 mal) wegen der erhöhten Wortgröße.

Was ich sicher weiß ist, dass die Virtual Memory-Idee vom Betriebssystem definitiv nicht praktisch unbegrenzte Allokationsfläche innerhalb eines Prozesses gibt. Es ist nur dort, so dass die vollen 2,4 GB für alle (viele) Anwendungen zur gleichen Zeit adressierbar ist.

Ich hoffe, diese Einsicht hilft etwas.

ich ursprünglich etwas beantwortet hier erzählt (ich bin immer noch ein newby so bin nicht sicher, wie soll ich diese Links tun):

Is there a memory limit for a single .NET process

+0

Warum wollten Sie dieselbe Antwort mehrmals posten? –

+0

Sorry, bin ein Noob. Wie verknüpfst du verwandte Fragen und Antworten auf dieser Seite? –