Problem mit Memory Mapped Files

[bono_82]

Hallo,

ich muss für meine Anwendung mit sehr großen Dateien arbeiten (bis 4GB). Aus diesem Grund lade ich eine große
Datei als Memory Mapped File. Ich hab gelesen, dass das theoretisch bis 4 GB geht, aber man nur 2 GB nutzen kann, da das BS
sich die anderen 2GB reserviert. Mein Problem ist allerdings, dass ich auch schon ab einer 1 GB großen Datei Fehlermeldungen bekomme. Mit kleineren Files (ca. 100 MB) Dateien funktioniert aber prinzipiell alles prima. Hier mal der Code zum Öffnen einer Datei als MMF.
Hat jemand einen Ratschlag?

Delphi-Quellcode:

str:=VisuFilePath+VisuFileName+'.dat';

{Variante mit Memory Mapped Files}
FileHandle := GetHandle(str); //Fkt. um Handle zu erzeugen
if FileHandle = INVALID_HANDLE_VALUE then
   Raise exception.Create('File could not be opened!');
FileSize := GetFileSize(FileHandle,nil);

MapHandle := CreateFileMapping(FileHandle,nil,PAGE_READONLY,0,0,nil);
if MapHandle = 0 then begin
   CloseHandle(FileHandle);
  Raise Exception.Create('Filemapping Error!');
end;

FData := MapViewOfFile(MapHandle,FILE_MAP_READ,0,0,0);

if FData = nil then begin
   CloseHandle(MapHandle);
  Raise Exception.Create('Filemapping Error!');
end;

FData ist der Pointer auf den Beginn des Speicherbereich in dem meine Daten liegen.
Bei meiner 1 GB großen Datei wird für FData allerdings nil zurückgeliefert. Probleme sollten doch aber erst ab ca. 2GB auftreten?

Gruß,
bono

[Bernhard Geyer]

1, Deine gesamte Anwendung kann unter Win32 maximal 2 GB an speicher haben. Unter Win64 mit richtigen Memory Manager und Windows-Einstellung 3 GB

2, Ich vermute mal das die Memory Mapped Files u.U. einen zusammenhängenden Adressbereich in der Anwendung benötigen. Und wenn man so sieht wieviel DLLs gewollt oder ungewollt in einer Exe "gemappt" sind und wo ist selbst 1 GB schon ein sehr guter Wert.

[bono_82]

Danke für Deinen Tipp. Deiner Aussage nach müsste meine Anwendung dann auch schon ohne die verwendete Datei 1GB an
Adressraum "verbraten". Kann ich mir irgendwie nicht vorstellen. Ich kenn mich da allerdings auch nicht so aus.

[Bernhard Geyer]

Zitat:

Zitat von bono_82

Danke für Deinen Tipp. Deiner Aussage nach müsste meine Anwendung dann auch schon ohne die verwendete Datei 1GB an
Adressraum "verbraten". Kann ich mir irgendwie nicht vorstellen. Ich kenn mich da allerdings auch nicht so aus.

Nein.
Jedoch die geladenen DLL's liegen verstreut im Adressraum so daß es keinen zusammenhängenden 1GB-Bereich mehr gibt der vermutlich dafür benötigt wird.

[sirius]

Und warum nimmst du nicht ein TFileStream? MMFs sind ja nicht für große Dateien gedacht sondern für IPC, IMHO.

[OldGrumpy]

Wenn Du nur mit moderneren Windowsversionen arbeitest, bedient Windows Filezugriffe eh bevorzugt durch Mapping in den Filecache, memory mapped files bringen da nicht mehr die riesigen Leistungszuwächse. Dazu kommt noch dass der Gesamtspeicher des Systems ja auch eher begrenzt ist und du durch gnadenlosen Speicherhunger an anderer Stelle Performance in grossem Massstab verbrennst (erzwungenes Swapping anderer Prozesse und massive Swapfilezugriffe -> Bremse). Mit MapViewOfFile kannst Du aber z.B. auch die Größe des gemappten Bereichs angeben, so dass sich da z.B. ein Fenster von sagen wir 256 MB (je nachdem wieviel Du im File herumspringst und wieviel Speicher vorhanden ist) anbieten würde. Zugriffe aufs File bzw. dessen View musst Du dann nur durch eine Filterfunktion laufen lassen, die ggf. den View ändert wenn die angeforderte Adresse ausserhalb des momentan gemappten Bereichs liegt.

[bono_82]

Das klingt interessant. Würde ein solches "Fenster" auch für Bereiche zw. z.B. 3 und 4 GB funktionieren oder
trifft einen da irgendwie die oben erwähnte 2 GB Grenze?

@sirius:
MMF's kann man meiner Ansicht nach auch für den Umgang mit sehr großen Dateien verwenden, da die bearbeitete Datei auf der Festplatte bleibt und ich mir nur bestimmte Abschnitte in den Speicher holen möchte.
Ich hab mir auch eine TFileStream-Variante erstellt, allerdings muss ich da immer mit irgendwelchen Puffern arbeiten, die bei mir schnell sehr groß werden können. Bei MMF's arbeite ich mit Pointern.

Danke für eure Hinweise. Bin für weitere Tips aufgeschlossen!

[Robert Marquardt]

Es koennte helfen die Dokumentation der Funktionen zu lesen. Der Aufruf von MapViewOfFile(MapHandle,FILE_MAP_READ,0,0,0); bedeutet das das gesamte File in den Speicher gemappt werden soll. Es macht mehr Sinn ein kleineres Fenster zu waehlen. Dann wird auch nur Speicher fuer dieses Fenster belegt und nur ein Teil des Files gemappt. Will man auf einen anderen Teil des Files zugreifen muss man das Mapping aendern.
Idealerweise bindet man das in einer Klasse ein (ich wette da gibt es schon welche im Internet).

[alzaimar]

Was willst Du denn mit diesen riesigen Dateien anstellen? Wenn in diesen Dateien irgendwelche Daten sind, dann pack sie in eine ordendliche DB.

[DMW]

Zitat:

Zitat von Bernhard Geyer

1, Deine gesamte Anwendung kann unter Win32 maximal 2 GB an speicher haben. Unter Win64 mit richtigen Memory Manager und Windows-Einstellung 3 GB

Nein, auch unter Win32 ist es möglich, einem Programm 3 GB Speicher zuzuteilen, indem man Windows mit der Kerneloption /3GB startet und entsprechende Linkereinstellungen tätigt. Unter Win64 ist der Speicher bei den gegenwärtigen Versionen AFAIK auf 8192 GB begrenzt.

[OldGrumpy]

Allerdings ist /3GB auch nicht ganz ohne, da der Kernel dann mit der Hälfte der üblichen Speichermenge auskommen muss, es gibt Fälle in denen das dann eng wird - oder auch gar nicht mehr passt.

[Bernhard Geyer]

Zitat:

Zitat von DMW

Nein, auch unter Win32 ist es möglich, einem Programm 3 GB Speicher zuzuteilen, indem man Windows mit der Kerneloption /3GB startet und entsprechende Linkereinstellungen tätigt.

OK.

Zitat:

Zitat von DMW

Unter Win64 ist der Speicher bei den gegenwärtigen Versionen AFAIK auf 8192 GB begrenzt.

Was meinst Du damit? Delphi kann nur 32-Bit und damit nur 4 GB Adressieren oder meinst du Windows. Dort hängte es dan vom Windows-Speichermanager ab was der einem Prozess zuordnen kann/darf.

[DMW]

Zitat:

Zitat von Bernhard Geyer

Was meinst Du damit? Delphi kann nur 32-Bit und damit nur 4 GB Adressieren oder meinst du Windows. Dort hängte es dan vom Windows-Speichermanager ab was der einem Prozess zuordnen kann/darf.

Natürlich, Delphi kann, solange es keinen 64-Bit-Compiler hat, nur die unter Win32 übliche Speichermenge, also 2 bzw. 3 GB, adressieren. Das System hingegen ist in der Lage, mit bis zu 8192 GB RAM pro Applikation umzugehen - z.B. mit VC++ ist das ausnutzbar.

[Olli]

Ich bin auch fuer die "Fenster"-Variante welche von OldGrumpy und Robert erwaehnt wurde.

Zitat:

Zitat von sirius

Und warum nimmst du nicht ein TFileStream? MMFs sind ja nicht für große Dateien gedacht sondern für IPC, IMHO.

:shock:

Zitat:

Zitat von bono_82

@sirius:
MMF's kann man meiner Ansicht nach auch für den Umgang mit sehr großen Dateien verwenden, da die bearbeitete Datei auf der Festplatte bleibt und ich mir nur bestimmte Abschnitte in den Speicher holen möchte.

MMFs sind quasi die Umkehrung des Prinzips einer Auslagerungsdatei. Entsprechend landet es auch nicht automatisch im echten Speicher (sprich RAM), selbst wenn du einen View auf einen Abschnitt erstellst. Ansonsten volle Zustimmung.

Zitat:

Zitat von DMW

Nein, auch unter Win32 ist es möglich, einem Programm 3 GB Speicher zuzuteilen, indem man Windows mit der Kerneloption /3GB startet und entsprechende Linkereinstellungen tätigt.

Strikt gesagt ist das eine Windows NT Option.

Zitat:

Zitat von DMW

Unter Win64 ist der Speicher bei den gegenwärtigen Versionen AFAIK auf 8192 GB begrenzt.

... woher sind die Zahlen? Habe da etwas leicht anderes sowohl bzgl. der aktuellen Implementationen der CPU (also Hardware) als auch der Implementation von Windows (also Software) gehoert. Soweit ich mich entsinne war die Rede von 16TB Gesamtadressraum wovon "nur" um die 128GB fuer den Kernel reserviert waren und der Rest fuer Userspace (oder umgekehrt?!). Jedenfalls kommt das nicht mit deinen Zahlen zusammen.

[DMW]

Zitat:

Zitat von Olli

... woher sind die Zahlen? Habe da etwas leicht anderes sowohl bzgl. der aktuellen Implementationen der CPU (also Hardware) als auch der Implementation von Windows (also Software) gehoert. Soweit ich mich entsinne war die Rede von 16TB Gesamtadressraum wovon "nur" um die 128GB fuer den Kernel reserviert waren und der Rest fuer Userspace (oder umgekehrt?!). Jedenfalls kommt das nicht mit deinen Zahlen zusammen.

Von der CPU her geht natürlich deutlich mehr (2^64 = 17179869184 GB). Der Speicher, den Windows einem Prozeß maximal zuteilen kann, liegt aber bei 8192 GB (zzgl. die von dir erwähnten 128 GB je für Kernel, Systemcache, ausgelagerten und nicht ausgelagerten Pool). Die Zahlen habe ich aus "Windows Internals" von Mark Russinovich und David Solomon entnommen.

[Olli]

Zitat:

Zitat von DMW

Von der CPU her geht natürlich deutlich mehr (2^64 = 17179869184 GB). Der Speicher, den Windows einem Prozeß maximal zuteilen kann, liegt aber bei 8192 GB (zzgl. die von dir erwähnten 128 GB je für Kernel, Systemcache, ausgelagerten und nicht ausgelagerten Pool). Die Zahlen habe ich aus "Windows Internals" von Mark Russinovich und David Solomon entnommen.

Alles klar. So macht das Sinn. Effektiv sind es dann naemlich wieder 16TB (oder TiB), weil ja zumindest nominell eine Haelfte dem UM und eine dem KM gehoert. Mir fiel uebrigens ein, dass sich meine damaligen Infos (noch in 2005) auf die x64-Versionen von XP und 2003 (im Kernel eh identisch) bezogen. Aber bei Vista duerfte sich da nichts wesentliches geaendert haben.

NonPagedPool hoert sich doch viel besser an als die deutsche Variante, findest du nicht? :zwinker:

[DMW]

Zitat:

Zitat von Olli

Effektiv sind es dann naemlich wieder 16TB (oder TiB), weil ja zumindest nominell eine Haelfte dem UM und eine dem KM gehoert.

Das ist laut Windows Internals allerdings nur bei den 32-Bit-Versionen so; in den 64-Bit-Versionen gelten für die Kernel-Mode-Adreßräume die von mir oben genannten Zahlen (in der IA-64-Version hat der User-Mode-Adreßraum allerdings nur 7152 GB).

Zitat:

Zitat von Olli

NonPagedPool hoert sich doch viel besser an als die deutsche Variante, findest du nicht? :zwinker:

Vielleicht, aber insgesamt ist das Buch IMHO trotzdem hervorragend übersetzt ;)

[Olli]

Zitat:

Zitat von DMW

Zitat:

Zitat von Olli

Effektiv sind es dann naemlich wieder 16TB (oder TiB), weil ja zumindest nominell eine Haelfte dem UM und eine dem KM gehoert.

Das ist laut Windows Internals allerdings nur bei den 32-Bit-Versionen so; in den 64-Bit-Versionen gelten für die Kernel-Mode-Adreßräume die von mir oben genannten Zahlen (in der IA-64-Version hat der User-Mode-Adreßraum allerdings nur 7152 GB).

:shock: 16 Tebibyte mit 32bit? Glaub ick net! :mrgreen:

Zitat:

Zitat von DMW

Zitat:

Zitat von Olli

NonPagedPool hoert sich doch viel besser an als die deutsche Variante, findest du nicht? :zwinker:

Vielleicht, aber insgesamt ist das Buch IMHO trotzdem hervorragend übersetzt ;)

K.A., ich besitze noch irgendwo die Ausgabe welche fuer Windows 2000 aktuell war. Aber irgendwie war mir die damals zu oberflaechlich, weshalb ich keine neue Ausgabe gekauft habe.

[DMW]

Zitat:

Zitat von Olli

:shock: 16 Tebibyte mit 32bit? Glaub ick net! :mrgreen:

Das

Zitat:

Zitat von DMW

Das ist laut Windows Internals allerdings nur bei den 32-Bit-Versionen so

bezog sich auf die Zweiteilung des Adreßraumes. Sorry für die Mißverständlichkeit ;)

Zitat:

Zitat von Olli

K.A., ich besitze noch irgendwo die Ausgabe welche fuer Windows 2000 aktuell war. Aber irgendwie war mir die damals zu oberflaechlich, weshalb ich keine neue Ausgabe gekauft habe.

Die Edition für Windows 2000 kenne ich nicht, aber allem, was ich gelesen habe, zufolge, war damals die Übersetzung deutlich schlechter. Und über die in der aktuellen Edition kann ich mich wirklich nicht beklagen :thumb:

[Olli]

Zitat:

Zitat von DMW

Zitat:

Zitat von Olli

K.A., ich besitze noch irgendwo die Ausgabe welche fuer Windows 2000 aktuell war. Aber irgendwie war mir die damals zu oberflaechlich, weshalb ich keine neue Ausgabe gekauft habe.

Die Edition für Windows 2000 kenne ich nicht, aber allem, was ich gelesen habe, zufolge, war damals die Übersetzung deutlich schlechter. Und über die in der aktuellen Edition kann ich mich wirklich nicht beklagen :thumb:

Wuerde mir ohnehin dann gleich die englische Ausgabe kaufen. Ich selber habe kein Problem die zu lesen und meine Kollegen haetten dann auch noch was davon.