VS Code Dev Container IO zu hoch: executeInWSL-Konfiguration erklärt und Ursachenanalyse

Bei der Verwendung der Dev Container-Erweiterung von VS Code für die containerbasierte Entwicklung unter Windows stoßen einige Benutzer auf deutliche Systemverzögerungen. Im Task-Manager ist zu sehen, dass der CPU- und Festplatten-IO des Extension Host-Prozesses kontinuierlich erhöht ist und auch ohne aktive Bedienung nicht zurückgeht. Dieser Artikel dokumentiert den vollständigen Untersuchungsprozess vom Auftreten des Problems über die schrittweise Lokalisierung der Ursache bis zur Findung der Kernlösung.

Problemphänomen

Die Systemverzögerung tritt auf, nachdem die Dev Container-Erweiterung eine Verbindung zum Container hergestellt hat. Im Task-Manager ist zu sehen, dass die Festplatten-Les-IO und CPU-Auslastung des Extension Host-Prozesses kontinuierlich erhöht sind, und diese Metriken fallen auch dann nicht auf den Leerlaufpegel zurück, wenn der Benutzer keine Bearbeitungs- oder Terminaloperationen durchführt. In extremen Fällen wird die Reaktionsgeschwindigkeit des gesamten Windows-Desktops beeinträchtigt, und der Mauszeiger zeigt intermittierende Verzögerungen.

Untersuchungsprozess

IO-Quelle mit Process Monitor lokalisieren

Sysinternals Process Monitor ist das erste Werkzeug für die Untersuchung solcher Probleme. Nach dem Start von procmon können Sie den Filter auf Process Name is Code.exe oder Process Name is Extension Host setzen, um alle ReadFile/WriteFile-Operationen in Echtzeit zu beobachten. In den Filterergebnissen treten Named-Pipe-Operationen mit Pfaden, die mit \\pipe\ beginnen, mit anomal hoher Frequenz auf, bis zu dutzende Male pro Sekunde. Diese Named-Pipe-Operationen entsprechen der Kommunikation zwischen Docker CLI und Docker daemon und zeigen, dass der Extension Host Docker CLI häufig aufruft.

Mit VS Code-internen Werkzeugen bestätigen

Über Help > Toggle Developer Tools können Sie die Chromium DevTools öffnen. Im Performance-Panel können Sie ein CPU-Profil aufnehmen und sehen, dass der Extension Host viel Zeit für das Spawnen von Unterprozessen und das Lesen von stdout-Pipes verbraucht. Wenn Sie im Output-Panel den Protokolliergrad “Dev Containers” auf “trace” setzen, sehen Sie die vollständige Befehlsaufrufsequenz: docker inspect --type container, docker version --format, docker exec, docker ps und andere Befehle werden wiederholt ausgeführt. Aus den Protokolldaten von issue #9194 kann der Overhead eines einzelnen Aufrufs quantifiziert werden: docker inspect --type container dauert etwa 1800ms, docker version etwa 620ms.

System-IO mit Windows Performance Analyzer analysieren

Für eine tiefere Analyse starten Sie die ETW-Aufzeichnung mit wpr.exe -start GeneralProfile -filemode, reproduzieren das Problem und stoppen die Aufzeichnung mit wpr.exe -stop capture.etl. Laden Sie die Ergebnisse im Windows Performance Analyzer. Die Disk-I/O-Ansicht bestätigt, dass der Extension Host der Hauptbeitragende zur Festplatten-Les-IO ist. Die Process Life Cycle-Ansicht zeigt eine große Anzahl kurzlebiger Unterprozesse, die wiederholt erstellt und zerstört werden. Diese Unterprozesse sind genau die Docker CLI-Aufrufinstanzen.

Ursachenanalyse

Prozesskommunikationsarchitektur von Dev Container

Die Untersuchungsergebnisse weisen auf die Multi-Prozess-Kommunikationsarchitektur von Dev Container hin. Wenn ein Benutzer unter Windows über die Dev Container-Erweiterung einen Container-Arbeitsbereich öffnet, wird tatsächlich eine mehrstufige Kommunikationsverbindung gestartet, die die Grenzen zwischen Windows und Linux überschreitet.

flowchart LR
    subgraph Windows["Windows-Host"]
        A["VS Code Client<br/>(Electron)"]
        B["Extension Host<br/>(Node.js)"]
        C["Docker CLI<br/>(Unterprozess)"]
    end

    subgraph WSL2["WSL2 / Docker Desktop"]
        D["Docker Daemon<br/>(dockerd)"]
    end

    subgraph Container["Innerhalb des Containers"]
        E["VS Code Server"]
        F["Remote Extension Host"]
        G["Port-Forwarding-Prozess<br/>(Node.js)"]
    end

    A e1@--> B
    B e2@--> C
    C e3@--> D
    B e4@--> E
    E e5@--> F
    F e6@--> G

    classDef win fill:#E3F2FD,stroke:#1565C0,stroke-width:1px,color:#0D47A1;
    classDef wsl fill:#FFF8E1,stroke:#EF6C00,stroke-width:1px,color:#E65100;
    classDef ctr fill:#E8F5E9,stroke:#2E7D32,stroke-width:1px,color:#1B5E20;
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9\,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;
    class A,B,C win;
    class D wsl;
    class E,F,G ctr;
    class e1,e2,e3,e4,e5,e6 animate;

Der lokale VS Code-Client (Electron) kommuniziert über IPC mit dem lokalen Extension Host (Node.js). Der Extension Host muss eine Verbindung zum VS Code Server im Container herstellen, und diese Verbindung hängt von Docker CLI als Vermittler ab. Nach dem Start des VS Code Servers im Container übernimmt der Remote Extension Host die Erweiterungsausführung, und der Port-Forwarding-Prozess bietet einen TCP-Tunnel für den lokalen Browser, um auf Containerdienste zuzugreifen. Jedes Glied in dieser Kette kann eine Quelle für IO-Verstärkung sein.

Docker CLI-Polling-Mechanismus

Die Dev Containers-Erweiterung ruft Docker CLI-Befehle频繁 auf, um Containerstatus zu erhalten und aufrechtzuerhalten. In der Container-Startphase führt die Erweiterung nacheinander docker inspect --type container aus, um Container-Metadaten zu erhalten, docker version --format, um die Docker daemon-Verfügbarkeit zu prüfen, docker exec, um Umgebungserkennungsbefehle im Container auszuführen, und docker ps, um laufende Container aufzulisten. Diese Befehle werden nicht nur einmal beim Start ausgeführt, sondern während des gesamten Lebenszyklus des Containers mit einer bestimmten Häufigkeit wiederholt aufgerufen.

Jeder Aufruf von Docker CLI startet einen neuen Unterprozess, was eine Reihe von IO-Operationen beinhaltet: Prozesserstellung, stdout-Pipe-Lesen, JSON-Ergebnis-Parsing usw. Im Standardmodus müssen diese Operationsdaten die Windows/WSL-Grenze überschreiten, und das 9P-Dateifreigabeprotokoll von WSL2 hat eine schlechte Leistung bei der Verarbeitung einer großen Anzahl kleiner Datei-IOs und hochfrequenter Kurzverbindungen. Gemäß der Microsoft-Official-Dokumentation sollten grenzüberschreitende Dateisystemoperationen vermieden werden, aber das Architekturdesign von Dev Container macht es schwierig, diesen Overhead vollständig zu vermeiden.

sequenceDiagram
    participant EH as Extension Host
    participant CLI as Docker CLI
    participant DD as Docker Daemon

    EH->>CLI: spawn docker inspect
    CLI->>DD: Named-Pipe-Anfrage
    DD-->>CLI: JSON-Antwort
    CLI-->>EH: stdout-Pipe-Ausgabe
    EH->>CLI: spawn docker version
    CLI->>DD: Named-Pipe-Anfrage
    DD-->>CLI: Versionsinformation
    CLI-->>EH: stdout-Pipe-Ausgabe
    EH->>CLI: spawn docker exec
    CLI->>DD: Named-Pipe-Anfrage
    DD-->>CLI: Ausführungsergebnis
    CLI-->>EH: stdout-Pipe-Ausgabe

Port-Forwarding-Verbindungsleck

Der Port-Forwarding-Mechanismus von VS Code erstellt für jeden weitergeleiteten Port einen separaten Node.js-Unterprozess. Diese Prozesse stellen über net.createConnection eine Verbindung zum Zielport im Container her und leiten Daten bidirektional zwischen dem lokalen Port und dem Containerport weiter. Das Problem besteht darin, dass wenn der Browser oder ein anderer Client auf den weitergeleiteten Port zugreift und dann die Verbindung trennt, diese Weiterleitungsprozesse fortbestehen und nicht normal beendet werden, wenn die Bereinigungslogik nicht rechtzeitig erfolgt.

Gemäß der Analyse von microsoft/vscode-remote-release#5767 belegt jedes undichte Port-Forwarding-Prozess etwa 26 MiB Speicher. In einer Entwicklungsumgebung mit mehreren konfigurierten Weiterleitungsports und häufigem Zugriff kann die Prozesszahl in kurzer Zeit von normalen 2 auf Dutzende anwachsen. Der folgende Codeausschnitt zeigt das Kernmuster des Port-Forwarding-Prozesses, wobei das client.on('close')-Ereignis der Schlüssel dafür ist, ob der Prozess normal beendet werden kann.

const net = require('net');
process.stdin.pause();
const client = net.createConnection({ port: 36187 }, () => {
    client.pipe(process.stdout);
    process.stdin.pipe(client);
});
client.on('close', function (hadError) {
    console.error(hadError ? 'Remote close with error' : 'Remote close');
    process.exit(hadError ? 1 : 0);
});
client.on('error', function (err) {
    process.stderr.write(err && (err.stack || err.message) || String(err));
});

Wenn der Docker CLI-docker exec-Prozess abnormal beendet wird, während der Node.js-Prozess im Container noch läuft, können diese Waisenprozesse nicht normal recycelt werden, was zu kontinuierlichem Speicherwachstum führt. Dieses Problem wurde nach VS Code Version 1.62 teilweise behoben, kann aber unter bestimmten Netzwerkbedingungen erneut auftreten. Es ist erwähnenswert, dass das Port-Forwarding-Leck keine direkte Verbindung zu executeInWSL hat; es ist ein eigenständiger Softwarefehler im Port-Forwarding-Mechanismus von VS Code.

Extension Host-Wiederverbindungsschleife

Gemäß den Aufzeichnungen von microsoft/vscode-remote-release#6178 gibt es einen Bug in der Wiederverbindungslogik im Extension Host, wenn die Verbindung zum Remote-Container aufgrund von Netzwerkunterbrechungen oder anderen Gründen verloren geht: Eine async-Funktion ruft sich im catch-Block rekursiv selbst auf, was zu einer CPU-Leerlauf-Schleife führt. Der Aufruf-Stack zeigt, dass diese Funktion in processTicksAndRejections wiederholt zirkuliert, ohne eine Exit-Bedingung.

flowchart TD
    A["Verbindung verloren"] e1@--> B["async Wiederverbindungsfunktion"]
    B e2@--> C{"Verbindung erfolgreich?"}
    C e3@-->|Ja| D["Normal wiederhergestellt"]
    C e4@-->|Nein| E["catch-Block"]
    E e5@--> B

    classDef start fill:#FFEBEE,stroke:#C62828,stroke-width:1px,color:#B71C1C;
    classDef work fill:#E8F5E9,stroke:#2E7D32,stroke-width:1px,color:#1B5E20;
    classDef check fill:#FFF8E1,stroke:#EF6C00,stroke-width:1px,color:#E65100;
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9\,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;
    class A start;
    class B,D work;
    class C,E check;
    class e1,e2,e3,e4,e5 animate;

Gleichzeitig wächst der Speicher des Extension Host mit etwa 1 MB/Minute kontinuierlich, da jeder rekursive Aufruf nicht freigegebene Kontexte auf dem Aufruf-Stack akkumuliert. Dieses Problem wurde in der Remote-Containers 0.221.0-pre-release-Version behoben, aber für Benutzer, die die Erweiterung nicht rechtzeitig aktualisiert haben, kann das Problem durch einmaliges Simulieren einer Netzwerkunterbrechnung (z.B. Ausschalten von WiFi) ausgelöst werden, und der Dialog zur Verbindungsunterbrechung wird nie angezeigt. Dies ist ein eigenständiger Softwarefehler, der nicht mit der executeInWSL-Konfiguration zusammenhängt, aber er wird die vom Benutzer wahrgenommene Systemverzögerung verschlimmern.

WSL2-grenzüberschreitende Dateisystem-IO-Verstärkung

Bei der Verwendung von Docker Desktop mit dem WSL2-Backend unter Windows gibt es inhärente grenzüberschreitende Dateisystem-IO-Leistungsprobleme. Die VS Code-Erweiterung auf der Windows-Seite kommuniziert über Pipes mit dem Docker daemon in WSL2. Dateisystemoperationen im Container, die Pfade wie /mnt/c (d.h. Zugriff auf Windows-Festplatten) betreffen, erfordern eine Konvertierung über das 9P-Dateifreigabeprotokoll. Das 9P-Protokoll von WSL2 hat eine deutlich schlechtere Leistung bei der Verarbeitung einer großen Anzahl kleiner Datei-IOs im Vergleich zum nativen Dateisystem, und die Latenz einer einzelnen Operation kann das 3-5-fache des nativen Pfads betragen.

Darüber hinaus wird laut dem Bericht von microsoft/vscode-remote-release#9372 auf ARM-Macs beim Ausführen von x86-Containern über Rosetta der CPU-Affinity-Mask des VS Code Server-Prozesses abnormal auf nur einen einzelnen Kern gesetzt, was dazu führt, dass nproc 1 statt der tatsächlichen physischen Kernanzahl zurückgibt. Obwohl dieses Problem hauptsächlich auf der macOS-Plattform auftritt, zeigt es, dass Dev Container bei der Steuerung von Prozessplanungsparametern über Plattformen hinweg Inkonsistenzen aufweist. Ähnliche Probleme können in der Windows-WSL2-Umgebung in unterschiedlicher Form auftreten. executeInWSL: true verlagert die Ausführung von Docker CLI nach WSL, um die Häufigkeit von grenzüberschreitenden Dateisystem-IOs zu reduzieren, kann aber den 9P-Overhead beim Zugriff des Containers auf /mnt/c-Pfade nicht vollständig eliminieren.

Lösungen

Port-Forwarding-Konfiguration optimieren

Das Optimieren der forwardPorts-Konfiguration in devcontainer.json durch Beibehalten nur der tatsächlich benötigten Ports kann die Anzahl der Port-Forwarding-Prozesse erheblich reduzieren und das Prozessleck-Risiko aus issue #5767 senken. Das Schließen nicht verwendeter Dev Container-Fenster kann auch sofort die entsprechenden Extension Host- und Port-Forwarding-Ressourcen freigeben.

Docker Desktop optimieren

Passen Sie in Docker Desktop unter Settings > Resources die CPU- und Speicherzuweisung angemessen an, um zu vermeiden, dass der Docker daemon aufgrund unzureichender Ressourcen häufig Garbage Collection oder Swap-Operationen durchführt. Stellen Sie sicher, dass Sie die neueste Version von Docker Desktop verwenden, da die WSL2-Backend-Leistung in jeder Version verbessert wird. Für Szenarien mit höheren Leistungsanforderungen können Sie erwägen, Docker Engine direkt in WSL2 zu installieren, um die Virtualisierungsschicht von Docker Desktop zu umgehen und dadurch den zusätzlichen Overhead der Windows/WSL-Grenze weiter zu eliminieren.

VS Code-Konfiguration optimieren

Das Deaktivieren nicht benötigter Erweiterungen kann die Last des Extension Host reduzieren, insbesondere solche, die im Remote-Container ausgeführt werden und Dateiüberwachungsfunktionen haben (wie TypeScript-Sprachdienst, ESLint usw.). Das Setzen von files.watcherExclude in settings.json zum Ausschließen großer Verzeichnisse wie node_modules, .git und dist kann die IO reduzieren, die durch Dateisystemüberwachung entsteht. Das Setzen von extensions.autoUpdate: false kann verhindern, dass Erweiterungsupdates im Hintergrund zusätzliche Netzwerk- und Plattenoperationen in der Containerumgebung auslösen.

Alternative Lösungen

Wenn die oben genannten Maßnahmen die Leistungsanforderungen immer noch nicht erfüllen können, können Sie erwägen, die VS Code Remote-SSH-Erweiterung zu verwenden, um sich mit WSL2 zu verbinden und Docker CLI direkt in WSL2 zum Verwalten von Containern zu verwenden. Diese Methode verwandelt die Docker CLI-Aufrufe von Windows/WSL-grenzüberschreifender Kommunikation in eine lokale Kommunikation innerhalb von WSL2. Eine andere Methode ist die Verwendung von Docker Compose zur Verwaltung des Container-Lebenszyklus. Starten Sie den Dienst mit docker compose up -d und verbinden Sie sich dann nur mit Remote-SSH mit dem Container für die Entwicklung, um den Polling-Mechanismus der Dev Container-Erweiterung vollständig zu umgehen.

executeInWSL aktivieren (Kernlösung)

Die oben genannten Maßnahmen können das Problem der übermäßig hohen IO in unterschiedlichem Maße lindern, aber sie reduzieren entweder nur die Häufigkeit der IO (Port-Forwarding-Optimierung) oder optimieren nur die Ressourcenzuweisung (Docker Desktop-Optimierung), ohne die Grundursache zu berühren: den Named-Pipe-Kommunikationsoverhead, der entsteht, wenn Docker CLI-Aufrufe die Windows/WSL-Grenze überschreiten. dev.containers.executeInWSL ist genau die direkte Lösung für diese Grundursache.

Gemäß der klaren Erklärung des VS Code-Teammitglieds chrmarti in microsoft/vscode-remote-release#9194 bestimmt diese Einstellung, ob der docker-Befehl auf der Windows-Seite oder innerhalb von WSL ausgeführt wird. Nach dem Setzen auf true werden alle Docker CLI-Aufrufe (einschließlich docker inspect, docker version, docker exec, docker ps usw.) innerhalb von WSL ausgeführt und kommunizieren über Unix-Sockets direkt mit dem Docker daemon, wodurch der Named-Pipe- und 9P-Protokollübersetzungsoverhead an der Windows/WSL-Grenze umgangen wird.

Fügen Sie die folgende Konfiguration in settings.json hinzu, um sie zu aktivieren:

{
  "dev.containers.executeInWSL": true
}

Um zu verstehen, warum diese Konfiguration die IO-Leistung erheblich verbessern kann, müssen Sie den Unterschied in den Kommunikationspfaden zwischen den beiden Modi vergleichen. Im Standardmodus (executeInWSL: false oder nicht gesetzt) läuft der VS Code Extension Host auf Windows. Jedes Mal, wenn eine Interaktion mit dem Docker daemon erforderlich ist, wird ein Windows-docker.exe-Unterprozess über spawn gestartet. Dieser Unterprozess kommuniziert über Named Pipes (Pfade beginnen mit \\pipe\) grenzüberschreitend mit dem Docker daemon. Dieser Pfad umfasst drei Phasen: Windows-Prozesserstellung, Named-Pipe-grenzüberschreitende IO und stdout-Pipe-Rückgabe, wobei jede Phase zusätzliche Latenz und IO-Overhead einführt. Wenn executeInWSL: true gesetzt ist, führt der Extension Host Docker CLI stattdessen über wsl -d <distro> -e docker innerhalb von WSL aus. Docker CLI läuft nativ innerhalb von WSL und kommuniziert über Unix-Sockets (lokale IPC) mit dem Docker daemon in derselben WSL-Instanz. Dieser Pfad wird vollständig innerhalb des Linux-Kernelraums abgeschlossen, wodurch der Named-Pipe-grenzüberschreitende Overhead vermieden wird.

flowchart TB
    subgraph Default["Standardmodus (executeInWSL: false)"]
        direction LR
        A1["Extension Host<br/>(Windows)"]
        A2["docker.exe<br/>(Windows-Unterprozess)"]
        A3["Named Pipe<br/>(\\\\pipe\\\\)"]
        A4["Docker Daemon<br/>(WSL2)"]
        A1 e1@--> A2
        A2 e2@--> A3
        A3 e3@--> A4
    end

    subgraph Optimized["Optimierter Modus (executeInWSL: true)"]
        direction LR
        B1["Extension Host<br/>(Windows)"]
        B2["wsl -e docker<br/>(Innerhalb von WSL)"]
        B3["Unix Socket<br/>(Lokale IPC)"]
        B4["Docker Daemon<br/>(WSL2)"]
        B1 e4@--> B2
        B2 e5@--> B3
        B3 e6@--> B4
    end

    Default ~~~ Optimized

    classDef win fill:#E3F2FD,stroke:#1565C0,stroke-width:1px,color:#0D47A1;
    classDef wsl fill:#FFF8E1,stroke:#EF6C00,stroke-width:1px,color:#E65100;
    classDef fast fill:#E8F5E9,stroke:#2E7D32,stroke-width:1px,color:#1B5E20;
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9\,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;

    class A1,A2 win;
    class A3,A4 wsl;
    class B1 win;
    class B2,B3,B4 fast;
    class e1,e2,e3,e4,e5,e6 animate;

Die Verbesserung kann durch die quantitativen Daten aus der Untersuchungsphase verifiziert werden: Im Standardmodus beträgt die Latenz eines einzelnen docker inspect --type container-Aufrufs etwa 1800ms, und der docker version-Aufruf etwa 620ms. Diese Latenzen stammen hauptsächlich aus dem Named-Pipe-grenzüberschreitenden Kommunikationsoverhead und dem Prozesserstellungsoverhead an der Windows/WSL-Grenze. Nach der Aktivierung von executeInWSL: true führt Docker CLI innerhalb von WSL über Unix-Sockets mit dem daemon kommuniziert, und die Latenz eines einzelnen Aufrufs kann auf Millisekundenebene reduziert werden. Die kumulative Verbesserung ist besonders signifikant.

Bekannte Probleme und Vorsichtshinweise

dev.containers.executeInWSL kann die IO-Leistung effektiv verbessern, aber bei der Verwendung sind die folgenden bekannten Probleme zu beachten.

Docker Desktop Auto-Start-Problem: issue #9695 berichtet, dass Docker Desktop mit executeInWSL: true nicht automatisch startet. Dieses Problem wurde in der Dev Containers 0.353.0-pre-release-Version behoben. Benutzer neuerer Versionen sollten dieses Problem nicht mehr haben.

WSL-Dienstweiterleitung: issue #9194 berichtet, dass die Erweiterung auch bei executeInWSL: false versucht, eine Verbindung zu WSL herzustellen (für Display/SSH-Agent/GPG-Agent-Weiterleitung). Dieses Verhalten wurde in der 0.337.0-pre-release-Version durch Hinzufügen der neuen Einstellung dev.containers.wslServiceForwarding kontrollierbar gemacht. Benutzer können die WSL-Dienstweiterleitung unabhängig deaktivieren.

Rancher Desktop-Kompatibilität: issue #10722 berichtet, dass bei Verwendung von Rancher Desktop anstelle von Docker Desktop executeInWSL: true einen WSL1-Fehler auslöst. Dieses Problem ist derzeit noch offen. Rancher Desktop-Benutzer müssen diese Einstellung möglicherweise vorübergehend deaktivieren.

Versehentliche Aktivierung: issue #11005 berichtet, dass executeInWSL: true in lokalen Windows-Repositories versehentlich den Dev Container-Initialisierungsprozess auslöst. Dieses Problem ist ebenfalls offen. Betroffene Benutzer können erwägen, diese Einstellung auf bestimmte Arbeitsbereiche zu beschränken, anstatt sie global zu konfigurieren.

Zusammenfassung

Die Untersuchung des Problems der übermäßig hohen IO-Auslastung von VS Code Dev Container unter Windows erfordert die schrittweise Lokalisierung der Grundursache ausgehend vom Phänomen. Mit Process Monitor kann bestätigt werden, dass die Hauptquelle der IO die Named-Pipe-Kommunikation von Docker CLI ist. Mit VS Code-internen Werkzeugen und Windows Performance Analyzer können die Aufrufhäufigkeit und Latenz weiter quantifiziert werden. Die Ursachenanalyse zeigt vier überlagerte Faktoren: Das hochfrequente grenzüberschreitende Polling von Docker CLI ist der wichtigste Leistungsengpass, das Verbindungsleck der Port-Forwarding-Prozesse und die Wiederverbindungsschleife des Extension Host sind bestätigte Softwarefehler, und die grenzüberschreitende Dateisystem-IO-Verstärkung von WSL2 ist eine plattformspezifische inhärente Einschränkung.

Unter den Lösungen ist dev.containers.executeInWSL: true die wichtigste Maßnahme. Sie eliminiert direkt den Named-Pipe-Kommunikationsoverhead von Docker CLI, der die Windows/WSL-Grenze überschreitet, indem sie den Ausführungsort der hochfrequenten CLI-Aufrufe von Windows nach WSL verlagert und die lokale IPC über Unix-Sockets abschließt. Die anderen Maßnahmen (Port-Forwarding-Optimierung, Docker Desktop-Optimierung, VS Code-Konfigurationsoptimierung) dienen als Hilfsmaßnahmen und lindern die Auswirkungen anderer Faktoren in unterschiedlichem Maße. Für Benutzer, die von diesem Problem betroffen sind, wird empfohlen, die Grundursache gemäß dem Untersuchungsprozess in diesem Artikel zu bestätigen, dann executeInWSL: true priorisiert zu aktivieren und dann basierend auf dem tatsächlichen Szenario geeignete Hilfsoptimierungsstrategien auszuwählen.

• ←Zurück
• Weiter→