Freier Speicher in Delphiprogrammen ermitteln?

[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.