Das Ausführen von Git-Befehlen unter Debian und Ubuntu auf WSL ist für große Projekte sehr langsam
Lesezeit: 6 Minuten
Wir haben ein sehr großes Projekt mit insgesamt fast 15.000 Commits. Ich betreibe Debian 9.3 auf meinem Windows-Rechner mit WSL. Meine Git-Version ist 2.17.0.
Wenn ich Befehle ausführe, wie z git status, dauert es mindestens 20 Sekunden, bis er abgeschlossen ist. Auch wenn keine Änderungen vorgenommen wurden.
Ich habe mehrere ältere Versionen von Git und sogar Ubuntu ausprobiert, aber ich erlebe immer noch das gleiche Ergebnis. Ich habe versucht, eine Reihe von Befehlen von verschiedenen Posts hier und auf anderen Websites auszuführen, aber keiner von ihnen hat funktioniert.
Lustige Sache: Wenn ich mich öffne cmd.exe oder Git Bash unter Windows, die Ausführung dauert weniger als eine Sekunde git status.
Was könnte dies verursachen? Was kann ich tun, um das zu beheben?
Hast du es versucht git gc und dann git status
– nbari
18. Mai 2018 um 8:04 Uhr
@nbari Ja und es ist genauso langsam.
– Morten Moulder
18. Mai 2018 um 8:35 Uhr
Was ist die Ausgabe, wenn which git?
– Tarun Lalwani
18. Mai 2018 um 9:01 Uhr
@TarunLalwani /usr/bin/git
– Morten Moulder
18. Mai 2018 um 11:43 Uhr
15000 Commits sollten das Zeug nicht verlangsamen, es sei denn vielleicht, wenn die festgeschriebenen Dateien wirklich groß sind, wie Photoshop-Projekte oder Bilder oder dergleichen. Auf diese Weise eingeführt, klingt es jedoch eher nach einem Timeout-Problem als nach einem Git-Verhalten. Haben Sie Ihre CPU-Auslastung überprüft, während Sie den Befehl ausführen?
– Obsidian
20. Mai 2018 um 15:31 Uhr
VonC
Aktualisierung Juni 2019: WSL 2 kommt, und damit eine vollständige Kompatibilität mit Systemaufrufen.
Das sollte die Git-Befehlsleistung erheblich steigern!
Ursprüngliche Antwort 2018:
Git funktioniert am besten, wenn es auf einem Host ohne Zwischenschicht ausgeführt wird.
Wenn sich Ihr Repo beispielsweise in einem freigegebenen Ordner befindet, wäre Git erheblich langsamer.
Im Fall von WSL wird lokal auf das Repo zugegriffen, aber durch durch a Dateisystemübersetzung zwischen verschiedenen Linux-Dateisystemoperationen in NT-Kerneloperationen.
Das würde ausreichen, um die verschlechterte Leistung zu erklären, insbesondere bei großen Git-Repositories $PATH verweist nicht auf Ordner mit ausführbaren Windows-Dateien, die anstelle der Linux-Ordner aufgerufen werden könnten
Shell-Eingabeaufforderung: Stellen Sie sicher, dass Sie Ihren Befehl in einer einfachen Shell-Eingabeaufforderung ohne Komplexe testen PS1 Berechnung
Windows Defender AV: Versuchen Sie, das WSL-verwaltete Dateisystem (zu Testzwecken) vom AV-Scan auszuschließen.
Sie sagen also im Wesentlichen, dass ich Git nicht über WSL verwenden kann? Und nein, git stört meine ausführbare Windows-Datei nicht. Es befindet sich auf meiner lokalen Festplatte, bei der es sich um eine Samsung 960 EVO mit 500 GB handelt, also sollte es ziemlich schnell sein. Wohlgemerkt, meine anderen Projekte mit ein paar hundert Commits und Dateien sind wirklich schnell.
– Morten Moulder
22. Mai 2018 um 6:29 Uhr
@MortenMoulder Ja, Git ist bei Verwendung über eine beliebige Schicht (Netzwerkschicht oder hier Übersetzungsschicht) langsamer als bei Verwendung auf Bare Metal (hier Git für Windows als git.exe direkt in einer CMD).
– VonC
22. Mai 2018 um 6:41 Uhr
Irgendeine Ahnung, warum es so langsam ist? Ich weiß, dass die Kommunikation mit dem NT-Kernel langsamer ist als die direkte Kommunikation mit dem NT-Kernel (vom NT-Kernel), aber ich finde es schwer zu glauben, dass es 25-35-mal langsamer ist (vorausgesetzt git.exe status ist 1 Sekunde).
@MortenMoulder Kein Problem. Ich werde das in meiner Antwort für andere hinterlassen, die es könnten nicht habe den Windows Defender deaktiviert.
– VonC
22. Mai 2018 um 8:07 Uhr
Am Ende fügte ich einen Hack hinzu.
alias git=git.exe
Jetzt wird die ausführbare Windows-Git-Datei in WSL mit WSL-Konfigurations-/SSH-Einstellungen ausgeführt.
Danke vielmals! Das ist genau das, wonach ich gesucht habe
– Berm
20. August 2021 um 18:47 Uhr
Das ist toll! Machte einen bemerkenswerten Unterschied.
– die schwarze Perle
15. September 2021 um 22:22 Uhr
Das ist ähnlich wie ich es getan habe. ich habe das gefunden Artikel das schlägt eine Funktion vor, um den plattformspezifischen Befehl basierend auf dem auszuführen pwd. Ich habe diese Funktion einfach am Ende meiner hinzugefügt .bashrc Datei. Hinweis: Es scheint die which Der Befehl lügt jedoch über die tatsächlich verwendete ausführbare Datei.
– Chiramisu
4. März um 1:18
Sie können einige Profiling-Details haben, indem Sie die verwenden GIT_TRACE_PERFORMANCE Umgebungsvariable:
Hilft mir besonders bei meinem oh-my-zsh in WSL 2, das nach jedem Befehl “git status” ausführt.
Auch das Deaktivieren von Defender wie oben erwähnt hilft ein wenig.
In meiner WSL mit Ubuntu erlebe ich, dass der ERSTE “git status”-Befehl viel langsamer ist als der zweite. Wahrscheinlich wird bei der ersten Ausführung Caching oder Indizierung durchgeführt. Die zweite Geschwindigkeit “git status” ist für mich in Ordnung.
Jesus Iniesta
WSL2
WSL ist in der Tat eine lustige Sache.git Die Geschwindigkeit in WSL hängt stark vom Dateisystem ab, in dem die Dateien gelesen/geschrieben werden.
Lösung:
Stellen Sie sicher, dass Sie verwenden git oder git.exe abhängig vom Dateisystempfad.
Fügen Sie das folgende Snippet am Ende von hinzu ~/.bashrc (für Bash, ZSH und Freunde).
function git() {
if $(pwd -P | grep -q "^\/mnt\/c\/*"); then
git.exe "$@"
else
command git "$@"
fi
}
Wenn Sie verwenden fishkönnen Sie das folgende Snippet verwenden:
function git --wraps git
if pwd -P | grep -q "^\/mnt\/c\/*"
git.exe $argv
else
command git $argv
end
end
In meinem Fall habe ich, obwohl ich am Dateisystem von WSL gearbeitet habe, die benutzerdefinierte Datei verwendet git Befehl hat das Problem behoben, sieht so aus, als gäbe es noch eine Chance für git um einige Arbeiten außerhalb des WSL-Dateisystems zu erledigen.
Dank an Christoph Grabo (asaaki), der diese Lösung ursprünglich gepostet hat hier.
weberjn
rannte
time git clone https://github.com/git/git.git
und
time git clone git git.1
auf Thinkpad T460s in aktueller WSL, MSYS2 und virtualboxed Fedora 28 (keine GUI, Putty).
Reale Zeiten für den lokalen Klon waren
Fedora 3s, WSL 67s, MSYS2 65s
Nach dem Ausschalten des Defenders gehen die Zeiten nach unten
WSL 11s, MSYS2 13s
So
VirtualBoxed Fedora ohne GUI ist am schnellsten
Verteidiger ist teuer. Schließen Sie Ihr Git-Working-Root aus.
keinen praktischen Unterschied gefunden, wenn das WSL-Git-Arbeitsverzeichnis unter ~ oder /c/mnt war
Gerne können Sie den kleinen Test wiederholen.
Windows Defender ist bei mir deaktiviert 🙂
– Morten Moulder
6. Juni 2018 um 6:19 Uhr
12048700cookie-checkDas Ausführen von Git-Befehlen unter Debian und Ubuntu auf WSL ist für große Projekte sehr langsamyes
Hast du es versucht
git gc
und danngit status
– nbari
18. Mai 2018 um 8:04 Uhr
@nbari Ja und es ist genauso langsam.
– Morten Moulder
18. Mai 2018 um 8:35 Uhr
Was ist die Ausgabe, wenn
which git
?– Tarun Lalwani
18. Mai 2018 um 9:01 Uhr
@TarunLalwani
/usr/bin/git
– Morten Moulder
18. Mai 2018 um 11:43 Uhr
15000 Commits sollten das Zeug nicht verlangsamen, es sei denn vielleicht, wenn die festgeschriebenen Dateien wirklich groß sind, wie Photoshop-Projekte oder Bilder oder dergleichen. Auf diese Weise eingeführt, klingt es jedoch eher nach einem Timeout-Problem als nach einem Git-Verhalten. Haben Sie Ihre CPU-Auslastung überprüft, während Sie den Befehl ausführen?
– Obsidian
20. Mai 2018 um 15:31 Uhr