VS Code Dev Container IO अधिक: executeInWSL कॉन्फ़िगरेशन विवरण और मूल कारण विश्लेषण
Windows पर VS Code के Dev Container एक्सटेंशन का उपयोग करके कंटेनराइज़्ड विकास करते समय, कुछ उपयोगकर्ताओं को सिस्टम में स्पष्ट लैग की समस्या का सामना करना पड़ता है। टास्क मैनेजर में Extension Host प्रक्रिया की CPU और डिस्क रीड IO लगातार उच्च दिखती है, और बिना सक्रिय ऑपरेशन के भी यह घटती नहीं है। इस लेख में समस्या के लक्षणों से शुरू करके, क्रमिक रूप से मूल कारण का पता लगाते हुए, मुख्य समाधान तक पहुँचने की पूरी जांच प्रक्रिया को दर्ज किया गया है।
समस्या के लक्षण
सिस्टम लैग तब होता है जब Dev Container एक्सटेंशन कंटेनर से कनेक्ट होता है। टास्क मैनेजर में Extension Host प्रक्रिया की डिस्क रीड IO और CPU उपयोग लगातार उच्च रहता है, भले ही उपयोगकर्ता कोई संपादन या टर्मिनल ऑपरेशन न करे, ये मीट्रिक आइडल स्तर तक नहीं गिरते। अत्यधिक मामलों में, पूरे Windows डेस्कटॉप की प्रतिक्रिया गति प्रभावित होती है, और माउस कर्सर में अंतराल वाले लैग दिखते हैं।
जांच प्रक्रिया
Process Monitor का उपयोग करके IO स्रोत की पहचान
Sysinternals Process Monitor इस प्रकार की समस्या की पहली जांच के लिए टूल है। Procmon शुरू करने के बाद, फ़िल्टर को Process Name is Code.exe या Process Name is Extension Host पर सेट करें, जिससे सभी ReadFile/WriteFile ऑपरेशनों के पाथ और फ़्रीक्वेंसी को रीयल‑टाइम में देखा जा सके। फ़िल्टर परिणामों में, \\pipe\ से शुरू होने वाले नेम्ड पाइप ऑपरेशनों की फ़्रीक्वेंसी असामान्य रूप से अधिक होती है, प्रति सेकंड कई बार। ये नेम्ड पाइप ऑपरेशन्स Docker CLI और Docker daemon के बीच संचार को दर्शाते हैं, जिससे पता चलता है कि Extension Host बार‑बार Docker CLI को कॉल कर रहा है।
VS Code के अंतर्निहित टूल्स से पुष्टि
Help > Toggle Developer Tools खोलें और Chromium DevTools में Performance पैनल पर CPU प्रोफ़ाइल रिकॉर्ड करें। इससे पता चलता है कि Extension Host का बहुत समय सब‑प्रोसेस के spawn और stdout पाइप पढ़ने में खर्च हो रहा है। Output पैनल में “Dev Containers” लॉग लेवल को “trace” पर सेट करने से पूरी कमांड कॉल श्रृंखला दिखती है: docker inspect --type container, docker version --format, docker exec, docker ps आदि कमांड बार‑बार चलाए जा रहे हैं। issue #9194 के लॉग डेटा से एकल कॉल की लागत मापी जा सकती है: docker inspect --type container लगभग 1800 ms लेता है, docker version लगभग 620 ms।
Windows Performance Analyzer से सिस्टम‑स्तर IO विश्लेषण
गहरी विश्लेषण के लिए 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 Server"]
F["Remote 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 Server से कनेक्शन स्थापित करना पड़ता है, और यह कनेक्शन Docker CLI को मध्यस्थ के रूप में उपयोग करता है। कंटेनर के अंदर VS Code Server शुरू होने के बाद, Remote Extension Host एक्सटेंशन निष्पादन संभालता है, और पोर्ट‑फ़ॉरवर्डिंग प्रोसेस स्थानीय ब्राउज़र को कंटेनर सेवा तक पहुँचाने के लिए TCP टनल प्रदान करता है। इस लिंक के प्रत्येक चरण में IO वृद्धि का स्रोत बन सकता है।
Docker CLI पोलिंग मैकेनिज़्म
Dev Containers एक्सटेंशन Docker CLI कमांड को बार‑बार कॉल करके कंटेनर की स्थिति प्राप्त और बनाए रखता है। कंटेनर स्टार्टअप चरण में, एक्सटेंशन क्रमशः docker inspect --type container (मेटाडेटा प्राप्त), docker version --format (daemon उपलब्धता जांच), docker exec (कंटेनर में पर्यावरण जांच), और docker ps (रनिंग कंटेनर सूची) चलाता है। ये कमांड केवल स्टार्टअप पर नहीं, बल्कि कंटेनर के पूरे जीवन‑चक्र में निश्चित फ़्रीक्वेंसी से दोहराए जाते हैं।
प्रत्येक Docker CLI कॉल एक नया सब‑प्रोसेस शुरू करता है, जिससे प्रोसेस निर्माण ओवरहेड, stdout पाइप पढ़ना, JSON परिणाम पार्सिंग आदि कई IO ऑपरेशन होते हैं। डिफ़ॉल्ट मोड में, ये डेटा 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 में ठीक किया गया, लेकिन पुराने संस्करण उपयोग करने वाले उपयोगकर्ता एक बार नेटवर्क डिस्कनेक्ट (जैसे Wi‑Fi बंद) सिमुलेट करके इस समस्या को ट्रिगर कर सकते हैं, और डिस्कनेक्ट डायलॉग कभी नहीं दिखेगा। यह executeInWSL सेटिंग से असंबंधित एक स्वतंत्र सॉफ़्टवेयर बग है, लेकिन यह उपयोगकर्ता द्वारा महसूस किए गए सिस्टम लैग को बढ़ाता है।
WSL2 फ़ाइल‑सिस्टम सीमा‑पार IO वृद्धि
Windows पर Docker Desktop के WSL2 बैकएंड का उपयोग करते समय, अंतर्निहित फ़ाइल‑सिस्टम सीमा‑पार IO प्रदर्शन समस्या मौजूद है। Windows पक्ष का VS Code एक्सटेंशन पाइप के माध्यम से WSL2 के Docker daemon से संवाद करता है, और कंटेनर के अंदर की फ़ाइल‑सिस्टम ऑपरेशन्स यदि /mnt/c पाथ (Windows डिस्क तक पहुँच) शामिल करती हैं, तो 9P फ़ाइल‑शेयरिंग प्रोटोकॉल के रूपांतरण से गुजरना पड़ता है। 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 में forwardPorts कॉन्फ़िगरेशन को केवल आवश्यक पोर्ट तक सीमित करने से पोर्ट‑फ़ॉरवर्डिंग प्रोसेस की संख्या काफी घटेगी, और issue #5767 में वर्णित प्रोसेस लीक जोखिम कम होगा। उपयोग में नहीं रहने वाले Dev Container विंडो को बंद करने से संबंधित Extension Host और पोर्ट‑फ़ॉरवर्डिंग संसाधन तुरंत मुक्त हो जाते हैं।
Docker Desktop अनुकूलन
Docker Desktop के Settings > Resources पैनल में CPU और मेमोरी आवंटन को उचित रूप से समायोजित करें, ताकि Docker daemon संसाधन कमी के कारण बार‑बार गार्बेज कलेक्शन या स्वैप ऑपरेशन न करे। नवीनतम Docker Desktop संस्करण का उपयोग सुनिश्चित करें, क्योंकि प्रत्येक रिलीज़ में WSL2 बैकएंड के प्रदर्शन में सुधार किया गया है। उच्च‑प्रदर्शन आवश्यकताओं के लिए, WSL2 के भीतर सीधे Docker Engine स्थापित करने पर विचार करें, जिससे Docker Desktop के वर्चुअलाइज़ेशन लेयर को बायपास करके Windows/WSL सीमा‑पार ओवरहेड को पूरी तरह समाप्त किया जा सके।
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 सीमा‑पार नेम्ड पाइप संचार ओवरहेड—को नहीं छूते। 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 से संवाद करते हैं, जिससे Windows/WSL सीमा‑पार नेम्ड पाइप और 9P रूपांतरण ओवरहेड बायपास हो जाता है।
settings.json में निम्न कॉन्फ़िगरेशन जोड़ें:
{
"dev.containers.executeInWSL": true
}
यह समझने के लिए कि यह सेटिंग IO प्रदर्शन को कैसे सुधारती है, दो मोड के संचार पाथ की तुलना देखें। डिफ़ॉल्ट मोड (executeInWSL: false या अनसेट) में, VS Code Extension Host Windows पर चलता है, और प्रत्येक Docker daemon इंटरैक्शन के लिए Windows पर docker.exe सब‑प्रोसेस spawn किया जाता है। यह सब‑प्रोसेस नेम्ड पाइप (\\pipe\\) के माध्यम से Windows/WSL सीमा‑पार Docker daemon से संवाद करता है। इस पाथ में Windows प्रोसेस निर्माण, नेम्ड पाइप सीमा‑पार IO, और stdout पाइप रिटर्न के तीन चरण शामिल हैं, प्रत्येक में अतिरिक्त विलंब और IO ओवरहेड होता है। executeInWSL: true पर, Extension Host wsl -d <distro> -e docker के माध्यम से Docker CLI को WSL के भीतर चलाता है। Docker CLI WSL के भीतर मूल रूप से चलता है और Unix socket (स्थानीय IPC) के माध्यम से उसी WSL इंस्टेंस के Docker daemon से संवाद करता है। यह पाथ पूरी तरह Linux कर्नेल स्पेस में रहता है, जिससे नेम्ड पाइप सीमा‑पार ओवरहेड समाप्त हो जाता है।
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 कॉल लगभग 1800 ms लेता है, docker version लगभग 620 ms। ये विलंब मुख्यतः Windows/WSL सीमा‑पार नेम्ड पाइप संचार और प्रोसेस निर्माण ओवरहेड से आते हैं। executeInWSL: true पर, Docker CLI WSL के भीतर Unix socket के माध्यम से daemon से संवाद करता है, और एकल कॉल का विलंब मिलिसेकंड स्तर तक घट जाता है, जिससे संचयी प्रभाव अत्यधिक स्पष्ट होता है।
ज्ञात समस्याएँ और सावधानियाँ
dev.containers.executeInWSL प्रदर्शन में सुधार करता है, लेकिन उपयोग के दौरान निम्न ज्ञात मुद्दों पर ध्यान दें।
- Docker Desktop ऑटो‑स्टार्ट समस्या: issue #9695 रिपोर्ट करता है कि
executeInWSL: trueहोने पर Docker Desktop स्वतः नहीं शुरू होता। यह समस्या Dev Containers 0.353.0‑pre‑release में ठीक हो गई है; नवीनतम संस्करण उपयोग करने वाले उपयोगकर्ताओं को अब यह समस्या नहीं मिलनी चाहिए। - WSL सर्विस फ़ॉरवर्डिंग: issue #9194 बताता है कि
executeInWSLकोfalseरखने पर भी एक्सटेंशन WSL (डिस्प्ले/ssh‑agent/gpg‑agent फ़ॉरवर्डिंग) से कनेक्ट करने की कोशिश करता है। यह व्यवहार 0.337.0‑pre‑release में नया सेटिंगdev.containers.wslServiceForwardingद्वारा नियंत्रित किया गया है; उपयोगकर्ता इसे स्वतंत्र रूप से बंद कर सकते हैं। - Rancher Desktop संगतता: issue #10722 दर्शाता है कि Docker Desktop के बजाय Rancher Desktop उपयोग करने पर
executeInWSL: trueWSL1 त्रुटि उत्पन्न करता है। यह अभी भी खुला मुद्दा है; Rancher Desktop उपयोगकर्ता इस सेटिंग को अस्थायी रूप से निष्क्रिय कर सकते हैं। - अनपेक्षित सक्रियण: issue #11005 बताता है कि
executeInWSL: trueस्थानीय Windows रेपो में अनजाने में Dev Container इनिशियलाइज़ेशन ट्रिगर कर सकता है। यह भी खुला है; प्रभावित उपयोगकर्ता इस सेटिंग को केवल विशिष्ट वर्कस्पेस में लागू करने पर विचार कर सकते हैं।
निष्कर्ष
Windows पर VS Code Dev Container के IO अधिक समस्या को लक्षणों से शुरू करके क्रमिक रूप से मूल कारण तक पहुँचने की आवश्यकता है। Process Monitor से मुख्य IO स्रोत Docker CLI के नेम्ड पाइप संचार की पुष्टि होती है, VS Code के अंतर्निहित टूल्स और Windows Performance Analyzer से कॉल फ़्रीक्वेंसी और विलंब का मात्रात्मक विश्लेषण होता है। मूल कारण विश्लेषण चार प्रमुख कारकों को उजागर करता है: Docker CLI की उच्च‑फ़्रीक्वेंसी सीमा‑पार पोलिंग मुख्य बॉटलनेक है, पोर्ट‑फ़ॉरवर्डिंग प्रोसेस लीक और Extension Host री‑कनेक्शन लूप पुष्टि किए गए सॉफ़्टवेयर बग हैं, और WSL2 की फ़ाइल‑सिस्टम सीमा‑पार IO प्लेटफ़ॉर्म‑स्तर की स्थायी सीमा है।
समाधानों में, dev.containers.executeInWSL: true सबसे कोर उपाय है, क्योंकि यह Docker CLI के Windows/WSL सीमा‑पार नेम्ड पाइप ओवरहेड को सीधे समाप्त करता है, जिससे उच्च‑फ़्रीक्वेंसी CLI कॉल का निष्पादन स्थान Windows से WSL के भीतर बदल जाता है और Unix socket के माध्यम से स्थानीय IPC होता है। अन्य उपाय (पोर्ट‑फ़ॉरवर्डिंग को सरल बनाना, Docker Desktop अनुकूलन, VS Code कॉन्फ़िगरेशन अनुकूलन) सहायक हैं और विभिन्न स्तरों पर अतिरिक्त प्रभाव को कम करते हैं। इस समस्या से ग्रस्त उपयोगकर्ताओं को पहले जांच प्रक्रिया के माध्यम से मूल कारण की पुष्टि करनी चाहिए, फिर प्राथमिक रूप से executeInWSL: true सक्षम करना चाहिए, और अंत में अपने विशिष्ट परिदृश्य के अनुसार उपयुक्त सहायक अनुकूलन रणनीतियों को अपनाना चाहिए।