Fehler: Für diesen Befehl ist nicht genügend Speicher verfügbar.

[Michaell]

Zitat:

Zitat von bra (Beitrag 1396045)

Es geht ja nicht darum, wieviel Speicher insgesamt zur Verfügung steht, sondern wieviel Speicher an einem Stück zur Verfügung steht. Wenn du zwar 2 Gb frei hast, aber alle 20 MB mal ein paar Byte stehen, bekommst du nie 300 MB am Stück unter. Da kannst du dich drehen und wenden soviel du willst. ...

Geht es noch, ja? Die Theorie mit dem fragmentierten Speicher kann hier gern so oft wiederholt werden bis sie richtig ist (das ich die verstanden habe geht aus meinen anderen Antworten hervor). Wenn ich trotz des angeblich ach so "riesigen Bitmaps (ca. 300 MiB war die letzte Abschätzung)" nur insgesamt 300 MiB belege (natürlich mit dem Bitmap) dann brauche ich wohl kaum ein weiteres zusammenhängendes 300 MiB Stück (für das Bitmap).

[himitsu]

Du hast es wohl doch nicht ganz verstanden.
Und warum der angezeigte Speicher eventuell weniger anzeigt, als der [S]belegte[/A] reservierte Speicher wurde auch schon genannt.

Na egal, du bist der Meinung es geht jetzt, aber komm bitte nicht in einem halben Jahr wieder, wenn es erneut knallt. (oder lies dir dann wenigstens nochmal alles durch und beachte dann das Gesagte)
Ich bin nun hier raus. :hi:

[KodeZwerg]

Also hier schreibt MSDN das was ich als Beispiel Code zu verdeutlichen versuchte.

Zitat:

The working set of a process is the set of memory pages in the virtual address space of the process that are currently resident in physical memory. These pages are available for an application to use without triggering a page fault.

[Zacherl]

Wenn trockene Werte es nicht schaffen dich zu überzeugen, hilft es vielleicht eine grafische Darstellung? Mit VMMap kannst du dir den virtuellen Speicher deines Prozesses anzeigen lassen und auch z.b. explizit nach freien Speicherblöcken filtern:

Hier sieht man unter anderem schön, dass die meisten Blöcke (alle bis auf einen) zu klein wären, um dein 300MiB Bitmap an einem Stück zu beinhalten:
Anhang 48655

[KodeZwerg]

Ich bin schrecklich im Erklären, ich wollte darauf hinaus, mit diesem "working set", reserviert man sich virtuell Speicher, ob der physisch aus einem oder einer milliarde blöcken besteht ist damit hinfällig, wenn ich dein diagramm als beispiel nehme, könnte mein programm sich alle freien blöcke dazwischen zu eigen machen, virtuell hingegen ist es ein block. War das Verständlich genug formuliert, dafür gibt es doch diese funktion ?!

[himitsu]

Ich glaub du hast die Dokumentation falsch verstanden.

Beide Parameter auf $FFFFFFFF aka MAX-1 ist nicht MAXIMAL, sondern es ist NICHTS.

[KodeZwerg]

Die Größen (und Anwendung an sich) müssen natürlich an die Bedürfnisse angepasst werden, das ist nur der Rohbau meines Tests um diese Funktion hier vorzustellen, auch wenn viele sagen "Nein falsch, idiotisch usw.", ich vertrau da mal Microsoft.

[himitsu]

Aber wie schon mehrmals erwähnt wurde, hat das WorkingSet (der physische RAM) keinen Einfluß auf die Belegung/Fragmentierung des virtuellen Speichers.

PS: Wenn jede Anwendung wahllos sich mehr physischen Speicher erzwingt, dann haben schnell alle anderen Programme und vor allem die Systemkomponenten schnell ein Problem und Windows raucht dir ab :zwinker:

[KodeZwerg]

Also ich interpretiere das Working Set so:
Windows reserviert sich virtuellen Speicher für deine Anwendung.
Das ist ein block der eben eine Paging Fault (im physischem RAM) verhindern soll,
dieser block kann aus physischem oder ausgelagertem Speicher bestehen,
in beiden Fällen kann auch der virtuelle aus vielen physischen blöcken bestehen,
so kann man auch mehr Speicher anfordern als physisch überhaupt verbaut/noch frei ist,
die Ausführungsgeschwindigkeit ist dann natürlich lächerlich.
Ich hab Versucht jeden Aspekt in eine Zeile zu schreiben, in welcher irre ich mich?

[Zacherl]

Ne, also das Working Set ist tatsächlich der (virtuelle) Speicher, der NICHT ausgelagert ist, also bei einem Zugriff kein Page Fault verursachen würde:

Zitat:

Zitat von MSDN

The working set of a process is the set of pages in the virtual address space of the process that are currently resident in physical memory

Siehe auch:
https://msdn.microsoft.com/de-de/lib...or=-2147217396

[KodeZwerg]

Hier ist ein komplettes C++ Beispiel-Programm dass auch das Speicherproblem betreffen/lösen könnte. Link-Quelle ist MSDN.

[Zacherl]

Zitat:

Zitat von KodeZwerg (Beitrag 1396161)

Hier ist ein komplettes C++ Beispiel-Programm dass auch das Speicherproblem betreffen/lösen könnte. Link-Quelle ist MSDN.

AWE löst das Problem leider ebenfalls nicht :P Damit kannst du zwar große Mengen physikalischen Speicher verwalten, aber dieser muss trotzdem in den virtuellen Adressbereich gemappt werden. Ist in Letzterem halt kein zusammenhängender Block in der entsprechenden Größe mehr frei, scheitert auch das.

[KodeZwerg]

So ein Mist, ich hatte gehofft das man wenigstens über AWE (was ja das 2 GB limit sprengen kann) einen 300 MB block hinbekommt der keine Paging Fault verursacht.
Das Working Set auch nicht funktioniert kann ich auch noch nicht nachvollziehen aber ich halte mich jetzt da mal raus.
Mehr kann ich zu diesem Thema momentan nicht Beitragen.

[himitsu]

Warum hört niemand zu?


WorkingSet ist nur die nicht auslagerbare Menge, aber an der Gesamtmenge und der Verteilung ändert es rein garnichts.
Alternativ kann man auch direkt physischen Speicher reserveren und einbinden ... das macht keinen großen Unterschied. (hier sagt man nur "ich will genau diesen Speicherblock nie auslagen", während das WorkingSet sagt "ich will minimal/maximal einen so großen Anteil meines gesamten Virtuellen nie auslagern")

Auch andere Speicher-Erweterungen, wie AWE oder MMF, können zwar "zusätzlichen" Speicher reservieren, was nur "indirekt" mit der Belegung/Verteilung des virtuellen Speichers zu tun hat.
(der Speicher ist extern reserviert/belegt und muß nicht im Virtuellen eingebunden sein, aber wenn man ihn benutzen will, dann muß er ebenfalls da rein und schon ist das Problem wieder da)



Die einzige Lösung ist eine Defragmentierung des virtuellen Speichers.
Aber das ist nicht so einfach, da man dafür alle Referenzen auf die zu verschiebenen Blöcke kennen muß (wo es aber niemals 100% sicher eine komplette Liste geben wird) um die Zeiger anschließend mit anpassen zu können.
Oder man macht es wie die beim OutOfMemory. Dort wird gleich zu Programmstart ein kleiner Speicher "reserviert" (virtueller Bereich belegen, aber nicht mit physischem Speicher verbinden) und der wird vor Anzeige der Fehlermeldung freigegeben, dann der Speicher ist ja "voll", aber der Dialog braucht dennoch welchen, also hält man sich eine Lücke für den Notfall frei.

Letzteres (OutOfMemory) entspricht in etwa dem, was hier mit dem "ich mache das Bitmap vor den restlichen Fenstern" gemacht wird, außer dass hier kein "großer" Block reserviert wird, für den praktisch immer genügend Speicher verfügbar ist. und in dem praktisch niemals existierenden Fall, wo der Speicher nicht doch ausreicht, dann wäre das komplette Programm sowieso nicht lauffähig.

[Zacherl]

Zitat:

Zitat von himitsu (Beitrag 1396173)

Die einzige Lösung ist eine Defragmentierung des virtuellen Speichers.

Oder - wie bereits in Post #9 vorgeschlagen - einfach den umgekehrten Weg gehen und das Bitmap fragmentieren / in mehrere Teil-Bitmaps splitten.

Naja, ich klinke mich an dieser Stelle auch mal aus, der TE scheint ja sowieso seinen eigenen Weg gehen zu wollen :stupid: