เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 3) — เครื่องเสมือนที่บูตในไม่กี่วินาที: ทำไม WSL2, Windows Sandbox และคอนเทนเนอร์จึงเบา

เมื่อคุณสร้าง Windows VM ใน Hyper-V Manager มันใช้เวลาหลายสิบวินาทีในการเริ่มและผูกขาดหน่วยความจำหลายกิกะไบต์ แต่บนเครื่องเดียวกัน การพิมพ์ wsl คืนเชลล์ Linux ภายในไม่กี่วินาที และ Windows Sandbox เปิดเดสก์ท็อปใช้แล้วทิ้งในไม่กี่วินาทีเช่นกัน¹

ทั้งคู่ตั้งบน Windows hypervisor เดียวกัน (ตอนที่ 1 “Windows ของคุณรันอยู่ที่ไหนจริง ๆ?”) ในตอนที่ 2 เราเห็นว่ารากฐานนี้สร้างการแยกที่แข็งกว่าเคอร์เนลได้ แล้วทำไมอันหนึ่งหนักและอีกอันเบา?

คำถามที่ตอนสุดท้ายของซีรีส์ตอบมีเพียงข้อเดียว

VM เต็มตัวหนัก — แล้วทำไม WSL2 และ Windows Sandbox จึงเบา?

ผู้อ่านที่ตั้งใจ คือนักพัฒนาและผู้ปฏิบัติการที่ใช้ WSL2, Windows Sandbox และคอนเทนเนอร์ Windows สำหรับการพัฒนาและการตรวจ และอยากเข้าใจความเบากับข้อจำกัดจากกลไกขึ้นมา ข้อกำหนดเบื้องต้น คือ Windows 10/11 การเดินตามหมวด Windows Sandbox ต้องการรุ่น Pro, Enterprise หรือ Education (Home และ Windows Server ไม่มีฟีเจอร์นี้) พื้นความรู้ คือแนวคิดพาร์ติชันจากตอนที่ 1 ความยากคือระดับกลาง

1. สรุปก่อนเลย

VM น้ำหนักเบาเก็บเส้นการแยก (เคอร์เนลเฉพาะและขอบเขต hypervisor) ไว้ และทำให้น้ำหนักของ “สำเนาของ OS เกสต์ครบชุด” เบาลง Sandbox ใช้ Windows ของโฮสต์เองร่วมกัน WSL2 แทนที่เกสต์ด้วย Linux เล็กที่สร้างเฉพาะงาน และในทั้งสองกรณี หน่วยความจำไม่ใช่การจองคงที่ แต่เป็นการยืมและให้ยืมแบบไดนามิกกับโฮสต์

แหล่งของน้ำหนักของ VM เต็มตัวไม่ใช่การแยกเอง แต่เป็นการทำซ้ำ อิมเมจ OS อีกชุดบนดิสก์ เพจอีกชุดเท่ากับ OS อีกตัวใน RAM และการบูตเต็มอีกครั้งทุกครั้งที่เริ่ม VM น้ำหนักเบาตัดการทำซ้ำนั้นด้วยสองนโยบาย: “ใช้ร่วมสิ่งที่ปลอดภัยที่จะใช้ร่วม” (Sandbox) และ “หากใช้ร่วมไม่ได้ ให้สร้างใหม่ให้เล็ก” (WSL2)

flowchart TB
    accTitle: การใช้ร่วมสามชนิดที่รองรับ VM น้ำหนักเบา
    accDescr: อิมเมจ OS ที่ VM เต็มตัวเคยทำซ้ำถูกตัดด้วยการใช้ร่วมใน Sandbox และการย่อใน WSL2 หน่วยความจำที่เป็นการจัดสรรคงที่ตามค่าเริ่มต้น （หน่วยความจำไดนามิกคือข้อยกเว้น） กลายเป็นการยืมให้ยืมแบบไดนามิกกับโฮสต์ การเริ่มต้นถูกแทนที่ด้วยเคอร์เนลเบาและการตั้งค่าขั้นต่ำ เหลือเพียงขอบเขตการแยก
    heavy["VM เต็มตัว: การทำซ้ำ"] --> d1["ดิสก์: สำเนาอิมเมจ OS"]
    heavy --> more{"หน่วยความจำหรือการเริ่ม?"}
    more --> d2["หน่วยความจำ: ค่าเริ่มต้นคงที่"]
    more --> d3["การเริ่ม: บูตเต็ม"]
    d1 -->|ถูกแทนที่ด้วย| s1["ใช้ร่วม（Sandbox）"]
    s1 -.-> s1b["หรือย่อ（WSL2）"]
    d2 -->|ถูกแทนที่ด้วย| s2["การยืมจากโฮสต์แบบไดนามิก"]
    d3 -->|ถูกแทนที่ด้วย| s3["เคอร์เนลเบา + ขั้นต่ำ"]

ภาพ 1: โครงของคำตอบต่อ “hypervisor เดียวกัน แต่เบา” คือพวกมันหยุดทำซ้ำ ไม่ใช่หยุดแยก

ด้านล่างเราดู WSL2, Windows Sandbox และคอนเทนเนอร์ตามลำดับนั้น และว่าแต่ละอันตัดการทำซ้ำชนิดใด

2. สิ่งที่ VM เต็มตัวกำลังแบก

ในฐานะเส้นฐานสำหรับการเปรียบเทียบ นี่คือสิ่งที่ VM แบบดั้งเดิมแบก

• อิมเมจ OS อิสระ มันถือทุกไฟล์ของ OS เกสต์ในดิสก์เสมือน แม้โฮสต์มี Windows เดียวกัน ก็ไม่ใช้ร่วม
• การจัดสรรหน่วยความจำหยาบ ค่าเริ่มต้นของ VM แบบดั้งเดิมคือจัดสรรหน่วยความจำโฮสต์ที่ขนาดคงที่ กลไกอย่าง Hyper-V Dynamic Memory สามารถขยายและหดการจัดสรรในช่วงที่ตั้งได้ แต่วิธีปรับตามการเปลี่ยนแปลงของความต้องการมีจำกัด²
• การบูตเต็มเอนกประสงค์ เฟิร์มแวร์ ตัวโหลดบูต และชุดบริการเริ่มในลำดับเดียวกับบนเครื่องจริง

flowchart TB
    accTitle: สามภาระที่ VM เต็มตัวแบก
    accDescr: VM เต็มตัวแบกอิมเมจ OS อิสระ การจัดสรรหน่วยความจำที่คงที่ตามค่าเริ่มต้น และการบูตเต็มเอนกประสงค์ และสิ่งเหล่านั้นปรากฏเป็นต้นทุนในดิสก์ RAM และเวลาเริ่มต้น
    fullvm["VM เต็มตัว"] --> b1["อิมเมจ OS อิสระ"]
    fullvm --> more{"หน่วยความจำหรือบูต?"}
    more --> b2["ค่าเริ่มต้นหน่วยความจำคงที่"]
    more --> b3["บูตเอนกประสงค์"]
    b1 -.-> c1["ดิสก์เพิ่มสำหรับสำเนา"]
    b2 -.-> c2["ถือ RAM ที่ไม่ได้ใช้ด้วย"]
    b3 -.-> c3["ใช้เวลาหลายสิบวินาที"]

ภาพ 2: การแยกต้นทุนของ VM เต็มตัวถูกจ่ายไม่ใช่เพื่อการแยก แต่เพื่อความเป็นเอนกประสงค์และการทำซ้ำ

สิ่งเหล่านี้ไม่ใช่ข้อบกพร่อง แต่เป็นราคาของความเป็นเอนกประสงค์ที่ “คุณใส่เกสต์อะไรก็ได้” สำหรับงานอย่างการรัน Linux เก่าข้าง Windows Server ความเป็นเอนกประสงค์นั้นคือคุณค่า แต่สำหรับงานอย่าง “อยากรัน OS เดียวกับ (หรือที่กำหนดไว้ล่วงหน้ากับ) โฮสต์ ตอนนี้ สำหรับการพัฒนาหรือการตรวจ” ส่วนใหญ่เป็นสัมภาระที่เสียเปล่า VM น้ำหนักเบาวางสัมภาระนั้นลงด้วยการจำกัดวัตถุประสงค์

3. WSL2 — Utility VM กับเคอร์เนลที่สร้างเฉพาะงาน

3.1. โครงสร้าง: VM ที่ถูกจัดการและดิสทริบิวชันข้างใน

WSL2 คือกลไกที่รันเคอร์เนล Linux จริงใน utility VM น้ำหนักเบา³ มีสามจุด

• เคอร์เนลเป็นของจริง แต่เป็นผลิตภัณฑ์เฉพาะทาง เป็นเคอร์เนล Linux ที่ Microsoft สร้างจากสาขา Stable ปรับขนาดและประสิทธิภาพสำหรับ WSL2 แล้ว ตามมาตรฐานปัจจุบัน WSL ที่แจกผ่าน Microsoft Store เคอร์เนลถูกอัปเดตร่วมกับแพ็กเกจ WSL เองและนำไปใช้ด้วย wsl --update (บนการแจกในกล่องรุ่นเก่า มันมาผ่าน Windows Update)⁴ เพราะเป็นเคอร์เนลจริง ความเข้ากันได้ของการเรียกระบบจึงครบ และเครื่องมืออย่าง Docker รันตามที่เป็น
• VM อยู่เบื้องหลัง การสร้าง เริ่ม และหยุด VM ถูกจัดการโดย WSL ผู้ใช้เพียงเปิดเชลล์ ไม่มีหน้าจอตั้งค่า VM และไม่รู้สึกว่ารอการบูต⁴
• ดิสทริบิวชันคือคอนเทนเนอร์ใน VM ดิสทริบิวชันอย่าง Ubuntu และ Debian รันเป็นคอนเทนเนอร์ที่แยกใน VM ที่ถูกจัดการหนึ่งตัว พวกมันใช้เนมสเปซเครือข่ายและเคอร์เนลร่วมกัน ขณะที่เนมสเปซอย่าง PID, mount และ user ถูกแยก³

flowchart TB
    accTitle: สถาปัตยกรรม WSL2
    accDescr: Windows โฮสต์และ utility VM น้ำหนักเบานั่งข้างกันบน hypervisor เคอร์เนล Linux ที่ Microsoft สร้างรันใน VM และแต่ละดิสทริบิวชันรันเป็นคอนเทนเนอร์ที่แยกในนั้น
    hv["Hypervisor"] --> host["Windows โฮสต์"]
    hv --> uvm["Utility VM น้ำหนักเบา"]
    uvm --> lk["เคอร์เนล Linux （สร้างโดย Microsoft อัปเดตด้วย wsl --update）"]
    lk --> u1["Ubuntu （คอนเทนเนอร์）"]
    lk --> u2["Debian （คอนเทนเนอร์）"]
    host <-->|"Interop （คำสั่ง ไฟล์ เครือข่าย）"| uvm

ภาพ 3: คำตอบต่อ “WSL2 คือ VM หรือไม่” คือ “ใช่ แต่เป็น VM ที่ถูกจัดการอยู่เบื้องหลัง” และแม้คุณติดตั้งหลายดิสทริบิวชันก็ยังมี VM เพียงหนึ่งตัว

วินาทีที่คุณพิมพ์ wsl ฝั่งหลังมีลักษณะดังนี้

flowchart TB
    accTitle: จากรันคำสั่ง wsl ถึงเชลล์ที่คืนในไม่กี่วินาที
    accDescr: หาก utility VM ไม่ได้รันเมื่อรัน wsl VM น้ำหนักเบาและเคอร์เนล Linux จะเริ่ม หากกำลังรันอยู่แล้วจะถูกใช้ซ้ำ และเชลล์คืนในคอนเทนเนอร์ของดิสทริบิวชัน
    cmd["รัน wsl"] --> vmq{"Utility VM กำลังรันอยู่แล้วหรือไม่?"}
    vmq -->|ไม่| bootvm["เริ่ม VM น้ำหนักเบาและเคอร์เนล Linux （ไม่กี่วินาที）"]
    vmq -->|ใช่| reuse["ใช้ VM ที่กำลังรันอยู่ซ้ำ"]
    bootvm --> shell["เชลล์คืนในคอนเทนเนอร์"]
    reuse --> shell

ภาพ 4: การรอมีเพียงการเริ่ม VM ขั้นต่ำ และนี่คือจุดที่การวางสัมภาระของการบูตเต็มปรากฏ

3.2. ไฟล์ I/O: ฝั่งที่คุณวางทำให้เป็นคนละเรื่อง

หัวข้อที่มักขึ้นในการพูดถึงประสิทธิภาพของ WSL2 คือคุณวางไฟล์ไว้ที่ไหน

• การทำงานบนไฟล์ฝั่ง Linux (ดิสก์เสมือน ext4) เร็ว เพราะเคอร์เนล Linux พูดกับระบบไฟล์ของตนเองโดยตรง และการเร่งความเร็วสูงสุด 20 เท่าเทียบกับ WSL1 สำหรับการแตก tarball และ 2–5 เท่าสำหรับ git clone กับ npm install ถูกรายงานไว้⁴
• การทำงานบนไฟล์ฝั่ง Windows (/mnt/c เป็นต้น) ช้าเพราะผ่านการแชร์ไฟล์ที่ข้ามขอบเขต OS ประสิทธิภาพระบบไฟล์ข้าม OS คือรายการใหญ่หนึ่งข้อที่ WSL2 แย่กว่า WSL1⁴

ดังนั้นกฎคือ: “วางไฟล์โปรเจกต์ไว้ฝั่ง OS เดียวกับเครื่องมือที่ทำงานกับไฟล์นั้น”⁴ ที่เก็บที่คุณจัดการด้วยเครื่องมือบิลด์ Linux ไปฝั่ง Linux โซลูชันที่คุณบิลด์ใน Visual Studio ไปฝั่ง Windows

flowchart TB
    accTitle: ส้อมของเส้นทางไฟล์ I/O ของ WSL2
    accDescr: การเข้าถึงดิสก์เสมือน ext4 ฝั่ง Linux เป็นตรงจากเคอร์เนล Linux จึงเร็ว การเข้าถึงไฟล์ฝั่ง Windows ผ่านการแชร์ไฟล์ที่ข้ามขอบเขต OS จึงช้า
    io["การทำงานกับไฟล์ใน WSL2"] --> place{"ไฟล์อยู่ฝั่งใด?"}
    place -->|"ฝั่ง Linux （home เป็นต้น）"| ext4["I/O ตรงไปยังดิสก์เสมือน ext4"]
    place -->|"ฝั่ง Windows （/mnt/c เป็นต้น）"| p9["ผ่านการแชร์ที่ข้ามขอบเขต OS"]
    ext4 --> fast["เร็ว （ตัวอย่างสูงสุด 20 เท่าเทียบ WSL1）"]
    p9 --> slow["มีแนวโน้มช้า"]
    slow -.-> fix["แก้: วางไฟล์บน OS ที่ใช้"]

ภาพ 5: สิ่งที่ช้าคือเส้นทาง ไม่ใช่ WSL2 ดังนั้นการเปลี่ยนตำแหน่งที่วางไฟล์มักทำให้ปัญหาประสิทธิภาพหายไป

3.3. หน่วยความจำ: มันโต มันหด แต่ไม่ได้คืนทุกอย่างเสมอ

การใช้หน่วยความจำของ WSL2 (คุณเห็นเป็นโปรเซส vmmem ใน Task Manager) ไม่ใช่การจองคงที่ มันโตและหดตามการใช้งาน หน่วยความจำที่โปรเซสปล่อยแล้วถูกคืนให้ Windows อัตโนมัติภายใต้การตั้งค่า pageReporting ซึ่งเปิดตามค่าเริ่มต้น⁵ เพจที่ถือเป็นแคชไฟล์เคยไม่คืนให้ Windows จนกว่า VM จะออก⁴ ใน WSL ปัจจุบัน การตั้งค่าทดลอง .wslconfig ชื่อ autoMemoryReclaim (ค่าเริ่มต้นคือ dropCache) เรียกคืนแคชอัตโนมัติเช่นกัน⁵ ในสภาพแวดล้อมที่การตั้งค่านี้เป็น disabled หรือบน WSL เก่า แคชของเซสชันยาวอาจเหลือจนกว่า VM จะออกและกดหน่วยความจำโฮสต์ได้

flowchart TB
    accTitle: วิธีที่หน่วยความจำ WSL2 โต หด และถูกคืน
    accDescr: ความต้องการที่โตใน WSL2 ยกการใช้หน่วยความจำของ VM เพจที่โปรเซสปล่อยถูกคืนให้ Windows ภายใต้ pageReporting ซึ่งเปิดตามค่าเริ่มต้น แคชไฟล์ถูกเรียกคืนอัตโนมัติโดย autoMemoryReclaim ตามค่าเริ่มต้น แต่บนการตั้งค่าที่ปิดหรือ WSL เก่า มันเหลือจนกว่า VM จะออก และ wsl --shutdown คืนทุกอย่าง
    grow["ความต้องการหน่วยความจำโตใน WSL2"] --> vm["การใช้ vmmem โต"]
    vm --> freed{"เพจนั้นถูกปล่อยแล้วหรือไม่?"}
    freed -->|"โปรเซสปล่อย （เมื่อ pageReporting เปิด）"| ret["คืนให้ Windows อัตโนมัติ"]
    freed -->|ถือเป็นแคชไฟล์| amr["autoMemoryReclaim เรียกคืนอัตโนมัติ （ค่าเริ่มต้น）"]
    amr -.-> old2["บนการตั้งค่าที่ปิดหรือ WSL เก่า เหลือจนกว่า VM จะออก"]
    old2 --> sd["wsl --shutdown คืนทุกอย่าง"]

ภาพ 6: สิ่งที่ดูเหมือน “มันโตอย่างเดียว” ส่วนใหญ่คือแคช (และเมื่อ pageReporting ปิด เพจที่โปรเซสปล่อยด้วย) จึงรู้จักเส้นทางคืนก่อนตัดสินว่าเป็นการรั่ว

หากคุณอยากได้เพดานชัดเจน %UserProfile%\.wslconfig สามารถควบคุมหน่วยความจำรวมของ VM จำนวน CPU และสวอปได้⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

หลังเปลี่ยนการตั้งค่า ให้รีสตาร์ท VM ด้วย wsl --shutdown เพื่อให้มีผล การจัดสรรแบบไดนามิกนี้ — “เพดานคือการตั้งค่า การใช้จริงตามความต้องการ” — ถูกพาไปไกลกว่าในหัวข้อถัดไปคือ Windows Sandbox

4. Windows Sandbox — ใช้ Windows ของโฮสต์ซ้ำ

4.1. Dynamic Base Image: Windows ครบชุดใน 500 MB

Windows Sandbox คือเดสก์ท็อป Windows ใช้แล้วทิ้งที่แยกด้วย hypervisor ปิดแล้วทุกอย่างหาย ครั้งถัดไปเริ่มในไม่กี่วินาทีจากสถานะสะอาด¹

ปริศนาแรกคือดิสก์ มันบูต Windows ครบชุดได้ แต่อิมเมจฐานของ Sandbox มีเพียงประมาณ 500 MB หลังติดตั้ง และ 30 MB เมื่อบีบอัดตอนแจก² ความลับคือ dynamic base image

• ไฟล์ OS ส่วนใหญ่เปลี่ยนแปลงไม่ได้ จึงใช้สำเนาของโฮสต์ร่วมกันตามที่เป็น
• ไฟล์ที่เปลี่ยนแปลงได้จำนวนน้อยใช้ร่วมไม่ได้ จึงเก็บสำเนาสะอาดไว้ในอิมเมจฐาน
• ตอนเริ่ม ไฟล์ที่เปลี่ยนแปลงไม่ได้ของโฮสต์บวกสำเนาท้องถิ่นของไฟล์ที่เปลี่ยนแปลงได้ถูกรวมเพื่อประกอบอิมเมจ Windows ครบชุด²

กล่าวคือ Sandbox ไม่ดาวน์โหลดและไม่เก็บสำเนา Windows มันใช้ Windows ที่ติดตั้งบนโฮสต์อยู่แล้วซ้ำเพื่อเริ่ม

flowchart TB
    accTitle: วิธีประกอบ dynamic base image
    accDescr: ไฟล์ OS ที่เปลี่ยนแปลงไม่ได้จาก Windows โฮสต์ถูกใช้ร่วม มีเพียงไฟล์ที่เปลี่ยนแปลงได้ที่ถือเป็นสำเนาสะอาดในอิมเมจฐาน และทั้งคู่ถูกรวมเพื่อประกอบอิมเมจ Windows ครบชุดของ Sandbox
    hostw["Windows ครบชุดของโฮสต์"] --> imm["ไฟล์ OS ที่เปลี่ยนแปลงไม่ได้ （ส่วนใหญ่）"]
    hostw --> mut["ไฟล์ OS ที่เปลี่ยนแปลงได้ （ส่วนน้อย）"]
    imm -->|ใช้ร่วมตามที่เป็น| img["อิมเมจบูตของ Sandbox"]
    mut -->|เก็บสำเนาสะอาด| img
    img --> boot["บูตเป็น Windows ครบชุด"]
    img -.-> size["ต้องเก็บเพียงประมาณ 500 MB"]

ภาพ 7: รูปของการเลิกทำซ้ำดิสก์ไม่ใช่ “เป็นเจ้าของอีก Windows หนึ่ง” แต่เป็น “ประกอบจาก Windows ของโฮสต์”

องค์ประกอบนั้นคือสิ่งที่ทำให้วงจรชีวิตต่อไปนี้เป็นไปได้ สิ่งที่ถูกทิ้งคือสถานะท้องถิ่นใน Sandbox หากคุณแมปโฟลเดอร์ที่เขียนได้จากโฮสต์ในไฟล์ตั้งค่า .wsb การเปลี่ยนแปลงที่นั่นเหลือบนโฮสต์⁶

flowchart TB
    accTitle: วงจรชีวิตของ Windows Sandbox
    accDescr: การเริ่มเตรียม Windows สะอาดในไม่กี่วินาที หลังตรวจแอปหรือทดลองคุณปิดแล้วสถานะทั้งหมดใน Sandbox ถูกทิ้งจึงเริ่มสะอาดครั้งถัดไปด้วย แต่การเปลี่ยนแปลงต่อโฟลเดอร์โฮสต์ที่แมปเป็นเขียนได้ยังเหลือ
    launch["เริ่ม （ไม่กี่วินาที）"] --> clean["Windows สะอาด"]
    clean --> work["การตรวจแอปหรือการทดลอง"]
    work --> close2["ปิด"]
    close2 --> discard["ทิ้งสถานะทั้งหมดใน Sandbox"]
    discard -.-> mapped["การเปลี่ยนแปลงในโฟลเดอร์ที่แมปเป็นเขียนได้เหลือบนโฮสต์"]
    discard -->|การเริ่มครั้งถัดไป| launch

ภาพ 8: การกลับสู่สถานะสะอาดทุกครั้งได้ เพราะส่วนที่เปลี่ยนแปลงได้เป็นสำเนาใช้แล้วทิ้ง และการทิ้งมันเป็นส่วนของการออกแบบ

4.2. Direct Map: ntdll.dll เดียวกันคือเพจจริงเดียวกัน

ไม่เพียงดิสก์ แต่ RAM ก็ถูกใช้ร่วมเช่นกัน เพราะ Sandbox รันอิมเมจ OS เดียวกับโฮสต์ จึงใช้เทคนิคชื่อ “direct map” เพื่อให้สำหรับไบนารี OS มันใช้เพจหน่วยความจำจริงเดียวกันกับโฮสต์ เมื่อ ntdll.dll ถูกโหลดเข้าหน่วยความจำใน Sandbox มันชี้ไปที่เพจจริงเดียวกันกับไบนารีเดียวกันที่โหลดบนโฮสต์แล้ว โดยไม่เปิดเผยความลับของโฮสต์ให้ตกอยู่ในอันตราย มันได้รอยเท้าหน่วยความจำเล็กกว่า VM แบบดั้งเดิมมาก²

“ใช้เพจจริงเดียวกันร่วมกันระหว่างผู้ใช้หลายคน” — นั่นคือแนวคิดเดียวกับการแชร์ DLL ผ่าน section object ที่เราตามในตอนที่ 3 ของซีรีส์หน่วยความจำ (“Section Object และ Copy-on-Write”) กลไกนั้นเป็นการใช้ร่วมระหว่างโปรเซส Sandbox ทำข้ามขอบเขต VM

flowchart TB
    accTitle: การใช้เพจจริงร่วมผ่าน direct map
    accDescr: แอปบนโฮสต์และแอปใน Sandbox ใช้เพจหน่วยความจำจริงเดียวกันสำหรับไบนารี OS เช่น ntdll จึงลดการใช้หน่วยความจำ
    happ["แอปบนโฮสต์"] --> hva["ที่อยู่เสมือนฝั่งโฮสต์"]
    sapp["แอปใน Sandbox"] --> sva["ที่อยู่เสมือนฝั่ง Sandbox"]
    hva --> phys["เพจจริงเดียวกัน （ไบนารี OS เช่น ntdll.dll）"]
    sva --> phys
    phys -.-> save["ไม่ต้องทำซ้ำ RAM เท่ากับ OS"]

ภาพ 9: Direct map คือแนวคิดการใช้เพจร่วมที่เคยใช้ระหว่างโปรเซส นำไปใช้ข้ามขอบเขต VM

4.3. การยืมและให้ยืมหน่วยความจำ: เหมือนโปรเซสมากกว่า VM

เทียบกับการจัดสรรหน่วยความจำคงที่ของ VM แบบดั้งเดิม เทคโนโลยีคอนเทนเนอร์ที่ Sandbox นั่งอยู่ตัดสินการจัดสรรทรัพยากรแบบไดนามิกโดยร่วมมือกับโฮสต์ หากโฮสต์ขาดหน่วยความจำ มันเรียกคืนหน่วยความจำจากคอนเทนเนอร์ได้แบบเดียวกับที่เรียกคืนจากโปรเซสธรรมดา² Hyper-V Dynamic Memory ก็ขยายและหดการจัดสรรของ VM ในช่วงที่ตั้งได้เช่นกัน แต่ Sandbox ไปไกลกว่า: ความต่างคือมันยืมและให้ยืมบนสนามเดียวกับการจัดการหน่วยความจำของโฮสต์

flowchart TB
    accTitle: ความร่วมมือด้านหน่วยความจำระหว่างโฮสต์กับ Sandbox
    accDescr: ค่าเริ่มต้นของ VM แบบดั้งเดิมคือการจัดสรรเฉพาะขนาดคงที่พร้อมวิธีปรับจำกัด Sandbox กลายเป็นเป้าหมายการเรียกคืนเมื่อโฮสต์มีความกดดันด้านหน่วยความจำ และยืมให้ยืมหน่วยความจำบนสนามเดียวกับโปรเซสธรรมดา
    pressure["ความกดดันหน่วยความจำโฮสต์สูงขึ้น"] --> from{"เรียกคืนจากที่ไหน?"}
    from --> proc["Working Set ของโปรเซสธรรมดา"]
    from --> sbx["การใช้ของ Sandbox （คอนเทนเนอร์）"]
    proc --> relief["หน่วยความจำว่างถูกสำรอง"]
    sbx --> relief
    relief -.-> contrast["VM แบบดั้งเดิมมีวิธีปรับจำกัด"]

ภาพ 10: ในการยืมและให้ยืมหน่วยความจำ Sandbox ยืนฝั่งโปรเซสไม่ใช่ฝั่ง VM และยื่นหน่วยความจำเมื่อโฮสต์ลำบาก

ในตอนที่ 1 เราบอกว่า “ประสิทธิภาพของ VM ยังขึ้นกับฝั่งโฮสต์” แต่กับ VM น้ำหนักเบาเราเดินอีกขั้น: การจัดสรรหน่วยความจำเองคืองานร่วมกับโฮสต์ เหตุที่ Sandbox ใช้ได้ด้วยความรู้สึกของ “อีกแอปหนึ่ง” ไม่ใช่ “ผลิตภัณฑ์จำลองเสมือนหนัก” คือความร่วมมือนี้

ขั้นตอนที่เป็นรูปธรรมสำหรับการใช้ Sandbox ตรวจแอปธุรกิจอยู่ในบทความก่อนหน้า “เร่งการตรวจสอบแอปด้วย Windows Sandbox” บทความนี้คือกลไกข้างใต้สิ่งนั้น

5. คอนเทนเนอร์ — คุณลากเส้นการแยกที่ไหน

5.1. Process Isolation และ Hyper-V Isolation

คอนเทนเนอร์ Windows มีโหมดการแยกสองแบบตอนรัน อิมเมจถูกใช้ร่วม คุณเลือกด้วยแฟล็กตอนเริ่ม⁷

• Process isolation: คอนเทนเนอร์หลายตัวใช้เคอร์เนลร่วมกับโฮสต์และแยกผ่านการจำลองเสมือนรายเนมสเปซของระบบไฟล์ รีจิสทรี พอร์ตเครือข่าย พื้นที่ process-ID เนมสเปซ Object Manager เป็นต้น โดยพื้นฐานเป็นแนวทางเดียวกับคอนเทนเนอร์ Linux
• Hyper-V isolation: แต่ละคอนเทนเนอร์รันใน VM ที่ปรับให้เหมาะสมสูงและมีสิ่งที่เป็นเคอร์เนลเฉพาะในทางปฏิบัติ การมี VM วางการแยกระดับฮาร์ดแวร์ระหว่างคอนเทนเนอร์กับโฮสต์⁷

การแยกผ่านเนมสเปซอธิบายได้ว่าเป็นเวอร์ชันที่ทำอย่างละเอียดของเทคนิคที่เราเห็นในบทความการจำลองเสมือนของรีจิสทรี (“การ Redirect และการจำลองเสมือนของ Registry บน Windows”) — “แสดงความเป็นจริงต่างกันใต้ API เดียวกัน”

flowchart TB
    accTitle: Process isolation เทียบกับ Hyper-V isolation
    accDescr: ภายใต้ process isolation คอนเทนเนอร์ใช้เคอร์เนลร่วมกับโฮสต์และแยกผ่านเนมสเปซ ภายใต้ Hyper-V isolation แต่ละคอนเทนเนอร์มีเคอร์เนลเฉพาะใน VM ที่ปรับให้เหมาะสม
    subgraph pi ["Process isolation"]
        c1["คอนเทนเนอร์ A"] --> sk1["เคอร์เนลที่ใช้ร่วมกับโฮสต์"]
        c2["คอนเทนเนอร์ B"] --> sk1
    end
    subgraph hi ["Hyper-V isolation"]
        c3["คอนเทนเนอร์ C"] --> k3["เคอร์เนลเฉพาะ （ใน VM ที่ปรับแล้ว）"]
        c4["คอนเทนเนอร์ D"] --> k4["เคอร์เนลเฉพาะ （ใน VM ที่ปรับแล้ว）"]
    end
    sk1 ~~~ c3

ภาพ 11: แม้ด้วยอิมเมจคอนเทนเนอร์เดียวกัน ว่าคุณลากเส้นการแยกเหนือเคอร์เนลหรือแยกเคอร์เนลเองเป็นการเลือกที่ทำตอนเริ่ม

5.2. อันไหนที่คุณเรียกว่า “ขอบเขตความปลอดภัย” ได้

ความต่างระหว่างสองโหมดนี้ไม่ใช่เพียงเรื่องประสิทธิภาพ Microsoft ไม่ถือว่าคอนเทนเนอร์แบบ process-isolated เป็นขอบเขตความปลอดภัยที่แข็งแรง คอนเทนเนอร์ที่ถูกรักษา (พร้อมการตอบช่องโหว่) ในฐานะขอบเขตความปลอดภัยคือคอนเทนเนอร์ที่แยกด้วย hypervisor และ Hyper-V isolation คือสิ่งที่คุณควรเลือกในสถานการณ์หลายผู้เช่าที่เป็นปฏิปักษ์⁸

VBS ที่เราเห็นในตอนที่ 2 ก็เป็นการออกแบบที่สมมติว่า “เคอร์เนลถูกทะลุได้” แล้วถอยไปที่ขอบเขต hypervisor เกณฑ์เดียวกันใช้ในโลกของคอนเทนเนอร์ เส้นที่กักโค้ดที่ไม่น่าเชื่อถือถูกลากที่ขอบเขต hypervisor ไม่ใช่ด้านในของเคอร์เนลที่ใช้ร่วม

flowchart TB
    accTitle: วิธีเลือกการแยกจากว่าคุณเชื่อถือโค้ดมากเพียงใด
    accDescr: หากภาระงานเชื่อถือได้ ให้เอาความหนาแน่นและประสิทธิภาพด้วย process isolation หากโค้ดไม่น่าเชื่อถือหรือเป็นของคนอื่น ให้เลือกขอบเขต hypervisor เช่น คอนเทนเนอร์แบบ Hyper-V isolated Sandbox ที่เสริมความแข็งแล้วปิดเครือข่าย หรือ VM ที่แยก
    trust{"คุณเชื่อถือโค้ดนั้นได้หรือไม่?"} -->|ได้| dens["Process isolation （เน้นความหนาแน่น）"]
    trust -->|ไม่ได้ / โค้ดของคนอื่น| bound["เลือกขอบเขต hypervisor"]
    bound --> opt1["คอนเทนเนอร์แบบ Hyper-V isolated"]
    bound --> opt2["Sandbox ที่เสริมความแข็งหรือ VM ที่แยก"]

ภาพ 12: โหมดการแยกเป็นเรื่องความปลอดภัยก่อนเรื่องประสิทธิภาพ และความเชื่อถือตัดสินว่าคุณลากเส้นที่ไหน

อนึ่ง การรันคอนเทนเนอร์แบบ Hyper-V isolated ใน Hyper-V VM ทำให้ hypervisor ลึกสองชั้น — nested virtualization การซ้อนหนึ่งระดับรองรับในการผลิตบนสภาพแวดล้อมที่เข้าเงื่อนไข (โปรเซสเซอร์ Intel กับโฮสต์ Windows 10 / Windows Server 2016 หรือใหม่กว่า หรือโปรเซสเซอร์ AMD กับโฮสต์ Windows 11 / Windows Server 2022 หรือใหม่กว่า และรุ่นการตั้งค่า VM ที่สอดคล้องในแต่ละกรณี) และข้อกำหนดเบื้องต้นเพิ่มคือการตั้งค่าที่เปิดเผยส่วนขยายการจำลองเสมือนให้ VM ชั้นนอก (ExposeVirtualizationExtensions บน Set-VMProcessor ใน Hyper-V) การรัน WSL2 ใน VM รองรับแบบเดียวกัน⁹ ว่าคุณใช้ WSL2 หรือ Docker ใน VM พัฒนาบนคลาวด์ได้หรือไม่ ก็ถูกตัดสินด้วยว่าขนาดและการตั้งค่า VM นั้นเปิดเผย nested virtualization หรือไม่

flowchart TB
    accTitle: โครงสร้างของการจำลองเสมือนซ้อน
    accDescr: VM บนคลาวด์นั่งบน hypervisor ของโฮสต์จริง และข้างในมี hypervisor อีกตัว （การซ้อนที่รองรับคือหนึ่งระดับ） รันเพื่อรองรับ WSL2 และคอนเทนเนอร์แบบ Hyper-V isolated
    phys3["Hypervisor ของโฮสต์จริง"] --> cvm["VM บนคลาวด์ （เครื่องพัฒนา）"]
    cvm --> nhv["Hypervisor ใน VM （ระดับซ้อน 1）"]
    nhv --> w2["WSL2"]
    nhv --> hvc["คอนเทนเนอร์แบบ Hyper-V isolated"]
    nhv -.-> limit["การซ้อนที่รองรับคือหนึ่งระดับ"]

ภาพ 13: เหตุที่ wsl รันใน VM บนคลาวด์คือเพราะ nested virtualization ได้รับการรองรับอย่างเป็นทางการเพียงหนึ่งระดับ

5.3. สเปกตรัมของการแยกและความเบา

การเรียงตัวละครจนถึงตอนนี้บนแกนเดียว มีลักษณะดังนี้

flowchart TB
    accTitle: สเปกตรัมของความแข็งของการแยกและความเบา
    accDescr: คอนเทนเนอร์แบบ process-isolated เบาที่สุดแต่ใช้เคอร์เนลร่วม WSL2, Sandbox และคอนเทนเนอร์แบบ Hyper-V isolated คือ VM น้ำหนักเบาที่มีเคอร์เนลเฉพาะ （Sandbox ทำให้เบาด้วยการใช้ร่วม WSL2 ด้วยเคอร์เนลที่สร้างเฉพาะงาน） VM เต็มตัวหนักที่สุดแต่เอนกประสงค์
    ax["เบา ← → หนัก"] ~~~ p1
    p1["คอนเทนเนอร์แบบ process-isolated （เคอร์เนลร่วม）"] --> p2["WSL2, Sandbox, Hyper-V isolation （VM น้ำหนักเบาที่มีเคอร์เนลเฉพาะ）"]
    p2 --> p3["VM เต็มตัว （รันอะไรก็ได้ ถือสำเนาครบชุด）"]
    p1 -.-> n1["ขอบเขต: เนมสเปซ"]
    p2 -.-> n2["ขอบเขต: hypervisor"]
    p3 -.-> n3["ขอบเขต: hypervisor + ความเป็นอิสระครบ"]

ภาพ 14: กลุ่ม VM น้ำหนักเบาคือทางแก้กลางที่เก็บขอบเขต hypervisor และตัดการทำซ้ำ วิธีตัดแยกเป็นการใช้ร่วมสำหรับ Sandbox และเคอร์เนลที่สร้างเฉพาะงานสำหรับ WSL2

6. ดูด้วยตนเอง

ความเบาและการใช้ร่วมเป็นสิ่งที่คุณสังเกตบนเครื่องตรงหน้าได้

เวลาเริ่มต้นกับการขึ้นลงของหน่วยความจำ (WSL2) เปิด Task Manager แล้วลองสิ่งต่อไปนี้

# Felt startup time (the first run starts the VM; the second and later are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# End the whole VM and watch the memory come back
wsl --shutdown

หากคุณทำการบิลด์ใหญ่หรือการทำงานกับไฟล์ใน WSL2 vmmem โต และคุณสังเกตได้ว่ามันถูกคืนทั้งก้อนด้วย wsl --shutdown

ความต่างของความเร็วจากตำแหน่งที่วางไฟล์ (WSL2) วางที่เก็บเดียวกันฝั่ง Linux (~/repo) และฝั่ง Windows (/mnt/c/repo) แล้วเปรียบเทียบเวลาของ git status หรือการแตก ความต่างจากหมวด 3.2 จะปรากฏเป็นตัวเลข

พื้นหลังของ direct map (Sandbox) เริ่ม Sandbox แล้วดูการเพิ่มของหน่วยความจำใน Task Manager บนโฮสต์ การที่การเพิ่มยังเล็กกว่ามากเมื่อเทียบกับสิ่งที่ “อีก Windows หนึ่ง” จะทำให้คุณจินตนาการ คือผลของการใช้ร่วมที่กำลังเล่าเรื่อง หากจะขุดต่อเรื่องการแยกหน่วยความจำฝั่งโฮสต์ บทความเรื่องเครื่องมือ Sysinternals ที่ครอบคลุมวิธีใช้ RAMMap และ VMMap (“Process Explorer / Handle / VMMap ในทางปฏิบัติ”) มีประโยชน์ อย่างไรก็ตาม สิ่งเหล่านี้เป็นเครื่องมือสำหรับดูการจัดประเภทของโปรเซสฝั่งโฮสต์และหน่วยความจำจริง ไม่ได้สังเกตการแชร์กับเกสต์เองโดยตรง

โหมดการแยกคอนเทนเนอร์ (Docker / คอนเทนเนอร์ Windows) หากคุณมีสภาพแวดล้อมคอนเทนเนอร์ Windows ให้เริ่มอิมเมจเดียวกันด้วย docker run --isolation=process และ --isolation=hyperv แล้วเปรียบเทียบเวลาเริ่มต้นและลักษณะใน Task Manager (ภายใต้ process isolation โปรเซสในคอนเทนเนอร์ปรากฏในรายการโปรเซสของโฮสต์) แล้วคุณจะรู้สึกได้ว่าเส้นการแยกอยู่ที่ไหน⁷ อย่างไรก็ตาม process isolation สมมติว่าโฮสต์กับรุ่นอิมเมจตรงกัน และบน OS ไคลเอนต์จำกัดไว้ที่การใช้พัฒนาและทดสอบ Hyper-V isolation อนุญาตชุดการจับคู่ที่กว้างกว่า จึงเปรียบเทียบบนคู่ที่เข้ากันได้¹⁰

7. สามการอ่านผิดที่ควรเลี่ยงในทางปฏิบัติ

7.1. “WSL2 ช้า”

สิ่งที่ช้าไม่ใช่ WSL2 แต่เป็นเส้นทางไฟล์ I/O ที่ข้ามขอบเขต OS มีหลายกรณีที่เพียงย้ายโปรเจกต์ไปฝั่ง Linux ทำให้ความรู้สึกเป็นคนละเรื่อง⁴ ในทางกลับกัน การวางไฟล์ที่เครื่องมือ Windows จะแตะฝั่ง Linux ก็เสียเปรียบเท่ากันด้วยเหตุเดียวกัน ตัดสินด้วย “วางไว้บน OS เดียวกับฝั่งที่ใช้”

7.2. “vmmem ที่โตใหญ่คือการรั่วของหน่วยความจำ”

หน่วยความจำของ WSL2 โตและหดตามความต้องการ และส่วนที่ปล่อยแล้วถูกคืน บน WSL ปัจจุบัน แคชไฟล์ยังถูกเรียกคืนอัตโนมัติโดย autoMemoryReclaim (ค่าเริ่มต้นคือ dropCache) ดังนั้น “มันยังใหญ่” มักคลี่คลายตามเวลา⁵ หากยังเหลือ ให้ยืนยันว่า autoMemoryReclaim ไม่ได้ถูกตั้งเป็น disabled และว่า pageReporting ซึ่งรับผิดชอบการคืนส่วนที่ปล่อย ไม่ได้ถูกปิด (หรือว่าคุณไม่ได้ใช้ WSL เก่า) จากนั้นทำให้เพดานชัดเจนด้วย memory ใน .wslconfig หรือคืนทุกอย่างด้วย wsl --shutdown ที่ขอบเซสชัน วิธีคิดเรื่องการแยกว่าเป็นการรั่วหรือไม่รั่ว เหมือนกับในตอนเกริ่นของซีรีส์หน่วยความจำ “"การใช้หน่วยความจำ" ของ Windows หมายถึงอะไรจริง ๆ?”

7.3. “อยู่ในคอนเทนเนอร์ จึงปลอดภัย”

คอนเทนเนอร์แบบ process-isolated ใช้เคอร์เนลร่วม และตามเกณฑ์ของ Microsoft ไม่ใช่ขอบเขตความปลอดภัย⁸ สำหรับการรันโค้ดที่ไม่น่าเชื่อถือหรือตัวอย่าง ให้เลือกการแยกที่มีขอบเขต hypervisor เช่น คอนเทนเนอร์แบบ Hyper-V isolated, Windows Sandbox หรือ VM เฉพาะ อย่างไรก็ตาม ขอบเขต hypervisor ไม่ใช่การยกเว้นทั้งก้อน การตั้งค่าเริ่มต้นของ Windows Sandbox มีการเชื่อมต่อเครือข่ายเปิดอยู่ และอาจเปิดเผยแอปที่ไม่น่าเชื่อถือต่อเครือข่ายภายใน¹ หากคุณใช้รันตัวอย่าง ให้เสริมการแยกด้วยการปิดเครือข่ายและการส่งต่อคลิปบอร์ดในไฟล์ตั้งค่า .wsb หรือใช้ VM เฉพาะบนเครือข่ายที่แยก

8. สรุป — ปิดซีรีส์

จุดของตอนที่ 3

• ความเบาของ VM น้ำหนักเบาคือผลของ “การหยุดทำซ้ำ” ไม่ใช่ของ “การทำให้อ่อนการแยก”
• WSL2 รันเคอร์เนล Linux จริงใน utility VM น้ำหนักเบาที่ถูกจัดการ และดิสทริบิวชันถูกแยกเป็นคอนเทนเนอร์ใน VM นั้น³ กฎประสิทธิภาพคือวางไฟล์บน OS ที่ใช้ และหน่วยความจำโตและหดแบบไดนามิก โดยเพดานควบคุมได้ใน .wslconfig⁴⁵
• Windows Sandbox ใช้ไฟล์ OS ที่เปลี่ยนแปลงไม่ได้ของโฮสต์ร่วมผ่าน dynamic base image และยังใช้เพจจริงของไบนารี OS เป้าหมายร่วมผ่าน direct map จึงไม่ถือสำเนาของ Windows ครบชุด² คุณยังต้องการประมาณ 500 MB สำหรับไฟล์ที่เปลี่ยนแปลงได้ บวกหน่วยความจำของแอปที่คุณรันข้างใน
• โหมดการแยกคอนเทนเนอร์ถูกเลือกตอนเริ่ม และฝั่งที่เรียกว่าขอบเขตความปลอดภัยได้คือ Hyper-V isolation⁷⁸

และหากเราวางทั้งซีรีส์บนหน้าเดียว จะมีลักษณะดังนี้

• ตอนที่ 1: มีชั้น hypervisor ใต้ Windows และ OS โฮสต์เองรันเป็น root partition การไกล่เกลี่ยของ CPU และของหน่วยความจำ (SLAT) ทำโดยชั้นนี้โดยตรง และ I/O ของอุปกรณ์สังเคราะห์ถูกเป็นตัวกลางโดย root partition (VSP) ฝั่งไกลของ VMBus
• ตอนที่ 2: ชั้นนั้นถูกใช้ไม่เพียงเพื่อแยก VM จากกัน แต่ยังเพื่อลากขอบเขตที่แข็งกว่าเคอร์เนล (VTL) ใน OS เดียวกัน ความปลอดภัยเริ่มต้นของ Windows 11 สร้างบนสิ่งนี้
• ตอนที่ 3: บนชั้นเดียวกัน การตัดการทำซ้ำคือสิ่งที่ทำให้ “เครื่องเสมือนที่เริ่มในไม่กี่วินาที” เป็นไปได้ เส้นการแยกถูกเก็บไว้ และมันกลายเป็นเครื่องมือประจำวัน

flowchart TB
    accTitle: ภาพเดียวของทั้งซีรีส์
    accDescr: hypervisor ตรงบนฮาร์ดแวร์คือตอนที่ 1 การแยก VTL0 และ VTL1 ใน Windows โฮสต์คือตอนที่ 2 ความเบาของ WSL2, Sandbox และ Hyper-V isolation บนชั้นเดียวกันคือตอนที่ 3 คอนเทนเนอร์แบบ process-isolated ใช้เคอร์เนลโฮสต์ร่วม Sandbox ทำให้เบาด้วยการใช้ร่วม WSL2 ด้วยเคอร์เนลที่สร้างเฉพาะงาน
    hw3["ฮาร์ดแวร์"] --> hv3["Hypervisor （ตอนที่ 1）"]
    hv3 --> rp3["Windows โฮสต์ （การแยก VTL คือตอนที่ 2）"]
    hv3 --> lw3["WSL2, Sandbox, Hyper-V isolation （ตอนที่ 3）"]
    rp3 --> pc3["คอนเทนเนอร์แบบ process-isolated （เคอร์เนลร่วม）"]
    lw3 -.-> mech3["Sandbox ใช้ร่วม WSL2 ทำให้เบาด้วยเคอร์เนลเฉพาะงาน"]

ภาพ 15: ซ้อนสามตอนแล้วคุณได้ภาพรวมของพื้นใต้ Windows ปัจจุบัน

การจำลองเสมือนไม่ใช่เทคโนโลยีห้องเซิร์ฟเวอร์อีกต่อไป และไม่ใช่เทคโนโลยีเฉพาะคนที่ยืน VM ที่พื้นใต้ Windows ของคุณ มันรองรับทั้งความปลอดภัยและประสบการณ์การพัฒนาอย่างเงียบ ๆ — นั่นคือจุดที่เราอยู่ตอนนี้

บทความที่เกี่ยวข้อง

• เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 1) — Windows ของคุณรันอยู่ที่ไหนจริง ๆ? Hypervisor และพาร์ติชัน
• เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 2) — หน่วยความจำที่แม้เคอร์เนลก็มองไม่เห็น: กลไกของ VBS, HVCI และ Credential Guard
• เชิงลึกของหน่วยความจำ Windows (ตอนที่ 3) — Section Object และ Copy-on-Write: DLL และการแมปไฟล์คืออะไรจริง ๆ
• เร่งการตรวจสอบแอปด้วย Windows Sandbox
• กับดักการ Redirect และการจำลองเสมือนของ Registry 32-bit/64-bit — Wow6432Node และปัญหา “ค่าที่ฉันเขียนไม่มีอยู่”

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับจัดสภาพแวดล้อมพัฒนาที่ใช้ WSL2 และคอนเทนเนอร์ ออกแบบสภาพแวดล้อมตรวจแอป Windows และสอบสวนประสิทธิภาพกับความเข้ากันได้ในสภาพแวดล้อมจำลองเสมือน

• การพัฒนาแอปพลิเคชัน Windows
• การตรวจสอบบั๊กและวิเคราะห์หาสาเหตุที่แท้จริง
• การใช้ประโยชน์และโยกย้ายสินทรัพย์ซอฟต์แวร์เดิม
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

WSL2 คือ VM หรือไม่

ใช่ WSL2 รันเคอร์เนล Linux จริงที่ Microsoft สร้างใน utility VM น้ำหนักเบา VM ถูกจัดการโดย WSL เบื้องหลัง ดังนั้นการออกแบบไม่เคยทำให้ผู้ใช้คิดเรื่องการตั้งค่า VM หรือการรอการบูต แต่ละดิสทริบิวชัน Linux รันเป็นคอนเทนเนอร์ที่แยกใน VM ที่ถูกจัดการนี้

ทำไมการทำงานกับไฟล์ใต้ /mnt/c ใน WSL2 จึงช้า

เพราะการเข้าถึงจากเคอร์เนล Linux ของ WSL2 ไปยังระบบไฟล์ฝั่ง Windows ผ่านการแชร์ไฟล์ที่ข้ามขอบเขต OS การทำงานบนระบบไฟล์ Linux (ดิสก์เสมือน ext4) เร็ว ดังนั้นกฎคือเก็บไฟล์โปรเจกต์ไว้ฝั่ง OS เดียวกับเครื่องมือที่ทำงานกับไฟล์นั้น

การใช้หน่วยความจำสูงของโปรเซส vmmem คือการรั่วหรือไม่

ในกรณีส่วนใหญ่ไม่ใช่การรั่ว หน่วยความจำของ WSL2 โตและหดตามการใช้งาน และหน่วยความจำที่โปรเซสปล่อยแล้วถูกคืนให้ Windows ภายใต้การตั้งค่า pageReporting ซึ่งเปิดตามค่าเริ่มต้น เพจแคชไฟล์ก็ถูกเรียกคืนอัตโนมัติโดย WSL ปัจจุบันผ่าน autoMemoryReclaim ใน .wslconfig (ค่าเริ่มต้นคือ dropCache) ในสภาพแวดล้อมที่การตั้งค่าเหล่านี้ถูกปิด หรือบน WSL เก่า หน่วยความจำอาจเหลือจนกว่า VM จะออก ในกรณีนั้นตั้งเพดานด้วยการตั้งค่า memory หรือคืนด้วย wsl --shutdown

Windows Sandbox บูต Windows ครบชุดจากดิสก์ไม่กี่ร้อยเมกะไบต์ได้อย่างไร

ผ่านกลไกชื่อ dynamic base image มันใช้ร่วมไฟล์ OS ที่เปลี่ยนแปลงไม่ได้จาก Windows ที่ติดตั้งบนโฮสต์อยู่แล้ว และเก็บสำเนาสะอาดของไฟล์ที่เปลี่ยนแปลงได้จำนวนน้อยเท่านั้น ทำให้ประกอบอิมเมจที่บูตได้ครบชุดโดยไม่ต้องเก็บสำเนา Windows ทั้งก้อน

คอนเทนเนอร์ปลอดภัยกว่า VM หรือไม่

ขึ้นกับโหมดการแยก คอนเทนเนอร์แบบ process-isolated ใช้เคอร์เนลร่วมกับโฮสต์ และ Microsoft ไม่ถือว่านี่เป็นขอบเขตความปลอดภัยที่แข็งแรง เมื่อคุณจัดการโค้ดที่เป็นปฏิปักษ์ คุณต้องการ Hyper-V isolation ซึ่งให้แต่ละคอนเทนเนอร์มีเคอร์เนลเฉพาะของตนเอง

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก