Git sh.exe Prozess Forking Problem auf Windows XP, langsam?

Wenn ein Programm 30 Sekunden benötigt, um etwas sofort zu tun, ist es wahrscheinlich eher ein I / O-Timeout-Problem, normalerweise ein Netzwerk, als die Geschwindigkeit Ihrer CPU oder die Menge an RAM, die Sie haben. Sie mögen sich fragen, wie das Netzwerk ist, aber das ist eine berechtigte Frage (ich würde auch nicht für Ihr System wissen).

Msysgit installiert eine spezielle Eingabeaufforderung, die eine spezielle Funktion __git_ps1 ausführt, die einige nützliche Informationen in der Eingabeaufforderung anzeigt. Sie können dies mit echo $PS1 sehen, für mein System zeigt dies:

Diese zusätzlichen Informationen sind völlig optional und Sie können sie ausschalten. Versuchen Sie Folgendes in einem Msysgit-Fenster:

Dadurch wird die Eingabeaufforderung auf den Standard $ zurückgesetzt und nicht versucht, Befehle in der Eingabeaufforderung auszuführen. Wenn dies Ihr Verzögerungsproblem löst, ist es wahrscheinlich die Funktion __git_ps1 . Versuchen Sie es manuell:

und sehen, wie lange es dauert, um zurückzukehren.

Sie können das beheben, indem Sie die Zeile entfernen, die __git_ps1 von C:\Program Files\Git\etc\profile aufruft:

Wir sind also auch auf dieses Problem gestoßen, und ich denke, wir haben es schließlich auf die Implementierung des Windows-Sicherheitsmodells von msys zurückgeführt. Ich werde versuchen, eine kurze Zusammenfassung des Problems zu veröffentlichen:

Screenshot: Stack-Spur von stecken sh.exe. Beachten Sie, wenn msys-1.0.dll in NetServerEnum ()

Dies ist, was passiert, wenn sh.exe für 30 Sekunden blockiert ist. So wird NetServerEnum() nur an einem Ort in msys aufgerufen, security.cc:228 in get_lsa_srv_inf() , welches von get_logon_server() und get_logon_server_and_user_domain() aufgerufen wird, welches in create_token() aufgerufen wird, welches von seteuid() in syscalls.cc aufgerufen wird wird von setuid() aufgerufen.

Was im Wesentlichen passiert, ist Folgendes: Wenn die msys-DLL initialisiert wird und sh.exe versucht, setuid() aufzurufen, versucht msys, sich an das Windows-Sicherheitsmodell zu halten und versucht, die Liste der Domänenserver von Ihrer Domäne zu suchen. Arbeitsgruppe. Leider ist dies im Gegensatz zu Linux ein blockierender Aufruf für Windows, der 5-30 Sekunden dauert, bis er abgeschlossen ist / Timeout ist, und ist eigentlich ziemlich unnötig für gut, git.

Unsere Lösung besteht darin, eine neue msys.dll zu erstellen, bei der das Sicherheitsfeature deaktiviert ist, indem Sie has_security in winsup.cc auf false gesetzt. Die mit msysgit gelieferte bash / sh.exe war nicht kompatibel mit unserer neuen Version von msys.dll, also mussten wir eine neue bash.exe von Grund auf neu kompilieren, keine Ahnung warum. Das Endergebnis war sh.exe nicht mehr versucht, diese NetServerEnum Aufrufe und führt Lickity Split.

Wenn die Verlangsamung beim Ausführen mehrerer simultaner Git-Befehle auftritt, kann dies auf ein Kernel-Locking-Problem in msysgit

Wir haben gesehen, dass unter einigen Bedingungen mehrere Instanzen von git.exe alle auf dasselbe Kernel-Objekt warten (innerhalb WaitForSingleObject() ), was bedeutet, dass nur ein einzelner git-Befehl gleichzeitig auf dem System ausgeführt werden kann.

Siehe hier:

Mit ProcessExplorer konnten wir sehen, dass alle git.exe-Prozesse hier stecken geblieben sind:

Dies scheint mit diesem Problem zu tun zu haben: Ссылка , da es nicht Git ist aber die Pseudo-Linux-Laufzeit (Mingw), die das Problem zu enthalten scheint.

Wir haben das Benutzerkonto, mit dem die Anwendungen von SYSTEM ausgeführt werden, in ein interaktives Benutzerkonto geändert, und das Warten auf das Kernel-Objekt wurde abgebrochen:

Gesunde git.exe-Prozesse

Daher könnte die Verlangsamung, die Sie sehen, mit einer Art von Kernel-Objektkonflikten zusammenhängen - nur wenn der vorherige git-Befehl die Kernelsperre freigegeben hat, könnten andere Befehle ausgeführt werden können.

Versuchen Sie, das Benutzerkonto zu ändern, unter dem Sie die Git-Befehle ausführen, und sehen Sie, ob dies das Problem löst - für uns.

Obwohl Gregs Antwort das Problem der unmittelbaren Geschwindigkeit löst, habe ich das Gefühl, dass es nur das Problem maskiert und nicht löst.

Ich fing an, git bash langsam laufen zu lassen und den Schritten zu folgen, die Greg beschreibt, identifizierte __git_ps1 als den Täter.

Anstatt die Eingabeaufforderungsinformationen zu ändern (ich finde es nützlich, die angezeigten Informationen zu haben), fand ich eine Lösung, die für mich funktionierte und in einem Blogpost beschrieben wurde:

Lösung, um Git Bash zu verlangsamen, wenn Sie als Domänenbenutzer angemeldet sind

  

Ich habe im Internet ein wenig gesucht und festgestellt, dass git das Standard-Home verwendet.   auf meinem Konto als Netzwerkkonto festgelegt. Dieses Ding, dass git würde   schaue in diesem Verzeichnis die ganze Zeit und verursache die Verzögerung.

     

Um das zu beheben, habe ich eine lokale Benutzerumgebungsvariable erstellt, die überschrieben wird   der Standardwert ist und auf% USERPROFILE% festgelegt, der auf zeigt   c: \ Benutzer [Benutzername].

Die gleiche Lösung wurde auch auf SO zur Beantwortung einer ähnlichen Frage veröffentlicht.

Das Hinzufügen der Umgebungsvariablen brachte git auf volle Geschwindigkeit zurück und ich bekomme immer noch die Befehlszeileninformationen.

Ich hatte Probleme mit langsamen Prozessen auf einem Windows XP-Rechner. Gelegentlich würde eine Prozessgabel Minuten dauern.

Die Lösung für mich war, den TEMP-Ordner des Computers zu leeren. Der Computer war eine gemeinsam genutzte Ressource und es wurden über Jahre hinweg Dateien gesammelt.

Wenn die Anmeldeserver in NetServerEnum aufgelistet werden, versuchen Sie, die LOGONSERVER-Umgebungsvariable auf den tatsächlichen Anmeldeserver zu setzen.