Suche Systemtool um SWAP/PAGING zu anlysieren in Win 11

XamBonX

Captain
Registriert
Nov. 2002
Beiträge
3.138
Folgende Situation:

1775408170381.png


1775408193419.png


Es geht mir um das Commit da, das steigt schlagartig innerhalb von Minute oder so von 36GB -> 47GB. Ich suche einen Tool, das mir im Detail erlaubt zu analysieren, was im Commit / SWAP / PAGING passiert, bzw. welche Programme oder Thread oder was auch immer dies verursachen.

Ich weiß schon welches Programm das macht, ich möchte rausfinden, wo genau, bzw. was im Detail da passiert, wenn der Sprunghafter Anstieg von 36gb auf 47gb passiert.

Gibt es sowas?

Danke,
Bonxi
 

Anhänge

  • 1775408020441.png
    1775408020441.png
    17,8 KB · Aufrufe: 26
  • 1775408035430.png
    1775408035430.png
    57,7 KB · Aufrufe: 38
  • Gefällt mir
Reaktionen: KEV24in_Janßen
@XamBonX
Vermutlich geschieht da auch RAM-Komprimierung, was kurzzeitig mehr Ressourcen & Rechenzeit benötigt.
 
@Tanzmusikus Ne, ich kann den sprunghaften Anstieg ständig reproduzieren. Ich muss oder will nur wissen, was im Detail das verursacht.

Unter anderem ist da bis zu 50gb, das passiert immer innerhalb von 1-2 min. sobald ich das reproduziere. Ich suche nun nach Details WAS da passiert.
 
lass dir gesagt sein, dass die commitgröße reine virtuelle (pre-)allocation ist, das heißt, der jew. prozess lässt durch das os hier speicherbereiche zusichern, die am ende u.u. niemals genutzt werden. es ist eine anmeldung an potenziellem bedarf, der aber zugesichert wird und dann im fall des falles über ram oder behelfsmäßig swapspace realisiert wird.
commit sieht man auch nicht in rammap, da dort nur physikalische adressbereiche im fokus stehen. (abgesehen von virtuellen adressen, die tatsächlich durch ram "bedient" wurden, aber daraus ergeben sich keine rückschlüsse auf die geartetheit des vorgangs im programm)

deine möglichkeiten der sache auf den grund zu gehen in bezug auf die frage "was macht der prozess in dem moment eigtl... also warum meldet er von einer sekunde auf die andere soviel bedarf an?" wäre zunächst mal im process monitor auf den prozess zu filtern und möglichst akkurat den moment des commit-size-sprungs (gemonitored im tool deiner wahl) mit den zeitlich zugehörigen operationen im process monitor log abzugleichen.

wenn sich daraus in kombination mit deinen beobachtungen im programm selbst (also dem trigger, den du ja offenbar sicher reproduzieren kannst) keine schlüsse ziehen lassen (eher wahrscheinlich, da procmon hauptsächlich interaktion mit kernel, registry und sonstigen windowsmodulen aufzeichnet und nicht prozessinterne funktionen) bleibt dir wenig anderes übrig als einen debugger/ida/ghidra zu installieren und wesentlich tiefer einzutauchen, um beispielsweise nach dem function call zu fischen, der das verursacht.

stichwort schwarmintelligenz. vielleicht hilft es auch uns mitzuteilen um welches programm es sich handelt und bei welcher aktion deinerseits dieser sprung konkret erzeugt wird.
wenn du mir jetzt sagen würdest es passiert bei einem file-duplicate-finder genau bei absetzen eines compare-scans all deiner platten dann könnte ich mir da schon recht konkrete gründe für das verhalten denken.
oder auch wenn du in einer professionellen videoschnittsoftware ein neues projekt erstellst und bestimmte parameter zu videoformat, -länge etc. hinterlegt hast.
das wären alles situationen wo eine reservierung virtueller speicherbereiche sinn macht.
 
Zurück
Oben