Freier Speicher in Delphiprogrammen ermitteln?

[Mavarik]

Hallo Zusammen...

Simples Programm:

Delphi-Quellcode:

Var
  f : array[0..100] of TByteDynArray;

procedure TForm49.Button2Click(Sender: TObject);
Var
   M : TMemoryStatus;
   i : Integer;
begin
  for i:=0 to 100 do
    begin
      Setlength(F[i],1024*1024*256);
      GlobalMemoryStatus(M);
      Memo1.Lines.add(Inttostr(M.dwTotalPhys div 1024)+' / '+Inttostr((M.dwAvailPhys) div 1024));
      Application.Processmessages;
    end;
end;

Ausgabe:
4194303 / 4194303
4194303 / 4194303
4194303 / 4104164
4194303 / 3840000
4194303 / 3580524

Peng - Out of Memory... Warum?

Wo ist der Trick?

Grüsse Mavarik

[himitsu]

Phys gibt den Speicher vom gesamten Windows an ... Was aber in deinem Programm, also im "virtuellen" Speicher, belegt/frei ist und was du demnach wirklich verwenden kannst, ist damit nicht ausgesagt!



Und du forderst "zusammenhängenden" Speicher von 256 MB + 8 Byte an.

Wenn kein so großer zusammenhängender Block mehr da ist, dann *peng*.
Übeall fein verteilt liegt genutzter Arbeitsspeicher ( Heap? ), der/die Stacks, die gemappten Resourcen, und Programmcodes der EXE und DLLs rum.

Du könntest dir höchstens eine Memory-Map erstellen, wo du alle freien Stellen anzeigst.

PS: OK, bei der Größegibt dir FastMM einen Big-Block, welcher direkt von Windows geholt wird (VirtualAlloc), aber bei kleineren Speicherblöcken, geht das auf Medium- und Small-Blocks, welche immer in Gruppen bei Windows reserviert werden, wovon nicht alle verwendet sein müssen ... diese sind also laut Windows belegt, aber FastMM kann sie dennoch ans Programm weitergeben, weil sie eben nur "vorbestellt"/reserviert sind.


Tipp: GlobalMemoryStatusEx




Ach ja, und du schreibst nichts in diesen Speicher rein, das merkt Windows und verknüpft dieses nicht unbedingt sofort mit "echtem" Speicher ... erst wenn das wirklich verwendet wird.

Delphi-Quellcode:

type
  TIntArray = array[0..0] of Integer;
  PIntArray = ^TIntArray;
var
  i, i2 : Integer;
begin
  for i := 0 to 100 do
    begin
      Setlength(F[i], 1024*1024*256);
      for i2 := 1024*1024*256 div 1024 - 1 downto 0 do
        PIntArray(@F[i])[i2 * 1024 div SizeOf(Integer)] := 666;
      GlobalMemoryStatus(M);

(man könnte och mit FillChar und Co. jedes Byte einzeln füllen, aber Windows verwaltet den Speicher sowieso nicht byteweise ... 4 KB und 64 KB)

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1174430)

Peng - Out of Memory... Warum?

Weil in dem 32-Bit Adressraum deines Prozesses kein 256 MB-Großer zusammenhängender Bereich mehr frei ist.
Die ganzen DLLs die Windows noch zu deinem Prozess läd führen bei ungünstiger Implementierung dieser DLL noch schneller zu diesem PENG

Zitat:

Zitat von Mavarik (Beitrag 1174430)

Wo ist der Trick?

Kleinere Speicherblöcke anfordern oder als 64-Bit Anwendung kompilieren.

[Mavarik]

OK, Aber wie bekommen ich den Restspeicher in meinem 32 Bit Adressraum raus?

Mavarik

[himitsu]

physical (Windows) ... Virtual (Programm)

[info] hatte oben nochmal editiert


schön, daß es beim Editieren keine RedBox gibt

[Mavarik]

Mal abgesehen von der Exception die ich bei Deinem Code bekommen...;-)

Was ist aus dem guten alten MemAvail/MaxAvail geworden?

Wie Frage ich den jetzt meinen Restspeicher ab?

Mavarik

[tgvoelker]

Zitat:

Zitat von Mavarik (Beitrag 1174439)

Peng - Out of Memory... Warum?

Weil Du den allokierten Speicher immer weiter erweiterst. Insofern stimmt

Zitat:

Zitat von himitsu (Beitrag 1174435)

Und du forderst "zusammenhängenden" Speicher von 256 MB + 8 Byte an.

nicht.

Der Speicherblock, in dem Deine Struktur angelegt wird, ist eben nicht so groß, und wenn Du immer mehr Speicher allokierst, dann knallt es eben irgendwann.

Zu beachten ist ferner, daß Du nicht 4GB Datenspeicher allokieren kannst, standardmäßig nur 2GB, mit einem Bootswitch 3GB (http://support.microsoft.com/default...22120121120120 ==> in der Mitte)

Ich hatte mal ein Problem, daß ich große Grafikdaten im Speicher konvertieren mußte. Das Problem dabei war, daß ich oft nicht zusammenhängende Blöcke bekommen habe, die die Daten aufnehmen konnten (analog Deines Problemes).

Ich habe als Lösung eine Klasse geschrieben, die die segmentierten Blöcke allokiert und mit durchgängiger Adressierung angesprochen werden kann: http://www.tgvconsult.de/attachments...moryStream.zip

[Mavarik]

Zitat:

Zitat von tgvoelker (Beitrag 1174445)

Zu beachten ist ferner, daß Du nicht 4GB Datenspeicher allokieren kannst, standardmäßig nur 2GB, mit einem Bootswitch 3GB (http://support.microsoft.com/default...22120121120120 ==> in der Mitte)

Ich hatte mal ein Problem, daß ich große Grafikdaten im Speicher konvertieren mußte. Das Problem dabei war, daß ich oft nicht zusammenhängende Blöcke bekommen habe, die die Daten aufnehmen konnten (analog Deines Problemes).

Ich habe als Lösung eine Klasse geschrieben, die die segmentierten Blöcke allokiert und mit durchgängiger Adressierung angesprochen werden kann: http://www.tgvconsult.de/attachments...moryStream.zip

Danke für Deine Antwort... Aber darum geht es garnicht...

Ich will garnicht auf 4GB oder meine 8GB RAM zugreifen... Ich will lediglich vor einer Speicherreservierung abfragen können ob der Speicher + eine "not-Reserve" noch frei ist... Und zwar innerhalb der 32BIT Kachel die ich vom Windows erhalten habe... Bei XP oder Win32 stellt sich die Frage nicht, da "NIE" genug Speicher da ist... aber ich erhalte ja unter Win 7 64 Bit die Meldung 3,8 GB Frei aber die Meldung Out of Memory...

Mavarik

[himitsu]

[QUOTE=tgvoelker;1174445]

Zitat:

Zitat von Mavarik (Beitrag 1174439)

Insofern stimmt

Zitat:

Zitat von himitsu (Beitrag 1174435)

Und du forderst "zusammenhängenden" Speicher von 256 MB + 8 Byte an.

nicht.

Nicht?

Delphi-Quellcode:

Setlength(..., 1024*1024*256);

fordert für das dynamische Array 268435456 Felder an, was durch SizeOf(Byte) der einzelnen Felder natürlich den 256 MB entspricht und dazu dann noch 2 Integer für die Verwaltung des Arrays (Größe und Referenzzählung).



Button1 = Deines
Button2 = Sucht die größten Speicherblöcke

[add]
Mit

Delphi-Quellcode:

NativeUInt(F[i])

könntest du dir noch die Speicheradressen dieser Blöcke ausgeben lassen.

Ach ja, am Ende bleibt noch etwas im Virtual übrig ... das sind vermutlich RESERVED-Blocks, welche frei sind, aber nicht "nochmal" reserviert (MEM_COMMIT) werden können. (siehe VirtualAlloc)

[Mavarik]

Hmm

Interessant...

Ich verstehe zwar nicht so ganz was Du da machst...

Aber M.dwAvailVirtual scheint der richtige Wert zu sein...

Abgesehen davon, das das Programm nicht durchläuft und mit einer Exception abstürtzt...

Mavarik

[Mavarik]

hmm Leider auch nicht...

Delphi-Quellcode:

procedure TForm49.Button2Click(Sender: TObject);
Var
   M : TMemoryStatus;
   i,i2 : Integer;
begin
  i2 := 1024*1024*256;
  for i:=0 to 100 do
    begin
      Setlength(F[i], i2);
      GlobalMemoryStatus(M);
      Memo1.Lines.add(Inttostr(M.dwAvailVirtual div 1024)+' / '+inttostr(M.dwTotalPhys div 1024)+' / '+Inttostr((M.dwAvailPhys) div 1024));
      if M.dwAvailVirtual < i2 then
        i2 := M.dwAvailVirtual div 2;
      Application.Processmessages;
    end;
end;

Funktioniert leider auch nicht....

[himitsu]

Hier läuft es durch ... Wo knall es denn?
Ohne Fehlerbeschreibung kann keiner helfen. :wall:

Nja, es wird einfach in einer Schleife versucht immer wieder einen möglichst großen Block (den aktuell Größten) zu reservieren.
In der inneren Schleife werden verschiedene Größen ausprobiert und es wird sich der möglichen Größe so lange angenähert, bis es grade noch so rein passt.


Wenn man nun ein dynamisches Array in einer Schleife Schritt für Schritt um 1 vergrößtert, dann kann man im Schlimmsten Fall davon ausgehn, daß dieses Array maximal nur ein Drittel so groß werden kann, wie der größte Block.

[Mavarik]

Bei Deiner Routine?

Access violation at 0x77770077a ;-)

Wieviel RAM hast Du den? Win 7 64 Bit?

Mavarik

[himitsu]

Zitat:

Zitat von Mavarik (Beitrag 1174498)

Access violation at 0x77770077a ;-)

Und welche Codezeile könnte das sein?

Ein Netbook mit 2 GB RAM und 1,5 in der Pagefile. (also 3,5 GB)
Und 'nen Server mit 12 GB RAM und nochmal 3 GB Auslagerungsdatei. (= 15 GB ... darum auch der Hinweis auf GlobalMemoryStatusEx)

Ach ja:
dwAvailVirtual ist das, was im virtuellen Speicher der Anwendung nicht belegt ist.
dwAvailPhys (echter RAM) + dwAvailPageFile (Auslagerungsdatei) ist das, was im gesamten Windows noch frei ist.

Real steht also nur noch der jeweils kleinere Wert, von den Beiden, zur Verfügung.

[Mavarik]

Delphi-Quellcode:

  finally
    for i := 0 to 100 do // 100 Du hast nur bis 20 definiert!
      VirtualFree(F[i], 0, MEM_RELEASE);
  end;

Ausgabe:

Gesamt ********* Size ******** Virtual 1.996.284 / 2.097.024 Load 39% Physical 4.194.304 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.509.504 Size 1.509.504 Virtual 486.780 / 2.097.024 Load 57% Physical 3.555.524 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.701.696 Size 192.192 Virtual 294.588 / 2.097.024 Load 59% Physical 3.360.848 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.823.360 Size 121.664 Virtual 172.924 / 2.097.024 Load 61% Physical 3.238.984 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.858.688 Size 35.328 Virtual 137.596 / 2.097.024 Load 61% Physical 3.201.668 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.883.776 Size 25.088 Virtual 112.508 / 2.097.024 Load 62% Physical 3.177.476 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.903.488 Size 19.712 Virtual 92.796 / 2.097.024 Load 62% Physical 3.156.356 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.923.136 Size 19.648 Virtual 73.148 / 2.097.024 Load 62% Physical 3.137.532 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.942.528 Size 19.392 Virtual 53.756 / 2.097.024 Load 62% Physical 3.117.464 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.956.736 Size 14.208 Virtual 39.548 / 2.097.024 Load 62% Physical 3.104.156 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.961.088 Size 4.352 Virtual 35.196 / 2.097.024 Load 63% Physical 3.099.800 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.964.608 Size 3.520 Virtual 31.676 / 2.097.024 Load 63% Physical 3.095.760 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.967.680 Size 3.072 Virtual 28.604 / 2.097.024 Load 63% Physical 3.091.828 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.970.176 Size 2.496 Virtual 26.108 / 2.097.024 Load 63% Physical 3.091.040 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.971.520 Size 1.344 Virtual 24.764 / 2.097.024 Load 63% Physical 3.088.420 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.972.864 Size 1.344 Virtual 23.420 / 2.097.024 Load 63% Physical 3.087.380 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.974.016 Size 1.152 Virtual 22.268 / 2.097.024 Load 63% Physical 3.087.076 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.974.592 Size 576 Virtual 21.692 / 2.097.024 Load 63% Physical 3.086.760 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.975.168 Size 576 Virtual 21.116 / 2.097.024 Load 63% Physical 3.086.204 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.975.744 Size 576 Virtual 20.540 / 2.097.024 Load 63% Physical 3.084.844 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.976.128 Size 384 Virtual 20.156 / 2.097.024 Load 63% Physical 3.083.964 / 4.194.304 Pagefile 4.194.304 / 4.194.304
Gesamt 1.976.512 Size 384 Virtual 19.772 / 2.097.024 Load 63% Physical 3.083.584 / 4.194.304 Pagefile 4.194.304 / 4.194.304

[himitsu]

Aber komisch witzig, daß es hier lief. (hab die Dateien dahingehend überarbeitet)

Nja, also die 5 größten Blöcke sind waren bei diesem Test 1.509.504 , 192.192 , 121.664 , 35.328 und 25.088 Kilobyte.
Und da passen nur maximal 5 Blöcke mit je 256 MB rein, selbst wenn rein rechnerisch 7,62 reinpassen würden.

[tgvoelker]

Zitat:

Zitat von himitsu (Beitrag 1174488)

Nicht?

Tschuldigung, vertan. Entweder nicht richtig gelesen, oder richtig gelesen und nicht richtig durchdacht. Sei es drum, das Grundproblem bleibt bestehen: Out of Memory kommt, weil kein Segment mehr da ist, das groß genug ist, den Speicher, der allokiert werden soll, bereitzustellen.

Du, Mavarik scheinst aber ein grundlegendes Verständnisproblem bei der Windows-Speicherverwaltung zu haben.

Zunächst: der Adressbereich eines Win32-Programmes ist immer virtuell, hat also mit dem Speicher im System nix zu tun. Das ist auch unabhängig davon, ob jetzt ein x64-Windows läuft, oder ein x32-Windows.

Der physische Arbeitsspeicher, den Windows verwalten kann, ist abhängig von Hardware und Software: x64 kann den gesamten installierten Speicher verwenden, x32 ohne PAE unter 4GB, weil die Addressen für Systemquatsch weggehen, x32 mit PAE 4GB, sofern es sich um ein Clientsystem, eine Server Web Edition oder eine Server Standard Edition handelt und über 4GB, wenn es sich um eine Advanced/Enterprise oder Datacenter Edition handelt.

x32 Clientprogramme haben einen Adressraum von 32bit, wie oben beschrieben ist bei 2 bzw. 3 GB Daten trotzdem Ende. Mehr Speicher können sie dennoch ansprechen, sofern sie AWE verwenden, das wird aber eben nur auf Advanced/Enterprise/Datacenter bereitgestellt und erfordert - für den Zugriff auf mehr als 4GB physischen Speicher - zusätzlich PAE-Hardware. Funktionieren tut das ganze dann in etwa wie früher die Segmenadressen in DOS: man definiert den Start des Segmentes, in dem man dann den 32bit-Adressraum nutzt.

Der Speicher ist in Seiten eingeteilt, die unterschiedliche Größe haben. Die Windows-Speicherverwaltung macht dann das Mapping zwischen den virtuellen Adressen (die Dein Programm kennt) und dem physischen Ort des Speichers - ob der im RAM liegt, oder in einer Auslagerungsdatei, oder gar in einem Bereich, der nur mit PAE angesprochen werden kann, ist für Dich völlig transparent.

Maßgeblich für Deine Allokierung ist, ob im VIRTUELLEN Adressbereich Deines Programmes ein Block frei ist, der groß genug ist, um die Datenstruktur aufzunehmen.

GlobalMemoryStatus bezieht sich aber nicht auf den virtuellen Adressraum Deines Programmes, sondern auf den PHYSISCHEN Speicher. (Siehe http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx)

Da der virtuelle Adressraum Deines Programmes jedoch speicherseitenweise entweder im physischen Speicher oder in der Auslagerungsdatei liegt, oder garnirgendswo (wenn er nicht allokiert ist), kannst Du mit dieser Funktion nicht prüfen, ob Du eine bestimmte Menge Speicher allokieren kannst, oder nicht.

Zudem ist die Aussage nur von begrenzter Relevanz, wie himitsu richtig zeigt, sind die Größen der Segmente maßgeblich, es sei denn, Du allokierst segmentübergreifend - was bedeutet, daß Du einen weiteren virtuellen Adreßraum schaffen mußt. In dem von mir verlinkten Beispiel habe ich genau das gemacht.

[Mavarik]

Zitat:

Zitat von tgvoelker (Beitrag 1174523)

Du, Mavarik scheinst aber ein grundlegendes Verständnisproblem bei der Windows-Speicherverwaltung zu haben.

Nein eigentlich nicht... Trotzdem Danke für Dein langes Posting um mich zu belehren...
Eine Antwort auf meine Frage wäre mir lieber gewesen...

Vielleicht ist die hier etwas unter gegangen:

Wie kann ich den Restspeicher für ein dynamisches Array ermitteln? Hier wäre es wichtig auch noch einen "restspeicher" für das laufende Programm frei zu halten!


Mavarik

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1174811)

Wie kann ich den Restspeicher für ein dynamisches Array ermitteln? Hier wäre es wichtig auch noch einen "restspeicher" für das laufende Programm frei zu halten!

Da eine dynamisches array AFAIK einen durchgehenden Adressbereich benötigt stellt das für dein "Restspeicher" kein Problem dar, da ja du nur den größten Durchgehenden Adressbereich anforderst aber tausende kleinere Adressblöcke für das "Restprogramm" immer noch verfügbar sin.

[tgvoelker]

Zitat:

Zitat von Mavarik (Beitrag 1174811)

...um mich zu belehren...

Entschuldige bitte, war ein langer Tag und eine Belehrung lag nicht in meiner Absicht. Ich wollte eigentlich darlegen, warum GlobalMemoryStatus nicht geeignet ist, Dir entsprechende Informationen zu liefern.

Zitat:

Zitat von Mavarik (Beitrag 1174811)

Wie kann ich den Restspeicher für ein dynamisches Array ermitteln? Hier wäre es wichtig auch noch einen "restspeicher" für das laufende Programm frei zu halten!

Mavarik

Der verfügbare Restspeicher für ein dynamisches Array ergibt sich aus der Größe des Segments, in dem das Array angelegt wurde. Das hilft Dir nun nicht so richtig weiter, weil Du ein array of Pointer hast und für jeden Neueintrag einen Speicherbereich allokierst. Das geht solange, wie Segmente frei sind, in die die neu allokierten Speichermengen reinpassen.

Da Du 256MB-Blöcke allokierst, geht das solange, bis kein Segment mehr da ist, das 256 MB groß ist.

Den verfügbaren virtuellen Speicher kannst Du mit GlobalMemoryStatusEx ermitteln:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Das Problem der Segmentierung bleibt aber nach wie vor bestehen. Wenn Du mehr Speicher allokieren willst, als das größte Segment hat, dann kommst Du um eine Struktur, die über die Segmente eine virtuelle Adressierung legt, nicht herum. ==> TSegmentedMemoryStream.

[Mavarik]

Zitat:

Zitat von tgvoelker (Beitrag 1174891)

Da Du 256MB-Blöcke allokierst, geht das solange, bis kein Segment mehr da ist, das 256 MB groß ist.

Nein das war nur für den Test...

Ich programmiere eine Dateiverwaltung die Freelisten, Dirs, Datensegmentlisten usw. in TByteDynArray speichert, die an dauernd erzeugt, vergrößert und wieder verkleinert werden...

Unzählge Setlength Befehle nach 10 Min. Müsste der Speicher eigentlich aussehen wie Schweizer Käse...

Was ich auf keinen Fall will ist eine Out of Memmory Exception...

Daher die Frage...

[DeddyH]

Das ändert aber am Kernproblem nichts: sobald kein zusammenhängender Speicherblock in der benötigten Größe mehr frei ist, ist Schicht im Schacht, obwohl in der Gesamtheit noch genügend Speicher vorhanden wäre. Ein Schritt weg von Arrays hin zu Listen kann das Problem zumindest abmildern.

[Mavarik]

hmm..

Das würde ein komplett neues Konzept bedeutet...

Kann ich davon ausgehen, dass hintereinander liegende wieder frei gegebene Segmente wieder zu einem großen block zusammen gefasst werden?

Mavarik

[tgvoelker]

Zitat:

Zitat von Mavarik (Beitrag 1175128)

hmm..

Das würde ein komplett neues Konzept bedeutet...

Kann ich davon ausgehen, dass hintereinander liegende wieder frei gegebene Segmente wieder zu einem großen block zusammen gefasst werden?

Mavarik

Ja. Die Frage ist allerdings, ob die Maßgabe für die Freigabe von Speicher ist, ob die Speicherbereiche beieinander liegen, oder, ob Du die enthaltenen Strukturen noch brauchst.