VS Code Dev Container IO उच्च: executeInWSL कॉन्फ़िगरेशन विवरण और मूल कारण विश्लेषण

Windows पर VS Code Dev Container एक्सटेंशन के कारण IO अधिक होने की समस्या की पूरी जांच प्रक्रिया को दर्शाता है, लक्षण पहचान से मूल कारण विश्लेषण तक, और अंततः dev.containers.executeInWSL को मुख्य समाधान के रूप में उपयोग करके Docker CLI क्रॉस-बाउंडरी संचार बाधा को हल करना.

Friday, April 03, 2026

Categories:

Windows पर VS Code के Dev Container एक्सटेंशन का उपयोग करके कंटेनराइज्ड विकास करते समय, कुछ उपयोगकर्ताओं को स्पष्ट रूप से सिस्टम धीमा होने की समस्या का सामना करना पड़ता है। टास्क मैनेजर में, Extension Host प्रक्रिया का CPU और डिस्क रीड IO लगातार अधिक रहता है, भले ही कोई सक्रिय ऑपरेशन न हो। यह लेख समस्या के लक्षणों से शुरू करके, धीरे-धीरे मूल कारण की पहचान करने और मुख्य समाधान खोजने की पूरी जांच प्रक्रिया को दर्शाता है।

समस्या के लक्षण

सिस्टम धीमा होना Dev Container एक्सटेंशन से कनेक्ट होने के बाद होता है। टास्क मैनेजर के माध्यम से देखा जा सकता है कि Extension Host प्रक्रिया का डिस्क रीड IO और CPU उपयोग दर लगातार अधिक रहती है, भले ही उपयोगकर्ता कोई संपादन या टर्मिनल ऑपरेशन न कर रहा हो, ये संकेतक आइडल स्तर तक नहीं गिरते। चरम स्थितियों में, पूरे Windows डेस्कटॉप की प्रतिक्रिया गति प्रभावित होती है, माउस कर्सर में अंतराल रुकावट दिखाई देती है।

जांच प्रक्रिया

IO स्रोत की पहचान के लिए Process Monitor का उपयोग

Sysinternals Process Monitor इस प्रकार की समस्याओं की जांच के लिए पहला उपकरण है। procmon शुरू करने के बाद, फ़िल्टर शर्त सेट करें Process Name is Code.exe या Process Name is Extension Host, यह सभी ReadFile/WriteFile ऑपरेशन के पथ और आवृत्ति को वास्तविक समय में देख सकते हैं। फ़िल्टर परिणामों में, \\pipe\ से शुरू होने वाले पथ वाले named pipe ऑपरेशन असामान्य रूप से उच्च आवृत्ति पर दिखाई देते हैं, प्रति सेकंड दर्जनों बार। ये named pipe ऑपरेशन Docker CLI और Docker daemon के बीच संचार से संबंधित हैं, जो दर्शाता है कि Extension Host Docker CLI को बार-बार कॉल कर रहा है।

VS Code के अंतर्निहित उपकरणों से पुष्टि करना

Help > Toggle Developer Tools के माध्यम से Chromium DevTools खोलें, Performance पैनल में CPU profile रिकॉर्ड करें, Extension Host का अधिकांश समय उप-प्रक्रियाओं के spawn और stdout पाइप पढ़ने पर खर्च होता दिखाई देता है। Output पैनल में “Dev Containers” लॉग स्तर को “trace” पर सेट करें, पूर्ण कमांड कॉल अनुक्रम देखा जा सकता है: docker inspect --type container, docker version --format, docker exec, docker exec आदि कमांड बार-बार निष्पादित होते हैं। issue #9194 के लॉग डेटा से एकल कॉल की लागत को मापा जा सकता है: docker inspect --type container में लगभग 1800ms, docker version में लगभग 620ms लगता है।

सिस्टम-स्तर IO के विश्लेषण के लिए Windows Performance Analyzer का उपयोग

गहरे विश्लेषण के लिए, wpr.exe -start GeneralProfile -filemode का उपयोग करके ETW रिकॉर्डिंग शुरू करें, समस्या को दोबारा उत्पन्न करने के बाद wpr.exe -stop capture.etl से रिकॉर्डिंग बंद करें, Windows Performance Analyzer में परिणाम लोड करें। Disk I/O व्यू पुष्टि करता है कि Extension Host डिस्क रीड IO का प्रमुख योगदानकर्ता है, Process Life Cycle व्यू कई छोटी-उम्र वाली उप-प्रक्रियाओं को दर्शाता है जो बार-बार बनाई और नष्ट की जाती हैं, ये उप-प्रक्रियाएं Docker CLI के कॉल उदाहरण हैं।

मूल कारण विश्लेषण

Dev Container का प्रक्रिया संचार आर्किटेक्चर

जांच परिणाम Dev Container के बहु-प्रक्रिया संचार आर्किटेक्चर की ओर इंगित करते हैं। जब उपयोगकर्ता Windows पर Dev Container एक्सटेंशन के माध्यम से एक कंटेनर वर्कस्पेस खोलता है, वास्तव में Windows और Linux सीमा को पार करने वाली एक बहु-प्रक्रिया संचार लिंक शुरू होती है।

flowchart LR
    subgraph Windows["Windows होस्ट"]
        A["VS Code क्लाइंट<br/>(Electron)"]
        B["Extension Host<br/>(Node.js)"]
        C["Docker CLI<br/>(उप-प्रक्रिया)"]
    end

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

    subgraph Container["कंटेनर के अंदर"]
        E["VS Code सर्वर"]
        F["रिमोट Extension Host"]
        G["पोर्ट फॉरवर्डिंग प्रक्रिया<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;

स्थानीय VS Code क्लाइंट (Electron) IPC के माध्यम से स्थानीय Extension Host (Node.js) से संवाद करता है। Extension Host को कंटेनर के अंदर VS Code सर्वर से कनेक्शन स्थापित करने की आवश्यकता है, और यह कनेक्शन Docker CLI के माध्यम से निर्भर करता है। कंटेनर के अंदर VS Code सर्वर शुरू होने के बाद, Remote Extension Host एक्सटेंशन निष्पादन को संभालता है, पोर्ट फॉरवर्डिंग प्रक्रिया स्थानीय ब्राउज़र को कंटेनर सेवाओं तक पहुंचने के लिए TCP टनल प्रदान करती है। इस लिंक में प्रत्येक घटक IO प्रवर्धन का स्रोत बन सकता है।

Docker CLI पोलिंग तंत्र

Dev Containers एक्सटेंशन कंटेनर की स्थिति प्राप्त करने और बनाए रखने के लिए Docker CLI कमांड को बार-बार कॉल करके प्राप्त करता है। कंटेनर स्टार्टअप चरण में, एक्सटेंशन क्रम से निष्पादित करता है docker inspect --type container कंटेनर मेटाडेटा प्राप्त करने के लिए, docker version --format Docker daemon उपलब्धता जांचने के लिए, docker exec कंटेनर के अंदर पर्यावरण पहचान कमांड निष्पादित करने के लिए, और docker ps चल रहे कंटेनरों की सूची के लिए। ये कमांड केवल एक बार स्टार्टअप पर नहीं चलते, बल्कि कंटेनर के पूरे जीवनकाल में एक निश्चित आवृत्ति पर बार-बार कॉल किए जाते हैं।

प्रत्येक Docker CLI कॉल एक नई उप-प्रक्रिया शुरू करता है, जिसमें प्रक्रिया निर्माण ओवरहेड, stdout पाइप पढ़ना, JSON परिणाम पार्सिंग आदि शामिल हैं। डिफ़ॉल्ट मोड में, इन ऑपरेशन के डेटा को Windows/WSL सीमा को पार करना होता है, और WSL2 का 9P फाइल शेयरिंग प्रोटोकॉल बड़ी संख्या में छोटी फाइल IO और उच्च-आवृत्ति शॉर्ट कनेक्शन को संभालने में खराब प्रदर्शन करता है। Microsoft आधिकारिक दस्तावेज़ के अनुसार, क्रॉस-फाइलसिस्टम ऑपरेशन से बचा जाना चाहिए, लेकिन Dev Container का आर्किटेक्चर डिज़ाइन इसे पूरी तरह से बचाने में कठिनाई उत्पन्न करता है।

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 अनुरोध
    DD-->>CLI: JSON प्रतिक्रिया
    CLI-->>EH: stdout पाइप आउटपुट
    EH->>CLI: spawn docker version
    CLI->>DD: named pipe अनुरोध
    DD-->>CLI: संस्करण जानकारी
    CLI-->>EH: stdout पाइप आउटपुट
    EH->>CLI: spawn docker exec
    CLI->>DD: named pipe अनुरोध
    DD-->>CLI: निष्पादन परिणाम
    CLI-->>EH: stdout पाइप आउटपुट

पोर्ट फॉरवर्डिंग कनेक्शन लीक

VS Code की पोर्ट फॉरवर्डिंग तंत्र प्रत्येक फॉरवर्ड पोर्ट के लिए एक स्वतंत्र Node.js उप-प्रक्रिया बनाता है। ये प्रक्रियाएं net.createConnection के माध्यम से कंटेनर के अंदर लक्ष्य पोर्ट से कनेक्ट होती हैं, और स्थानीय पोर्ट और कंटेनर पोर्ट के बीच डेटा दो-दिशात्मक रूप से फॉरवर्ड करती हैं। समस्या यह है कि जब ब्राउज़र या अन्य क्लाइंट फॉरवर्ड पोर्ट एक्सेस करने के बाद डिस्कनेक्ट होते हैं, तो सफाई तर्क समय पर न होने पर, ये फॉरवर्डिंग प्रक्रियाएं सामान्य रूप से बाहर नहीं निकलतीं बल्कि जारी रहती हैं।

microsoft/vscode-remote-release#5767 के विश्लेषण के अनुसार, प्रत्येक लीक हुई पोर्ट फॉरवर्डिंग प्रक्रिया लगभग 26 MiB मेमोरी का उपयोग करती है। कई फॉरवर्ड पोर्ट कॉन्फ़िगर किए गए और बार-बार एक्सेस किए जाने वाले विकास वातावरण में, प्रक्रियाओं की संख्या सामान्य 2 से दर्जनों तक बढ़ सकती है। निम्नलिखित कोड स्निपेट पोर्ट फॉरवर्डिंग प्रक्रिया का मुख्य पैटर्न दर्शाता है, जहां client.on('close') इवेंट हैंडलिंग प्रक्रिया के सामान्य रूप से बाहर निकलने में महत्वपूर्ण है।

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));
});

जब Docker CLI की docker exec प्रक्रिया असामान्य रूप से समाप्त होती है लेकिन कंटेनर के अंदर Node.js प्रक्रिया अभी भी चल रही होती है, तो ये अनाथ प्रक्रियाएं सामान्य रूप से पुनर्चक्रित नहीं हो पातीं, जिससे मेमोरी लगातार बढ़ती रहती है। यह समस्या VS Code 1.62 संस्करण के बाद आंशिक रूप से ठीक हुई, लेकिन विशिष्ट नेटवर्क स्थितियों में फिर से हो सकती है। ध्यान दें कि पोर्ट फॉरवर्डिंग लीक का executeInWSL से कोई सीधा संबंध नहीं है, यह VS Code पोर्ट फॉरवर्डिंग तंत्र का स्वयं का सॉफ्टवेयर दोष है।

Extension Host पुनः कनेक्शन लूप

microsoft/vscode-remote-release#6178 के अनुसार, जब रिमोट कंटेनर से कनेक्शन नेटवर्क बाधा या अन्य कारणों से खो जाता है, तो Extension Host में पुनः कनेक्शन तर्क में एक बग है: एक async फंक्शन catch ब्लॉक में स्वयं को पुनरावर्ती रूप से कॉल करता है, जिससे CPU खाली घूमता है। कॉल स्टैक दर्शाता है कि यह फंक्शन processTicksAndRejections में बार-बार घूमता है, कोई बाहर निकलने की स्थिति नहीं है।

flowchart TD
    A["कनेक्शन खो गया"] e1@--> B["async पुनः कनेक्ट फंक्शन"]
    B e2@--> C{"कनेक्शन सफल?"}
    C e3@-->|हां| D["सामान्य हो गया"]
    C e4@-->|नहीं| E["catch ब्लॉक"]
    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;

इसके साथ ही, Extension Host की मेमोरी लगभग 1 MB/मिनट की दर से लगातार बढ़ती है, क्योंकि प्रत्येक पुनरावर्ती कॉल कॉल स्टैक पर अप्रकाशित संदर्भ जमा करता है। यह समस्या Remote-Containers 0.221.0-pre-release संस्करण में ठीक हुई, लेकिन एक्सटेंशन को समय पर अपडेट न करने वाले उपयोगकर्ताओं के लिए, बस एक नेटवर्क डिस्कनेक्शन (जैसे WiFi बंद करना) का अनुकरण करके इस समस्या को ट्रिगर किया जा सकता है, और डिस्कनेक्ट कनेक्शन का संकेत देने वाला डायलॉग कभी प्रदर्शित नहीं होगा। यह एक स्वतंत्र सॉफ्टवेयर बग है, जो executeInWSL कॉन्फ़िगरेशन से संबंधित नहीं है, लेकिन यह उपयोगकर्ता द्वारा अनुभव की जाने वाली सिस्टम धीमेपन को बढ़ा देता है।

WSL2 क्रॉस-फाइलसिस्टम IO प्रवर्धन

Windows पर Docker Desktop के WSL2 बैकएंड का उपयोग करते समय, अंतर्निहित क्रॉस-फाइलसिस्टम IO प्रदर्शन समस्या है। Windows सिरे के VS Code एक्सटेंशन pipe के माध्यम से WSL2 में Docker daemon से संवाद करता है, कंटेनर के अंदर फाइलसिस्टम ऑपरेशन यदि /mnt/c पथ (यानी Windows डिस्क एक्सेस) को शामिल करते हैं, तो उन्हें 9P फाइल शेयरिंग प्रोटोकॉल के माध्यम से कनवर्ट करना होता है। WSL2 का 9P प्रोटोकॉल बड़ी संख्या में छोटी फाइल IO परिदृश्यों में मूल फाइलसिस्टम की तुलना में काफी खराब प्रदर्शन करता है, एकल ऑपरेशन में विलंबता मूल पथ की 3-5 गुना हो सकती है।

इसके अतिरिक्त, microsoft/vscode-remote-release#9372 की रिपोर्ट के अनुसार, ARM Mac पर Rosetta के माध्यम से x86 कंटेनर चलाते समय, VS Code Server प्रक्रिया का CPU affinity mask असामान्य रूप से केवल एक कोर का उपयोग करने के लिए सेट हो जाता है, जिससे nproc वास्तविक भौतिक कोर की संख्या के बजाय 1 लौटाता है। यद्यपि यह समस्या मुख्य रूप से macOS प्लेटफॉर्म पर दिखाई देती है, यह Dev Container के प्लेटफॉर्म-क्रॉसिंग परिदृश्य में प्रक्रिया शेड्यूलिंग पैरामीटर पर नियंत्रण में असंगति को प्रकट करती है, समान समस्या Windows के WSL2 वातावरण में विभिन्न रूपों में भी दिखाई दे सकती है। executeInWSL: true Docker CLI के निष्पादन स्थान को WSL के अंदर ले जाकर क्रॉस-फाइलसिस्टम IO की आवृत्ति को कम करता है, लेकिन कंटेनर के अंदर से /mnt/c पथ एक्सेस करते समय होने वाले 9P ओवरहेड को पूरी तरह से समाप्त नहीं कर सकता।

समाधान

पोर्ट फॉरवर्डिंग कॉन्फ़िगरेशन को सरल बनाना

devcontainer.json में पोर्ट फॉरवर्डिंग कॉन्फ़िगरेशन को सरल बनाएं, केवल वास्तविक आवश्यक पोर्ट रखें, जो पोर्ट फॉरवर्डिंग प्रक्रियाओं की संख्या को काफी कम कर सकता है और issue #5767 में वर्णित प्रक्रिया लीक जोखिम को कम कर सकता है। उपयोग में न होने वाले Dev Container विंडो को बंद करना भी तुरंत संबंधित Extension Host और पोर्ट फॉरवर्डिंग संसाधनों को मुक्त कर सकता है।

Docker Desktop अनुकूलन

Docker Desktop के Settings > Resources पैनल में, CPU और मेमोरी आवंटन को उचित रूप से समायोजित करें, ताकि Docker daemon संसाधनों की कमी के कारण बार-बार garbage collection या swap ऑपरेशन न करे। Docker Desktop के नवीनतम संस्करण का उपयोग सुनिश्चित करें, क्योंकि WSL2 बैकएंड का प्रदर्शन प्रत्येक संस्करण में सुधार होता है। उच्च प्रदर्शन आवश्यकताओं वाले परिदृश्यों के लिए, Docker Desktop की वर्चुअलाइजेशन परत को बायपास करने और IO ओवरहेड को और कम करने के लिए WSL2 के अंदर सीधे Docker Engine इंस्टॉल करने पर विचार किया जा सकता है।

VS Code कॉन्फ़िगरेशन अनुकूलन

अनावश्यक एक्सटेंशन को अक्षम करना Extension Host का भार कम कर सकता है, विशेषकर उन एक्सटेंशन को जो रिमोट कंटेनर में चलते हैं और फाइल वॉचिंग क्षमता रखते हैं (जैसे TypeScript लैंग्वेज सर्विस, ESLint आदि)। settings.json में files.watcherExclude सेट करके node_modules, .git, dist जैसे बड़े निर्देशिकाओं को बाहर करें, जो फाइलसिस्टम वॉचिंग से उत्पन्न IO को कम कर सकता है। extensions.autoUpdate: false सेट करना बैकग्राउंड एक्सटेंशन अपडेट से बचा सकता है जो कंटेनर वातावरण में अतिरिक्त नेटवर्क और डिस्क ऑपरेशन ट्रिगर करता है।

विकल्प

यदि उपरोक्त उपाय प्रदर्शन आवश्यकताओं को पूरा करने में असमर्थ हैं, तो VS Code Remote-SSH एक्सटेंशन का उपयोग करके WSL2 से कनेक्ट होने पर विचार किया जा सकता है, WSL2 के अंदर सीधे Docker CLI का उपयोग करके कंटेनर प्रबंधित करें। यह विधि Docker CLI कॉल को Windows/WSL क्रॉस-बाउंडरी संचार से WSL2 के अंदर स्थानीय संचार में बदल देती है। एक अन्य तरीका Docker Compose का उपयोग करके कंटेनर जीवनचक्र प्रबंधित करना है, docker compose up -d से सेवा शुरू करने के बाद, केवल Remote-SSH का उपयोग करके कंटेनर से कनेक्ट होकर विकास करें, Dev Container एक्सटेंशन के पोलिंग तंत्र को पूरी तरह से बायपास करें।

executeInWSL सक्षम करना (मुख्य समाधान)

उपरोक्त उपाय IO अधिक होने की समस्या को विभिन्न डिग्री में कम कर सकते हैं, लेकिन वे या तो केवल IO की आवृत्ति कम करते हैं (पोर्ट फॉरवर्डिंग को सरल बनाना), या केवल संसाधन आवंटन को अनुकूलित करते हैं (Docker Desktop अनुकूलन), और मूल कारण को संबोधित नहीं करते: Docker CLI कॉल Windows/WSL सीमा को पार करते समय named pipe संचार ओवरहेड उत्पन्न होता है। dev.containers.executeInWSL इसी मूल कारण के लिए सीधा समाधान है।

VS Code टीम के सदस्य chrmarti के microsoft/vscode-remote-release#9194 में स्पष्ट विवरण के अनुसार, यह सेटिंग निर्धारित करती है कि docker कमांड Windows सिरे पर या WSL के अंदर चलता है। इसे true पर सेट करने के बाद, सभी Docker CLI कॉल (जिसमें docker inspect, docker version, docker exec, docker ps आदि शामिल हैं) WSL के अंदर निष्पादित होंगे, Unix socket के माध्यम से सीधे Docker daemon से संवाद करेंगे, thereby Windows/WSL सीमा पर named pipe और 9P प्रोटोकॉल कनवर्ज़न ओवरहेड को बायपास करेंगे।

इसे सक्षम करने के लिए settings.json में निम्नलिखित कॉन्फ़िगरेशन जोड़ें:

{
  "dev.containers.executeInWSL": true
}

यह समझने के लिए कि यह कॉन्फ़िगरेशन IO प्रदर्शन को क्यों महत्वपूर्ण रूप से सुधार सकता है, दो मोड में संचार पथ के अंतर की तुलना करना आवश्यक है। डिफ़ॉल्ट मोड में (executeInWSL: false या सेट नहीं), VS Code Extension Host Windows पर चलता है, हर बार Docker daemon के साथ इंटरैक्ट करने की आवश्यकता होने पर, यह spawn के माध्यम से Windows पर docker.exe उप-प्रक्रिया शुरू करता है। यह उप-प्रक्रिया named pipe (पथ \\pipe\ से शुरू होता है) के माध्यम से Windows/WSL सीमा को पार करके Docker daemon से संवाद करती है। इस पथ में Windows प्रक्रिया निर्माण, named pipe क्रॉस-बाउंडरी IO, और stdout पाइप वापसी के तीन चरण शामिल हैं, प्रत्येक चरण अतिरिक्त विलंबता और IO ओवरहेड पैदा करता है। जब executeInWSL: true होता है, Extension Host WSL के अंदर wsl -d <distro> -e docker के माध्यम से Docker CLI निष्पादित करता है। Docker CLI WSL के अंदर मूल रूप से चलता है, Unix socket (स्थानीय IPC) के माध्यम से उसी WSL इंस्टेंस में Docker daemon से संवाद करता है। यह पथ पूरी तरह Linux कर्नेल स्पेस में पूरा होता है, named pipe के क्रॉस-बाउंडरी ओवरहेड से बचता है।

flowchart TB
    subgraph Default["डिफ़ॉल्ट मोड (executeInWSL: false)"]
        direction LR
        A1["Extension Host<br/>(Windows)"]
        A2["docker.exe<br/>(Windows उप-प्रक्रिया)"]
        A3["named pipe<br/>(\\\\pipe\\\\)"]
        A4["Docker Daemon<br/>(WSL2)"]
        A1 e1@--> A2
        A2 e2@--> A3
        A3 e3@--> A4
    end

    subgraph Optimized["अनुकूलित मोड (executeInWSL: true)"]
        direction LR
        B1["Extension Host<br/>(Windows)"]
        B2["wsl -e docker<br/>(WSL के अंदर)"]
        B3["Unix socket<br/>(स्थानीय 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;

जांच चरण के मात्रात्मक डेटा से इस सुधार को सत्यापित किया जा सकता है: डिफ़ॉल्ट मोड में, एकल docker inspect --type container कॉल में लगभग 1800ms, docker version कॉल में लगभग 620ms लगता है, ये विलंबता मुख्य रूप से Windows/WSL सीमा पर named pipe संचार और प्रक्रिया निर्माण ओवरहेड से आती है। executeInWSL: true सक्षम करने के बाद, Docker CLI WSL के अंदर Unix socket के माध्यम से daemon से संवाद करता है, एकल कॉल का विलंबता मिलीसेकंड स्तर तक गिर सकता है, संचयी प्रभाव का सुधार विशेष रूप से उल्लेखनीय है।

ज्ञात समस्याएं और सावधानियां

dev.containers.executeInWSL IO प्रदर्शन में प्रभावी सुधार कर सकता है, लेकिन इसका उपयोग करते समय निम्नलिखित ज्ञात समस्याओं पर ध्यान देना आवश्यक है।

Docker Desktop स्वतः प्रारंभ समस्या: issue #9695 रिपोर्ट करता है, executeInWSL: true पर Docker Desktop स्वतः प्रारंभ नहीं होता। यह समस्या Dev Containers 0.353.0-pre-release संस्करण में ठीक हुई, नवीनतम संस्करण का उपयोग करने वाले उपयोगकर्ताओं को इस समस्या का सामना नहीं करना चाहिए।

WSL सेवा फॉरवर्डिंग: issue #9194 रिपोर्ट करता है, भले ही executeInWSL को false पर सेट किया गया हो, एक्सटेंशन अभी भी WSL से कनेक्ट करने का प्रयास करता है (display/ssh-agent/gpg-agent फॉरवर्डिंग के लिए)। यह व्यवहार 0.337.0-pre-release संस्करण में नई dev.containers.wslServiceForwarding सेटिंग आइटम जोड़के नियंत्रित किया गया, उपयोगकर्ता WSL सेवा फॉरवर्डिंग को स्वतंत्र रूप से बंद कर सकते हैं।

Rancher Desktop अनुकूलता: issue #10722 रिपोर्ट करता है, Rancher Desktop को Docker Desktop के स्थान पर उपयोग करते समय, executeInWSL: true WSL1 त्रुटि संकेत ट्रिगर करता है। यह समस्या अभी open स्थिति में है, Rancher Desktop उपयोगकर्ताओं को इस सेटिंग को अस्थायी रूप से अक्षम करने की आवश्यकता हो सकती है।

अनपेक्षित सक्रियण: issue #11005 रिपोर्ट करता है, executeInWSL: true स्थानीय Windows रिपॉजिटरी में Dev Container प्रारंभिक प्रक्रिया को अनपेक्षित रूप से ट्रिगर करता है। यह समस्या भी open स्थिति में है, प्रभावित उपयोगकर्ता इस सेटिंग को वैश्विक कॉन्फ़िगरेशन के बजाय विशिष्ट वर्कस्पेस तक सीमित करने पर विचार कर सकते हैं।

सारांश

Windows पर VS Code Dev Container की IO अधिक होने की समस्या की जांच के लिए, लक्षणों से शुरू करके धीरे-धीरे मूल कारण की पहचान करना आवश्यक है। Process Monitor के माध्यम से IO का प्रमुख स्रोत Docker CLI का named pipe संचार होने की पुष्टि की जा सकती है, VS Code के अंतर्निहित उपकरणों और Windows Performance Analyzer के माध्यम से कॉल की आवृत्ति और विलंबता को आगे मापा जा सकता है। मूल कारण विश्लेषण ने चार ओवरलेइंग कारकों को प्रकट किया: Docker CLI की उच्च-आवृत्ति क्रॉस-बाउंडरी पोलिंग प्रमुख प्रदर्शन बाधा है, पोर्ट फॉरवर्डिंग प्रक्रिया का कनेक्शन लीक और Extension Host का पुनः कनेक्शन लूप पुष्टि किए गए सॉफ्टवेयर बग हैं, WSL2 क्रॉस-फाइलसिस्टम IO प्रवर्धन प्लेटफॉर्म-स्तरीय अंतर्निहित सीमा है।

समाधानों में, dev.containers.executeInWSL: true सबसे मुख्य उपाय है, यह सीधे Docker CLI के Windows/WSL सीमा को पार करने वाले named pipe संचार ओवरहेड को समाप्त करता है, उच्च-आवृत्ति CLI कॉल के निष्पादन स्थान को Windows से WSL के अंदर ले जाता है, Unix socket के माध्यम से स्थानीय IPC पूरा करता है। अन्य समाधान (पोर्ट फॉरवर्डिंग को सरल बनाना, Docker Desktop अनुकूलन, VS Code कॉन्फ़िगरेशन अनुकूलन) सहायक उपाय के रूप में, विभिन्न डिग्री में अन्य कारकों के प्रभाव को कम करते हैं। इस समस्या से प्रभावित उपयोगकर्ताओं के लिए, इस लेख की जांच प्रक्रिया के अनुसार मूल कारण की पुष्टि करने के बाद, पहले executeInWSL: true सक्षम करने की अनुशंसा है, फिर वास्तविक परिदृश्य के अनुसार उपयुक्त सहायक अनुकूलन रणनीति चुनें।