ความลึกของหน่วยความจำ Windows (ตอนที่ 2) — ชีวิตของเพจทางกายภาพ: ห้าบัญชีและเรื่องจริงของไฟล์เพจ

ในบทความก่อน «ความลึกของหน่วยความจำ Windows (ตอนที่ 1) — ช่วงที่ที่อยู่เสมือนกลายเป็น RAM จริง» เราตามจนถึงตอนที่ตัวจัดการเพจฟอลต์จัดสรรเพจทางกายภาพเมื่อแตะเพจที่ Commit แล้วครั้งแรก แล้วเพจทางกายภาพนั้นไปไหนหลังจากถูกเอาออกจาก Working Set

คำอธิบายมักย่อเหลือ «ถูกไล่ไปไฟล์เพจ» แต่จริง ๆ มีหลายสถานะก่อนและหลัง เพจที่ไม่ได้แก้ไขอาจย้ายไป Standby โดยทิ้งเนื้อหาไว้ เพจที่แก้ไขแล้วรอการเขียนกลับที่ Modified ก่อน เมื่อนำกลับมาใช้ อาจผ่าน Free หรือ Zeroed และถ้าต้องการเนื้อหาเดิมอีก อาจกลับจาก Standby ด้วยซอฟต์ฟอลต์

บทความนี้ใช้ฐานข้อมูล PFN เป็นแกนและตาม เพจทางกายภาพหนึ่งแผ่นเคลื่อนผ่าน Active, Modified, Standby, Free และ Zeroed อย่างไร การอ่านตัวเลขเองถือว่าบทความแนะนำ «What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File» เป็นพื้นฐาน

«ความลึกของหน่วยความจำ Windows» — ทั้ง 3 ตอน

1. ตอนที่ 1: ที่อยู่เสมือนและเพจฟอลต์
   เราตามว่าเพจเสมือนที่ Commit แล้วได้ RAM จริงเมื่อใด
2. ตอนที่ 2 (บทความนี้): ชีวิตของเพจทางกายภาพ
   เราตามการเปลี่ยนสถานะของเพจที่ออกจาก Working Set และบทบาทของไฟล์เพจ
3. ตอนที่ 3: อ็อบเจ็กต์เซกชันและคัดลอกเมื่อเขียน
   เราตามกลไกที่ DLL, การแมปไฟล์ และหน่วยความจำร่วมใช้เพจทางกายภาพร่วมกัน

คำถามที่ตอนที่ 2 ตอบมีเพียงข้อเดียว

เพจทางกายภาพที่ออกจาก Working Set หายไป ไปดิสก์ หรือยังอยู่ใน RAM

ผู้อ่านเป้าหมาย คือนักพัฒนาและผู้ปฏิบัติงานที่อยากเข้าใจจากกลไกว่าทำไม Available สูงแล้ว Standby ก็สูง พฤติกรรมหลังตัด Working Set การตั้งไฟล์เพจ และการบีบอัดหน่วยความจำ ข้อกำหนด คือ Windows 10/11 หรือ Windows Server ปัจจุบัน และ พื้นหลังที่ต้องมี คือพื้นฐาน Working Set, Commit และซอฟต์/ฮาร์ดฟอลต์ ระดับความยากระดับกลาง เราใช้คำภายในอย่าง PFN และรายการเพจ แต่โฟกัสสิ่งที่สังเกตด้วย RAMMap และ PerfMon ได้โดยไม่ต้องใช้ดีบักเกอร์เคอร์เนล

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

เริ่มจากจุดที่อ่านผิดได้ง่าย

• เพจที่ออกจาก Working Set ไม่จำเป็นต้องหายทันที
  เพจสะอาดอยู่ที่ Standby และกลับได้โดยไม่ต้องอ่านดิสก์ถ้าต้องการเนื้อหาเดิม
• เพจที่แก้ไขแล้วนำกลับมาใช้ทันทีไม่ได้
  เนื้อหาส่วนตัวนำกลับมาใช้ได้หลังจากเขียนกลับไฟล์เพจได้ ไฟล์ที่แมปหลังจากเขียนกลับไฟล์ที่เกี่ยวข้องได้ และอื่น ๆ
• Available รวม Standby
  Standby เป็นแคชที่ยังถือเนื้อหา และในเวลาเดียวกันเป็นผู้สมัครนำกลับมาใช้ที่หยิบได้ทันทีถ้าจำเป็น¹
• การเขียนลงไฟล์เพจไม่ใช่งานชุดที่เริ่มเมื่อ RAM หมดสนิทเท่านั้น
  มันเดินในพื้นหลังตามรายการ Modified และความกดดันหน่วยความจำ²³
• ไฟล์เพจไม่ใช่แค่ «RAM ช้า»
  มันขยาย Commit Limit เป็นที่เก็บสำรองของเพจส่วนตัวที่แก้ไขแล้ว และรองรับดัมพ์เมื่อล่ม⁴
• ปิดไฟล์เพจไม่แก้หน่วยความจำรั่ว
  Commit Limit ลดลง และอาจเสียทางเลือกใช้ RAM ให้เกิดประโยชน์และความสามารถจับดัมพ์

ประโยคเดียว: ก่อน Windows ทิ้งเพจ มันตรวจความเป็นไปได้ว่าจะต้องการอีก และมีที่ให้กู้เนื้อหาเดิมหรือไม่

2. ฐานข้อมูล PFN — สมุดบัญชีฝั่ง RAM จริง

PTE ที่เห็นในตอนที่ 1 แทนการแปลจากเพจเสมือนเป็นเพจทางกายภาพ สมุดบัญชีที่มองจากฝั่งเพจทางกายภาพและตามว่า «เพจ RAM นี้ใช้อะไรอยู่ตอนนี้» คือฐานข้อมูล PFN PFN ย่อจาก Page Frame Number: RAM จริงที่นับเป็นหน่วยเพจ

รายการ PFN ตามแนวคิดติดตามข้อมูลต่อไปนี้

• สถานะปัจจุบันของเพจทางกายภาพ
• นับการอ้างอิงและนับการแบ่งใช้
• PTE ที่สอดคล้อง
• ว่าถูกแก้ไขหรือไม่
• อยู่รายการเพจใด
• ข้อมูลเกี่ยวกับโหนด NUMA และลำดับความสำคัญ

ใน WinDbg !pfn แสดงข้อมูลของ PFN ที่ระบุ และ !memusage แสดงการใช้หน่วยความจำทางกายภาพและผลรวมแต่ละรายการเพจ⁵⁶ ถ้าอยากสังเกตโลกเดียวกันโดยไม่ใช้ดีบักเกอร์เคอร์เนล มี Sysinternals RAMMap Use Counts แสดงจุดประสงค์และรายการเพจ Priority Summary แสดง Standby ตามลำดับความสำคัญ และ Physical Pages แสดงการใช้ต่อเพจ⁷

3. เชื่อมห้าสถานะในภาพเดียว

บทความนี้จัดการการไหลของเพจทางกายภาพเป็นห้าสถานะต่อไปนี้แบบง่าย ๆ ตามความเคร่งครัด Windows ปัจจุบันมีสถานะและรายการที่ไม่ได้วาดที่นี่ — Standby ตามลำดับความสำคัญ, Transition, Bad และอื่น ๆ — และ Active หมายถึงสถานะถูกอ้างจาก Working Set หรือคล้ายกันผ่าน PTE ที่ใช้ได้ มากกว่า «รายการ Active» เดี่ยว ถึงอย่างนั้นภาพนี้มีประโยชน์เกินพอสำหรับการอ่านพฤติกรรมหน่วยความจำของแอป

ภาพ 1: เพจที่ถูกอ้างใน Working Set ไป Standby ถ้าสะอาด และไป Modified ถ้าสกปรก เนื้อหาเดิมกลับได้ งานอื่นนำเพจกลับมาใช้โดยตรง หรือผ่าน Free/Zeroed เพื่อการจัดสรรที่ต้องการศูนย์

จุดสำคัญที่สุดในภาพนี้คือ การออกจาก Working Set กับการเสียเนื้อหาไม่ใช่เรื่องเดียวกัน และเมื่อเอาเพจ Standby ไปงานอื่น ไม่จำเป็นต้องผ่าน Free/Zeroed ตามลำดับ ถ้าจะส่งให้โหมดผู้ใช้เป็นเพจส่วนตัว demand-zero ใหม่ ต้องลบเนื้อหาเก่า ถ้าทั้งเพจจะถูกเขียนทับ เช่น ปลายทางอ่านไฟล์ สามารถถอดอัตลักษณ์ Standby แล้วนำเพจกลับมาใช้โดยตรง

4. Active / Valid — เพจทางกายภาพที่อ้างได้ตอนนี้

เพจ Active/Valid ถูกอ้างจาก Working Set ของโปรเซสหรือจากพื้นที่ระบบผ่าน PTE ที่ใช้ได้ CPU ถึงด้วยการแปลที่อยู่ธรรมดา ดังนั้นการเข้าถึงนั้นเองไม่ต้องการเพจฟอลต์

อย่างไรก็ตาม ไม่มีการรับประกันว่าเพจจะยัง Active เพื่อรักษาหน่วยความจำที่ใช้ได้ ตัวจัดการหน่วยความจำดูขนาด Working Set ความใกล้ของการใช้เพจ และปัจจัยคล้ายกัน แล้วตัดเพจที่เป็นผู้สมัคร เอกสาร Working Set ของ Microsoft ก็อธิบายว่าตัวจัดการหน่วยความจำเอาเพจออกจาก Working Set เพื่อสร้างหน่วยความจำที่ใช้ได้⁸

4.1. การตัดไม่ใช่การปล่อย

สิ่งที่การตัด Working Set เปลี่ยนหลัก ๆ คือ สถานะประจำที่อ้างผ่าน PTE ที่ใช้ได้ทันที แยกสี่ข้อต่อไปนี้เป็นเหตุการณ์คนละอย่าง

• เอาออกจาก Working Set
• ปล่อย Commit
• ปล่อยช่วงที่อยู่เสมือน
• สูญเสียข้อมูลต้นฉบับ

การรัน EmptyWorkingSet หรือ «Trim Working Set» ของเครื่องมือไม่แทน VirtualFree หรือการปล่อยฮีป ถ้าแตะเพจเดิมอีก มันกลับด้วยซอฟต์ฟอลต์จาก Standby หรือฮาร์ดฟอลต์จากที่เก็บสำรอง ดังนั้น «ฉันทำให้ Working Set เล็กลง» ไม่ได้หมายความว่า «ฉันแก้รอยรั่วแล้ว»

5. เพจสะอาดไป Standby

แม้เพจถูกเอาออกจาก Working Set ถ้าเนื้อหายังตรงกับไฟล์ต้นฉบับหรือมีที่เก็บสำรองที่ปลอดภัยแล้ว สามารถวางที่ Standby ได้ ตัวอย่างที่เป็นตัวแทนมีดังนี้

• รหัส EXE/DLL ที่ไม่ได้แก้ไข
• ไฟล์แมปในหน่วยความจำที่ไม่ได้แก้ไข
• เพจส่วนตัวที่เขียนกลับแล้ว
• ข้อมูลที่เหลือในแคชไฟล์

เพจ Standby รักษาความสอดคล้องกับเนื้อหาก่อน เมื่อโปรเซสเดิมหรือโปรเซสอื่นต้องการเนื้อหานั้น ถ้าเพจยังไม่ถูกนำกลับมาใช้ ซอฟต์ฟอลต์ที่ต่อ PTE ใหม่ก็พอให้กู้คืน

ในทางกลับกัน ถ้าการจัดสรรอื่นต้องการเพจทางกายภาพ สามารถทิ้งอัตลักษณ์ Standby เก่าแล้วนำเพจกลับมาใช้ ถ้าปลายทางการนำกลับมาใช้เป็นเพจส่วนตัวโหมดผู้ใช้ที่ต้องเริ่มต้นด้วยศูนย์ จะเตรียมเพจ Zeroed ถ้าทั้งเพจจะถูกเขียนทับด้วยเนื้อหาไฟล์หรือคล้ายกัน สามารถกำหนดใหม่โดยตรงโดยไม่ต้องทำศูนย์

สองด้านนี้เองคือเหตุผลที่ Standby เป็น ทั้งแคชและ Available

5.1. ทำไม Available รวม Standby

MEMORYSTATUSEX.ullAvailPhys แทนหน่วยความจำทางกายภาพที่นำกลับมาใช้ทันทีได้โดยไม่เขียนลงดิสก์ และเป็นผลรวมของ Standby, Free และ Zeroed¹

flowchart LR
    accTitle: สามรายการเพจที่ประกอบ Available
    accDescr: หน่วยความจำทางกายภาพที่ใช้ได้คือผลรวมของ Standby, Free และ Zeroed เพจ Active ที่ถูกอ้างใน Working Set ไม่รวมอยู่
    standby["Standby（ผู้สมัครนำกลับมาใช้ที่เก็บเนื้อหา）"] --> avail["Available（หน่วยความจำทางกายภาพที่ใช้ได้）"]
    free["Free（ไม่ได้ใช้ ยังไม่ทำศูนย์）"] --> avail
    zeroed["Zeroed（ไม่ได้ใช้และทำศูนย์แล้ว）"] --> avail
    active["Active（ถูกอ้างใน Working Set）"] -.->|ไม่รวม| avail

ภาพ 2: Available คือผลรวมของ Standby, Free และ Zeroed Standby ที่ยังถือเนื้อหาก็นับเป็น «ใช้ได้» ด้วย

ดังนั้นไม่ขัดแย้งเมื่อตัวจัดการงานแสดง «Free ต่ำ แต่ Cached/Standby สูง และ Available พอ» Windows ไม่ปล่อย RAM ว่างให้ว่างเปล่า มันทิ้งไฟล์และรหัสที่เพิ่งใช้ไว้ที่ Standby เพื่อนำกลับมาใช้เร็วเป็นแคชถ้าจำเป็น และหยิบถ้างานอื่นต้องการ

อย่าสรุปว่า «Free ต่ำ จึงขาดหน่วยความจำทันที» ให้ดู Available, Commit, ฮาร์ดฟอลต์ และความล่าช้าในการประมวลผลพร้อมกัน

6. เพจสกปรกรอที่ Modified

เมื่อแอปเขียนลงเพจ เนื้อหานั้นไม่ตรงกับที่เก็บสำรองเดิมอีก การเขียนทับเพจสกปรกนั้นเพื่องานอื่นจะเสียข้อมูล ดังนั้นเพจที่แก้ไขแล้วและถูกเอาออกจาก Working Set รอการเขียนกลับที่ Modified

ปลายทางการเขียนกลับขึ้นกับชนิดของเพจ

เอกสารไฟล์เพจของ Microsoft ก็อธิบายว่า .dll, .exe และไฟล์ธรรมดาที่มีอยู่บนดิสก์แล้วไม่ต้องเขียนซ้ำลงไฟล์เพจ และข้อมูลที่แก้ไขโดยไม่มีสำเนอดิสก์ต้นเป็นผู้สมัครไฟล์เพจ²

6.1. Modified Page Writer

Modified Page Writer เป็นเวิร์กเกอร์ระบบที่สแกนเพจสกปรกที่สำรองด้วยไฟล์เพจซึ่งตัวจัดการหน่วยความจำติดตาม และเขียนออกไปไฟล์เพจ³ ฝั่งไฟล์ที่แมปมีเส้นทางอย่าง Mapped Page Writer ที่ร่วมกับระบบไฟล์และตัวจัดการแคชเพื่อเขียนกลับไฟล์ที่เกี่ยวข้อง

จุดสำคัญคือการเขียนออกไม่ใช่แบบ «ไม่ทำอะไรจนกว่า RAM จะเป็น 0 ไบต์» Windows เตรียมเพจที่นำกลับมาใช้ในอนาคตได้ในพื้นหลัง ตามรายการ Modified, Available, สถานะไฟล์เพจ และปัจจัยคล้ายกัน เมื่อเขียนกลับเสร็จและไม่มีอ้างอิงที่ใช้ได้อื่น เพจเดินไป Standby พร้อมเนื้อหาเดิม

flowchart TB
    accTitle: เส้นทางเขียนกลับของเพจที่แก้ไขแล้ว
    accDescr: เพจที่แก้ไขแล้วซึ่งออกจาก Working Set รอที่รายการ Modified สำหรับเพจส่วนตัวถ้ามีไฟล์เพจ Modified Page Writer เขียนลงไฟล์เพจ และเพจของไฟล์ที่แมปถูกเขียนกลับไฟล์ข้อมูลที่เกี่ยวข้องโดย Mapped Page Writer หรือคล้ายกัน แล้วเดินไป Standby พร้อมเนื้อหา
    dirty["เพจที่แก้ไขแล้วซึ่งออกจาก Working Set"] --> modified["รอเขียนกลับที่รายการ Modified"]
    modified -->|"เพจส่วนตัว（เมื่อตั้งไฟล์เพจ）"| mpw["Modified Page Writer เขียนลงไฟล์เพจ"]
    modified -->|เพจของไฟล์ที่แมป| mapped["Mapped Page Writer หรือคล้ายกันเขียนกลับไฟล์ที่เกี่ยวข้อง"]
    mpw --> standby["หลังเขียนกลับ ไป Standby พร้อมเนื้อหา"]
    mapped --> standby

ภาพ 3: ปลายทางการเขียนกลับถูกกำหนดด้วยชนิดเพจ และทั้งสองเส้นทางเดินในพื้นหลัง บนระบบที่ปิดไฟล์เพจ ฝั่งเพจส่วนตัวไม่มีปลายทางเขียนกลับ ดังนั้นเพจส่วนตัวที่แก้ไขแล้วยังอยู่ใน RAM

6.2. แยกเอาต์พุตเพจกับ I/O เฉพาะไฟล์เพจ

ตัวนับต่อไปนี้สับสนง่าย ให้ยืนยันความหมาย

• Memory\\Page Writes/sec: จำนวน I/O เขียนเพจที่ออกเพื่อปล่อยหน่วยความจำทางกายภาพ
• Memory\\Pages Output/sec: จำนวนเพจที่เขียนลงดิสก์จากการเขียนนั้น
• Memory\\Page Reads/sec: จำนวน I/O อ่านดิสก์ที่ออกเพื่อแก้ฮาร์ดฟอลต์
• Memory\\Pages Input/sec: จำนวนเพจที่เข้า RAM จากการอ่านนั้น

สังเกตว่า Page Writes/sec และ Pages Output/sec ไม่ใช่ตัวนับที่ระบุไฟล์เพจอย่างเดียว พวกมันขึ้นได้บนเส้นทางที่เขียนกลับเพจสกปรกที่สำรองด้วยไฟล์ เช่น ไฟล์ที่แมป ในทางกลับกัน ฝั่งอินพุตก็ไม่แยกไฟล์เพจ, DLL, EXE และไฟล์แมปในหน่วยความจำ² ถ้าต้องการระบุ I/O เฉพาะ pagefile.sys อย่าประมาณจากสี่ตัวนับนี้เพียงอย่างเดียว บันทึก File I/O และ Disk I/O ด้วย ETW/WPA แล้วยืนยันไฟล์เป้าหมายโดยจับคู่ FileObject และ FileName⁹

อีกจุดหนึ่ง: เขียนลงไฟล์เพจก่อนไม่ได้หมายความว่าอ่านกลับจากดิสก์ทันที ถ้าไม่เข้าถึงเพจ สามารถเอาเพจที่เขียนกลับแล้วออกจาก RAM และให้หน่วยความจำทางกายภาพแก่เพจที่ใช้บ่อยกว่า

7. ความต่างของ Standby, Free และ Zeroed

7.1. Standby

สถานะที่ยังรักษาความสอดคล้องกับเนื้อหาก่อน

• ถ้าต้องการเนื้อหาเดิม กลับด้วยซอฟต์ฟอลต์ได้
• ถ้างานอื่นต้องการ สามารถทิ้งอัตลักษณ์เก่าแล้วนำกลับมาใช้
• มีรายการ Standby ตามลำดับความสำคัญ

7.2. Free

ความสอดคล้องที่ใช้ได้กับเนื้อหาก่อนหายไป และจัดสรรเพจได้ อย่างไรก็ตาม รูปแบบบิตเก่าอาจยังอยู่ในเพจ การส่งให้โหมดผู้ใช้ตามที่เป็นเสี่ยงรั่วข้อมูลของโปรเซสก่อน

7.3. Zeroed

เนื้อหาเป็นศูนย์ และส่งเพจได้อย่างปลอดภัยเป็นเพจโหมดผู้ใช้ใหม่ ฟอลต์ demand-zero ในตอนที่ 1 เป็นกรณีตัวแทนของการได้เพจ Zeroed ที่ใช้ได้แล้วผูกกับ PTE การเตรียมจาก Free ไป Zeroed ทำตามความต้องการและสถานะระบบ

ดังนั้นแม้ «Free» และ «Zeroed» จะดูไม่ได้ใช้ทั้งคู่ แต่ต่างกันที่ความพร้อมด้านความปลอดภัย

8. ที่เก็บการบีบอัดหน่วยความจำ — สร้างปลายทางอีกแห่งใน RAM

ตั้งแต่ Windows 10 เมื่อมีความกดดันหน่วยความจำ ตัวจัดการหน่วยความจำในบางกรณีบีบเพจที่ใช้น้อยใน RAM แทนการเขียนลงดิสก์ทันที ชุดเพจที่บีบนั้นคือที่เก็บการบีบอัด

ในอิมพลีเมนต์ Windows 10 ช่วงแรก ที่เก็บการบีบอัดนับใน Working Set ของโปรเซส System แต่บน Windows ปัจจุบันปรากฏในรายการโปรเซสของดีบักเกอร์เป็นโปรเซส Memory Compression แยก ดังนั้นเมื่อสำรวจปริมาณการบีบอัดปัจจุบัน อย่าตามแค่ Working Set ของโปรเซส System จุดประสงค์เอง — เก็บแอปไว้ในหน่วยความจำทางกายภาพมากขึ้นและลด I/O ดิสก์ — ไม่เปลี่ยน¹⁰¹¹

อย่างไรก็ตามจำจุดต่อไปนี้

• เพจที่บีบแล้วยังใช้ RAM
• การบีบและคลายมีต้นทุนซีพียู
• การบีบอัดไม่ลบคำสัญญา Commit
• ไม่มีลำดับคงที่ «บีบอัดเสมอ แล้วค่อยไฟล์เพจ»
• นโยบายเปลี่ยนตามชนิดเพจ ความกดดัน และประวัติการเข้าถึง

«กำลังใช้ (บีบอัดแล้ว)» ในตัวจัดการงานไม่ได้หมายความว่าการบีบอัดเทหน่วยความจำทางกายภาพจนว่าง ที่เก็บการบีบอัดไม่ใช่ฟีเจอร์ที่ทำให้ไฟล์เพจไม่จำเป็น มันเพิ่ม ทางเลือกที่ใช้ซีพียูเพื่อลด I/O ระหว่าง RAM กับที่เก็บข้อมูล

9. บทบาทจริงของไฟล์เพจ

ไฟล์เพจมีอย่างน้อยสามบทบาท

flowchart LR
    accTitle: สามบทบาทของไฟล์เพจ
    accDescr: ไฟล์เพจขยาย Commit Limit เป็นที่เก็บสำรองของเพจส่วนตัวที่แก้ไขและเข้าถึงน้อย และเป็นที่รับดัมพ์เมื่อระบบล่ม
    pagefile["ไฟล์เพจ"] --> limit["ขยาย Commit Limit（ช่องว่างฝั่งเพดาน）"]
    pagefile --> backing["ที่เก็บสำรองของเพจส่วนตัวที่แก้ไขแล้ว"]
    pagefile --> dump["ที่รับดัมพ์เมื่อระบบล่ม"]

ภาพ 4: บทบาทของไฟล์เพจไม่ใช่แค่ «RAM ช้า» แม้การใช้เป็น 0 มันยังรองรับเพดานและดัมพ์

9.1. ขยาย Commit Limit

Commit Limit ของระบบกำหนดคร่าว ๆ จาก RAM บวกผลรวมไฟล์เพจทั้งหมด ไม่มีไฟล์เพจ Commit Limit ลดถึงระดับเล็กกว่า RAM ที่ติดตั้งเล็กน้อย เมื่อ Commit Total ถึงเพดาน Commit ใหม่ล้มเหลวและนำไปสู่การจบแอปผิดปกติหรือปัญหาของระบบได้⁴

นี่เป็นเรื่องคนละอย่างกับ «ตอนนี้เขียนกี่ GB ใน pagefile.sys» ไฟล์เพจยังเป็น ช่องว่างฝั่งเพดาน ที่รองรับคำสัญญา Commit

9.2. รองรับเพจส่วนตัวที่แก้ไขแล้ว

ถ้าเพจส่วนตัวที่แก้ไขและเข้าถึงน้อยถูกสำรองด้วยไฟล์เพจ สามารถเอาเพจทางกายภาพนั้นออกจาก RAM แล้วให้รหัสและข้อมูลที่ใช้บ่อย⁴ การปิดไฟล์เพจลดทางเลือกเอาเพจแบบนั้นออกจาก RAM พูดง่าย ๆ ว่า «เร็วเพราะไม่มีเพจเอาต์» ไม่ได้

9.3. รองรับดัมพ์เมื่อระบบล่ม

เพื่อสร้าง Memory.dmp เมื่อระบบล่ม คุณต้องการไฟล์เพจหรือไฟล์ดัมพ์เฉพาะที่รองรับวิธีดัมพ์ที่เลือกได้² ดัมพ์หน่วยความจำสมบูรณ์ ดัมพ์หน่วยความจำเคอร์เนล และดัมพ์หน่วยความจำอัตโนมัติต่างกันที่ปริมาณที่ต้องการ

ในสภาพแวดล้อมที่สอบสวนการล่ม การลบไฟล์เพจแค่เพื่อประหยัดที่อาจหมายความว่าหลักฐานหายเมื่อต้องการที่สุด วิธีเก็บดู «An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg» ด้วย

10. ขนาดที่เหมาะสมไม่เท่ากันทุกเครื่อง

ไม่ควรตัดสินขนาดไฟล์เพจจากสูตรคงที่อย่าง «1.5 เท่าของ RAM» เพียงอย่างเดียว Microsoft อธิบายว่าขนาดที่เหมาะสมต่างกันต่อระบบในสองจุดต่อไปนี้และสรุปทั่วไปไม่ได้²

1. System Commit Charge จุดสูงสุด
2. ดัมพ์เมื่อระบบล่มที่คุณต้องการ

ในทางปฏิบัติคิดตามลำดับนี้

10.1. เริ่มจากที่ระบบจัดการเป็นฐาน

ค่าเริ่มต้นของ Windows คือระบบจัดการ มันโตและหดตาม RAM ที่ติดตั้ง ความต้องการ Commit ความต้องการดัมพ์เมื่อล่ม และอื่น ๆ ถ้าไม่มีข้อจำกัดพิเศษหรือผลวัด เริ่มที่นี่เป็นการเลือกที่ปลอดภัย

10.2. วัด Commit จุดสูงสุดใต้ภาระที่เป็นตัวแทน

เก็บตัวนับต่อไปนี้ใน PerfMon เป็นเวลานาน

• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\% Committed Bytes In Use
• Memory\\Modified Page List Bytes
• Paging File(*)\\% Usage
• Memory\\Available MBytes
• Memory\\Page Reads/sec
• Memory\\Page Writes/sec

รวมจุดสูงสุดจริงในช่วงเก็บ — ประมวลผลสิ้นเดือน สำรองข้อมูล บิลด์ ผู้ใช้หลายคนพร้อมกัน และอื่น ๆ

เปอร์เซ็นต์การใช้ไฟล์เพจสูงเพียงอย่างเดียวไม่พิสูจน์ปัญหาประสิทธิภาพที่เก็บข้อมูล แต่การติดเพดานเป็นคำเตือนความจุไม่พอ ดูพร้อมกันว่า Commit เข้าใกล้เพดานหรือไม่ มี Modified รอมากหรือไม่ และดิสก์อิ่มหรือไม่²

10.3. ตัดสินความต้องการดัมพ์ก่อน

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

11. ดูด้วยตาคุณเอง

11.1. ดูรายการเพจใน RAMMap

เริ่ม RAMMap ในฐานะผู้ดูแลระบบแล้วเปิด Use Counts ก่อน⁷ รายการที่ดูมีดังนี้

• Active
• Standby
• Modified
• Modified no write
• Free
• Zeroed

Priority Summary ให้ยืนยันว่า Standby แยกตามลำดับความสำคัญ Processes แสดง Working Set ของแต่ละโปรเซส File Summary และ File Details ให้ตามข้อมูลไฟล์ที่อยู่ใน RAM

ลองอ่านไฟล์ท้องถิ่นที่ค่อนข้างใหญ่ครั้งหนึ่ง จบการอ่านแล้ว Refresh เพจของไฟล์นั้นอาจยังอยู่ใน File Summary หรือฝั่ง Standby การอ่านไฟล์เดิมอีกครั้งอาจกู้เพจที่ยังไม่ถูกนำกลับมาใช้โดยไม่มี I/O ดิสก์ หรือมี I/O น้อย ผลแปรตามความกดดันหน่วยความจำ แอนติไวรัส และขนาดไฟล์ ดังนั้นดูทิศทางการเปลี่ยนสถานะมากกว่าชุดตัวเลขชุดเดียว

สังเกตว่าเมนู Empty ของ RAMMap เปลี่ยนสถานะระบบอย่างไม่ธรรมชาติ อย่าล้าง Standby เป็นการปรับปรุงประสิทธิภาพในโปรดักชัน ใช้เฉพาะในสภาพแวดล้อมทดสอบที่แยก

11.2. แยก Commit กับ Touch ด้วย Testlimit

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

.\\testlimit64.exe -?

ต่อไปนี้มุ่ง Testlimit v5.24 ในวากยสัมพันธ์ทางการของ v5.24 -m [MB] จัดสรรวหน่วยความจำตามที่ระบุ -d [MB] จัดสรรและ Touch -e [seconds] เป็นช่วงจัดสรร และ -c [count] เป็นจำนวนครั้งจัดสรร ระบุ -c ท้ายสุด ถ้าที่เห็นในเครื่องต่าง ให้ใช้การใช้งานนั้น¹²

จากนั้นลองเล็ก ๆ บน VM ที่ทิ้งได้

# -m 64: จัดสรร 64 MiB, -e 1: ช่วง 1 วินาที, -c 8: หยุดหลัง 8 ครั้ง
.\\testlimit64.exe -m 64 -e 1 -c 8

# จำนวนและช่วงเดียวกัน พร้อม -d เพื่อ Touch แต่ละช่วง
.\\testlimit64.exe -d 64 -e 1 -c 8

ขณะรัน ให้บันทึกสิ่งต่อไปนี้พร้อมกัน

• «Committed X/Y» ของตัวจัดการงาน
• Active, Modified และ Standby ของ RAMMap
• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\Available MBytes
• Memory\\Modified Page List Bytes

ถ้าจำลองการหมด Commit จริง อย่าทำบนพีซีโฮสต์ เพิ่มจำนวนทีละขั้นบน VM ที่มีสแนปช็อต การรันที่จัดสรรอัตโนมัติถึงเพดานอาจค้างจอ จบโปรเซสผิดปกติ และเสียล็อก จุดประสงค์ไม่ใช่ทำให้ระบบปฏิบัติการไม่เสถียร คือสังเกตว่า เมื่อเข้าใกล้ Commit Limit Commit ใหม่ล้มเหลว

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

12.1. «Standby สูง ดังนั้นหน่วยความจำรั่ว»

Standby เป็นแคชที่นำกลับมาใช้ได้และรวมใน Available ตัดสินรอยรั่วจากว่าเส้นฐาน Commit ส่วนตัวของโปรเซสและการแยกการจัดสรรยังโตต่อแม้ภาระจบแล้วหรือไม่

12.2. «ตัด Working Set จะแก้รอยรั่ว»

การตัดเปลี่ยนแค่การประจำอยู่ ไม่ปล่อย Commit หรือการจัดสรรเสมือน เมื่อเข้าถึงอีกเพจฟอลต์กลับมา

12.3. «การใช้ไฟล์เพจเป็น 0 ดังนั้นไม่จำเป็น»

ไฟล์เพจรองรับไม่ใช่แค่ปริมาณเขียนปัจจุบัน แต่ยัง Commit Limit และดัมพ์เมื่อล่ม การตัดสินลบจากการใช้ประจำวันอย่างเดียวเสียช่องว่างจุดสูงสุดและหลักฐานตอนล้มเหลว

12.4. «บีบอัดหน่วยความจำก่อน แล้วจึงไฟล์เพจเสมอ»

การบีบอัดไม่ใช่ท่ออนุกรมคงที่ Windows เลือกแบบพลวัตตามชนิดเพจ ประสิทธิภาพการบีบ ภาระซีพียู ความกดดันหน่วยความจำ และมีที่เก็บสำรองหรือไม่

13. สรุป

• ฐานข้อมูล PFN คือสมุดบัญชีที่ตามความเป็นเจ้าของ การอ้าง การแก้ไข และสถานะรายการเพจของเพจทางกายภาพ
• เพจสะอาดที่ออกจาก Working Set อยู่ที่ Standby และกลับด้วยซอฟต์ฟอลต์ได้ถ้าต้องการเนื้อหาเดิม⁸
• เพจสกปรกรอที่ Modified และถูกเขียนกลับไฟล์เพจถ้าเป็นส่วนตัว หรือไฟล์ที่เกี่ยวข้องถ้าแมป³
• Available คือผลรวมของ Standby, Free และ Zeroed Standby ใหญ่เพียงอย่างเดียวไม่ใช่การขาดหน่วยความจำ¹
• การบีบอัดหน่วยความจำบีบเพจใน RAM เพื่อลด I/O แต่ไม่ลบบทบาทของ Commit และไฟล์เพจ¹⁰
• ไฟล์เพจรองรับ Commit Limit เพจส่วนตัวที่แก้ไขแล้ว และดัมพ์เมื่อระบบล่ม⁴²
• ขนาดที่เหมาะสมถูกกำหนดด้วย Commit จุดสูงสุดและความต้องการดัมพ์ ตัดสินด้วยตัวคูณเดียวกันทั้งระบบไม่ได้²
• การตัด Working Set และการล้าง Standby ไม่ใช่การแก้หน่วยความจำรั่ว

ต่อในตอนที่ 3 «อ็อบเจ็กต์เซกชันและคัดลอกเมื่อเขียน: DLL และการแมปไฟล์คืออะไรจริง ๆ»

เราตามว่าทำไมเพจไฟล์และ DLL ที่เหลือที่ Standby จึงมองจากหลายโปรเซสเป็นเพจทางกายภาพเดียวกัน

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

• ความลึกของหน่วยความจำ Windows (ตอนที่ 1) — ช่วงที่ที่อยู่เสมือนกลายเป็น RAM จริง
• What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File
• The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
• An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg
• Process Explorer / Handle / VMMap in Practice — Chasing Hangs, Leaks, and “File in Use” from the State Right Now

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

KomuraSoft LLC รับการสอบสวนความกดดันหน่วยความจำของแอปพลิเคชัน Windows การหมด Commit การเพจ การโตของ Working Set และการออกแบบการเก็บดัมพ์เมื่อล่ม

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

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

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

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

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

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

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

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

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

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

เพจถูกเขียนลงไฟล์เพจทันทีที่ออกจาก Working Set หรือไม่

ไม่ เพจที่ไม่ได้แก้ไขย้ายไป Standby พร้อมเนื้อหาเดิมและกลายเป็นแคชที่นำกลับมาใช้ได้ทันที เพจที่แก้ไขแล้วย้ายไป Modified และหลังจากเขียนกลับไปไฟล์เพจหรือไฟล์ที่เกี่ยวข้องตามความจำเป็น จะเดินต่อไปยังสถานะที่นำกลับมาใช้ได้ เช่น Standby

Available ในตัวจัดการงานรวมหน่วยความจำ Standby หรือไม่

รวม หน่วยความจำทางกายภาพที่ใช้ได้ซึ่ง Windows รายงานคือผลรวมของ Standby, Free และ Zeroed Standby ยังถือเนื้อหาเก่า แต่เพราะนำไปใช้กับงานอื่นได้ทันทีถ้าจำเป็น จึงนับเป็นหน่วยความจำที่ใช้ได้

การเขียนลงไฟล์เพจเริ่มเมื่อ RAM หมดสนิทเท่านั้นหรือไม่

ไม่ Windows เขียนกลับเพจที่แก้ไขและเข้าถึงน้อยในพื้นหลังตามรายการ Modified และสถานะหน่วยความจำที่ใช้ได้ ไม่ใช่กลไกเรียบง่ายที่รอจนหมดสนิทแล้วไล่ทั้งหมดทีเดียว

ปิดไฟล์เพจแล้ว Windows จะเร็วขึ้นหรือไม่

โดยทั่วไปยืนยันไม่ได้ การปิดทำให้ Commit Limit ลดลง เอาเพจที่แก้ไขและเข้าถึงน้อยออกจาก RAM ได้ยากขึ้น และกระทบดัมพ์เมื่อระบบล่มด้วย ตามปกติปล่อยให้ระบบจัดการแล้วตัดสินจาก Commit จุดสูงสุดและความต้องการดัมพ์

ถ้ามีการบีบอัดหน่วยความจำ ไฟล์เพจไม่จำเป็นแล้วหรือไม่

ไม่ได้กลายเป็นไม่จำเป็น ที่เก็บการบีบอัดบีบเพจใน RAM เพื่อลด I/O แต่เพจที่บีบแล้วยังใช้หน่วยความจำทางกายภาพและไม่แทนการรับประกัน Commit การเลือกระหว่างบีบอัดกับเพจเอาต์เป็นนโยบายแบบพลวัตของตัวจัดการหน่วยความจำ

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

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

Go Komura

ผู้แทนของ KomuraSoft LLC

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