In CMD.exe erstellt "start sh.exe" einen Conhost-Prozess, der 700 MB Speicher benötigt

Git bash (sh.exe) benötigt ansonsten wenig Speicher, aber wenn es mit dem start sh.exeBefehl von CMD gestartet wird , erstellt es einen conhost.exe-Prozess, der 3-700 MB Speicher benötigt.

Interessanterweise start cmd /k sh.exemacht es dasselbe, aber es erzeugt einen Conhost-Prozess, der nur 8 MB benötigt.

Warum erzeugt das Starten von sh.exe mit dem Befehl "start" einen Conhost-Prozess, der so viel mehr Speicher benötigt?

— laggingreflex
quelle

Wie messen Sie, wie viel Speicher benötigt wird? Und was meinst du mit "Erinnerung"? Meinen Sie physischen Speicher (RAM)?

— David Schwartz

@ DavidSchwartz Task-Manager zeigt ~ 300 MB, Prozess-Explorer zeigt ~ 700 MB (private Bytes)

— laggingreflex

Also kein physisches Gedächtnis. Dann ist die kurze Antwort, dass es niemanden interessiert, was dieser Wert ist. Nur der physische Speicher ist knapp, und in der Regel bemühen sich die Menschen nicht, den Verbrauch von Ressourcen zu minimieren, die nicht knapp sind.

— David Schwartz

@DavidSchwartz Ich habe die gesamte RAM-Auslastung im Ressourcenmonitor gemessen und die Spitzen und Tropfen scheinen ähnlich zu sein. Auch wenn es 10 solcher Conhosts gibt, bleibt mein Chrom für eine Weile stehen, wenn nach einiger Zeit darauf zugegriffen wird. Ich habe eine Verbesserung festgestellt, als ich vermieden habe, die Conhosts auf die in meiner Frage beschriebene Weise zu starten ( start cmd sh.exeanstelle von start sh.exe). Meine Frage ist warum der Unterschied überhaupt? Warum conhost Schwein so viel mehr Speicher (auch nur virtuell) , wenn dabei start sh.exezu tun im Vergleichstart cmd /c sh.exe

— laggingreflex

Die Antwort ist, was ich sagte - virtueller Speicher ist nicht knapp, so dass sich die Leute nicht die Mühe machen, seinen Verbrauch zu minimieren. Es ist durchaus üblich, ziemlich große Stücke zuzuweisen, nur für den Fall, dass sie später benötigt werden. Dies gilt insbesondere dann, wenn Sie einen Prozess starten, da Sie vor dem Start einige Dinge tun können, die Sie nach dem Start nicht so einfach erledigen können.

— David Schwartz

ok, ich habe mir beide Traces mit WPA.exe angesehen . In dem Trace, der die hohe Speichernutzung anzeigt, stammt die Speichernutzung aus der Erstellung des Bildschirmpuffers DoCreateScreenBuffer:

Line #, Process, Commit Stack, Address, Count, Impacting Size, Size
1, conhost.exe (10848), [Root], , 46, 800784384, 800833536
2, ,    |- ntdll.dll!RtlUserThreadStart, , 31, 800669696, 800673792
3, ,    |    kernel32.dll!BaseThreadInitThunk, , 31, 800669696, 800673792
4, ,    |    |- ConhostV2.dll!ConsoleIoThread, , 13, 800509952, 800509952
5, ,    |    |    ConhostV2.dll!ConsoleHandleConnectionRequest, , 13, 800509952, 800509952
6, ,    |    |    ConhostV2.dll!ConsoleAllocateConsole, , 13, 800509952, 800509952
7, ,    |    |    |- ConhostV2.dll!SetUpConsole, , 10, 800460800, 800460800
8, ,    |    |    |    |- ConhostV2.dll!AllocateConsole, , 7, 800432128, 800432128
9, ,    |    |    |    |    ConhostV2.dll!DoCreateScreenBuffer, , 7, 800432128, 800432128
10, ,   |    |    |    |    |- ConhostV2.dll!SCREEN_INFORMATION::CreateInstance, , 6, 800415744, 800415744
11, ,   |    |    |    |    |    ConhostV2.dll!TEXT_BUFFER_INFO::CreateInstance, , 6, 800415744, 800415744
12, ,   |    |    |    |    |    |- ConhostV2.dll!DBCS_SCREEN_BUFFER::CreateInstance, , 4, 599891968, 599891968
13, ,   |    |    |    |    |    |    ntdll.dll!RtlpAllocateHeapInternal, , 4, 599891968, 599891968
14, ,   |    |    |    |    |    |    ntdll.dll!RtlpAllocateHeap, , 4, 599891968, 599891968
15, ,   |    |    |    |    |    |    ntdll.dll!NtAllocateVirtualMemory, , 4, 599891968, 599891968
16, ,   |    |    |    |    |    |    ntoskrnl.exe!KiSystemServiceCopyEnd, , 4, 599891968, 599891968
17, ,   |    |    |    |    |    |    ntoskrnl.exe!NtAllocateVirtualMemory, , 4, 599891968, 599891968
18, ,   |    |    |    |    |    |    ntoskrnl.exe! ?? ::NNGAKEGL::`string', , 4, 599891968, 599891968

Der start cmd /k sh.exeeine macht diese Speicherbelegung nicht. Hier werden nur einige Zeichen gedruckt, die nur 69kB benötigen.

Line #, Process, Commit Stack, Address, Count, Impacting Size, Size
7, conhost.exe (10072), [Root], , 2, 81920, 81920
8, ,   ntdll.dll!RtlUserThreadStart, , 2, 81920, 81920
9, ,   kernel32.dll!BaseThreadInitThunk, , 2, 81920, 81920
10, ,   |- ConhostV2.dll!ConsoleIoThread, , 1, 69632, 69632
11, ,   |    ConhostV2.dll!SrvWriteConsole, , 1, 69632, 69632
12, ,   |    ConhostV2.dll!DoSrvWriteConsole, , 1, 69632, 69632
13, ,   |    ConhostV2.dll!DoWriteConsole, , 1, 69632, 69632
14, ,   |    ConhostV2.dll!WriteChars, , 1, 69632, 69632
15, ,   |    ConhostV2.dll!WriteCharsLegacy, , 1, 69632, 69632
16, ,   |    ConhostV2.dll!WriteRegionToScreen, , 1, 69632, 69632
17, ,   |    ConhostV2.dll!ConsolePolyTextOut, , 1, 69632, 69632
18, ,   |    ntdll.dll!RtlpAllocateHeapInternal, , 1, 69632, 69632
19, ,   |    ntdll.dll!RtlpAllocateHeap, , 1, 69632, 69632
20, ,   |    ntdll.dll!RtlpCommitBlock, , 1, 69632, 69632
21, ,   |    ntdll.dll!NtAllocateVirtualMemory, , 1, 69632, 69632
22, ,   |    ntoskrnl.exe!KiSystemServiceCopyEnd, , 1, 69632, 69632
23, ,   |    ntoskrnl.exe!NtAllocateVirtualMemory, , 1, 69632, 69632
24, ,   |    ntoskrnl.exe! ?? ::NNGAKEGL::`string', , 1, 69632, 69632
25, ,   |  , 0x2a657431000, 1, 69632, 69632

Aber ich habe keine Ahnung, warum das passiert. Führen Sie es immer mit start cmd / k aus.

— magicandre1981
quelle

Ahh! Ich hatte die Größe des Bildschirmpuffers auf 9999 eingestellt. Ich weiß nicht, warum er nur start sh.exeauf gesunde Werte angewendet , aber auf Werte gesenkt wurde, die mit weniger Speicherbedarf erstellt wurden. Verdammt! lol. Danke für die Analyse!

— Laggingreflex

Als ich mir die Spur zum ersten Mal ansah, dachte ich auch darüber nach, vergaß aber, sie hinzuzufügen. Aber schön zu hören, dass es jetzt behoben ist :)

— magicandre1981