การบีบอัด NTFS บน SSD - ขึ้นและลง

หัวข้อนี้กล่าวถึงการบีบอัด NTFS บน HDD เป็นวิธีการปรับปรุงประสิทธิภาพการเข้าถึงดิสก์และสรุปได้ว่ามันไม่ดีเท่าที่ควร แต่ฉันมักจะมองการบีบอัดเป็นวิธีการประหยัดพื้นที่และเรียนรู้ประสิทธิภาพของมันที่ และตอนนี้ฉันมี SSD ที่พื้นที่มีราคาแพงและประสิทธิภาพลดลงเช่นการอ่าน / เขียน 2 กลุ่มแทนที่จะเป็น 1 จะต่ำกว่ามาก

ในทางกลับกันเนื่องจาก SSD นั้นเร็วกว่า HDD มากฉันคาดว่าปริมาณงานที่มากขึ้นจะส่งผลให้มีการใช้งาน CPU สูงขึ้น นี่จะกลายเป็นปัญหาหรือไม่? มีความคิดเห็นอื่นเกี่ยวกับเรื่องนี้หรือไม่?

ฉันชอบเอฟเฟกต์ประหยัดพื้นที่ไม่มาก แต่ก็อยู่ที่นั่น หากประสิทธิภาพเป็นสิ่งที่น่ากังวลฉันก็อยากจะปิดมัน

Microsoft เขียนสิ่งนี้ในช่วงเวลาหนึ่งที่ผ่านมาในบล็อก :

NTFS บีบอัดไฟล์โดยแบ่งสตรีมข้อมูลออกเป็น CU (คล้ายกับการทำงานของไฟล์แบบกระจาย) เมื่อเนื้อหาสตรีมถูกสร้างหรือเปลี่ยนแปลง CU แต่ละอันในสตรีมข้อมูลจะถูกบีบอัดแยกกัน หากการบีบอัดส่งผลให้เกิดการลดลงของคลัสเตอร์ตั้งแต่หนึ่งคลัสเตอร์ขึ้นไปหน่วยที่บีบอัดจะถูกเขียนลงดิสก์ในรูปแบบที่บีบอัด จากนั้นช่วง sparse VCN จะถูกตรึงไว้ที่ส่วนท้ายของช่วง VCN ที่บีบอัดเพื่อวัตถุประสงค์ในการจัดตำแหน่ง (ดังที่แสดงในตัวอย่างด้านล่าง) หากข้อมูลไม่บีบอัดให้เพียงพอเพื่อลดขนาดทีละหนึ่งคลัสเตอร์ดังนั้น CU ทั้งหมดจะถูกเขียนไปยังดิสก์ในรูปแบบที่ไม่มีการบีบอัด

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

และในบทความ KB เขียนสิ่งนี้ :

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

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

หากคุณเรียกใช้โปรแกรมที่ใช้บันทึกการทำธุรกรรมและเขียนไปยังฐานข้อมูลหรือบันทึกอย่างต่อเนื่องให้กำหนดค่าโปรแกรมให้จัดเก็บไฟล์ไว้ในไดรฟ์ข้อมูลที่ไม่ได้บีบอัด หากโปรแกรมแก้ไขข้อมูลผ่านส่วนที่แมปในไฟล์บีบอัดโปรแกรมสามารถสร้างหน้า "สกปรก" ได้เร็วกว่าตัวเขียนที่แมปสามารถเขียนได้ โปรแกรมต่าง ๆ เช่นการจัดคิวข้อความ Microsoft (หรือที่เรียกว่า MSMQ) ไม่ทำงานกับการบีบอัด NTFS เนื่องจากปัญหานี้

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

สรุป:

บีบอัดไฟล์ขนาดเล็กเท่านั้นที่ไม่เคยเปลี่ยน (อ่านเท่านั้นและไม่เขียนไปยังมัน) เพราะอ่านได้อย่างรวดเร็ว แต่การเขียนต้องใช้การบีบอัดและการบีบอัดใหม่ซึ่งใช้พลังงาน CPU และประเภทการจัดเก็บไม่สำคัญ

ในขณะที่เคลาดิโอพูดในรายละเอียดหลายอย่างฉันจะเริ่มต้นความคิดเห็นของเขาที่เป็นของฉันฉันได้เห็นเอฟเฟ็กต์เดียวกันหลังจากลองสิ่งที่เขาพูด

สำหรับ SSD ต้องไม่ใช้การบีบอัด NTFS

ตอนนี้ฉันจะแจกแจงแรงจูงใจบางอย่างสำหรับการยืนยันดังกล่าว:

Motive Nº1: มันจะฆ่า musch SSD เร็วขึ้นเพราะมันทำให้การเขียนสองครั้ง; การบีบอัดข้อมูลแบบ NTFS จะเขียนข้อมูลที่ไม่บีบอัดไว้ก่อนที่จะเริ่มการบีบอัดข้อมูลบน RAM จากนั้นเขียนข้อมูลที่บีบอัดใหม่อีกครั้งหากได้รับอย่างน้อย 4KiB

Motive Nº2: การใช้คลัสเตอร์ NTFS 4KiB บน SSD นั้นลดความเร็ว 50% ของ SSD ตรวจสอบเกณฑ์มาตรฐานและจะเห็นบล็อก 128KiB ทำให้ SSD เร็วกว่าการใช้บล็อก 4KiB สองเท่าและการบีบอัด NTFS สามารถใช้กับพาร์ติชัน NTFS คลัสเตอร์ 4KiB เท่านั้น

Motive Nº3: มีคอนเทนเนอร์ (เช่น PISMO File Mount) ที่สามารถสร้างคอนเทนเนอร์ที่ถูกมองว่าเป็นการบีบอัดและ / หรือการเข้ารหัสแมลงเหล่านี้ทำการบีบอัด RAM และไม่ส่งข้อมูลที่ไม่บีบอัดไปยังดิสก์ก่อนที่จะเขียนซ้ำ ในรูปแบบการบีบอัดยิ่งกว่านั้น PISMO จะได้อัตราส่วนการอัดที่ดีกว่า NTFS

มีแรงจูงใจมากขึ้น แต่นั่นก็เป็นผู้นำเข้าอันดับต้น ๆ

จุด otrer คือ SPEED, compresion ใด ๆ ที่ทำบน CPU ดังนั้นหากคุณไม่มี CPU ที่เร็วมาก (mono-thread ถูกใช้สำหรับ NTFS ในขณะที่ multi-thread ถูกใช้ในคอนเทนเนอร์บางตัว) จะเห็นการอ่าน / เขียนช้ามาก เมื่อถูกบีบอัด; ที่เลวร้ายที่สุดคุณสามารถมี cpu ที่รวดเร็วมาก แต่ถ้ามันถูกใช้สำหรับสิ่งอื่น ๆ (เช่นการเรนเดอร์การแปลงรหัส ฯลฯ ) ไม่มี cpu ที่เหลือสำหรับการบีบอัดดังนั้นคุณจะได้รับประสิทธิภาพที่ต่ำ

การคอมไพล์ NTFS นั้นดีสำหรับดิสก์ช้าแบบดั้งเดิมเมื่อคุณมี cpu โดยไม่ต้องใช้มาก แต่มันต้องการการจัดระเบียบที่ดีหลังจากการเขียนแต่ละครั้ง (ที่ระดับไฟล์) เนื่องจากแต่ละ 64KiB บล็อก (บีบอัดหรือไม่) ถูกเขียนที่ตำแหน่ง 64KiB หลายแห่ง วิธีเดียวที่จะแพ็คชิ้นส่วนดังกล่าวคือหลังจากการบีบอัด (หรือเขียนในโฟลเดอร์ที่บีบอัด) ทำการจัดเรียงข้อมูลของไฟล์ดังกล่าว

PD: ระวังเรากำลังพูดถึง Windows บนฮาร์ดแวร์จริงไม่ใช่ในเครื่องเสมือนสิ่งที่ importatnt คือผู้ที่เขียนลงไปในสื่อที่มีอยู่จริงคนอื่น ๆ อาจมีเลเยอร์แคชที่สามารถลดผลกระทบและปรับปรุงสิ่งต่าง ๆ ได้มาก

ไม่มีใครพูดคุยเกี่ยวกับปัญหานายกเทศมนตรีใน SSD ไม่ใช่มันเป็นส่วน

แต่ละบล็อก 64KiB ถูกเขียนโดยที่มันจะไม่มีการบีบอัด แต่มันสามารถบีบอัดได้ดังนั้นอย่างน้อยก็คือ <= 60KiB จากนั้นมันจะเขียนน้อยกว่า 64KiB บล็อกรังแบบบิตจะไปในที่ที่เหมือนกับว่าก่อนหน้านี้ไม่มี บีบอัดดังนั้นช่องว่างมากมายapèars

ทดสอบด้วยไฟล์หลายกิกะไบต์ของเครื่อง virtusl ของระบบ windows ใด ๆ (มีแนวโน้มที่จะลดลง 50% แต่มีขนาดใหญ่กว่า 10,000 ชิ้น)

และสำหรับ SSD นั้นมีบางอย่างที่ไม่ได้บอกว่ามันเขียนได้อย่างไร ฉันหมายถึงถ้ามันเขียนมันไม่บีบอัดแล้วเขียนทับมันด้วยเวอร์ชั่นบีบอัด (สำหรับบล็อกขนาดใหญ่ 64KiB แต่ละบล็อก) อายุการใช้งานของ SSD จะถูกตัดขาดมาก แต่ถ้ามันเขียนโดยตรงบนรูปแบบการบีบอัด SSD live อาจเป็น lo ger หรือสั้นกว่า .... อีกต่อไปถ้าคุณเขียน 64KiB ในครั้งเดียวเท่านั้นสั้นลง mu h สั้นลงถ้าคุณเขียน 64KiB ใน 4KiB เพราะมันจะเขียน 64KiB เช่นนี้ (ในรูปแบบบีบอัด) หลาย ๆ ครั้งเป็น 64/4 = 16 ครั้ง

การลงโทษประสิทธิภาพเกิดขึ้นเนื่องจากเวลา CPU ที่จำเป็นในการบีบอัด / uncompress จะใหญ่กว่าเวลาที่ไม่จำเป็นต้องบีบบล็อก 4KiB ... ดังนั้นด้วย CPU ที่เร็วมากและการบีบอัดดิสก์ที่ช้ามากช่วยลดเวลาในการเขียนและอ่าน แต่ถ้า SSD เป็น เร็วมากและ CPU ค่อนข้างช้ามันจะเขียนช้ากว่ามาก

เมื่อฉันพูดถึง CPU ที่ช้าหรือช้าฉันหมายถึงในขณะนั้น CPU สามารถใช้งานได้โดย 'maths' หรือกระบวนการอื่นดังนั้น allways คิดว่าเป็น cpu ฟรีไม่ได้อยู่ในสเปคของ CPU ที่กระดาษเหมือนกันกับดิสก์ / SSD ใช้งานโดยหลายกระบวนการ

สมมติว่าคุณมี 7Zip ที่เขียนไฟล์ขนาดใหญ่จากดิสก์อื่นด้วย LZMA2 มันจะใช้ CPU เป็นจำนวนมากดังนั้นหากในเวลาเดียวกันคุณกำลังคัดลอกไฟล์บีบอัดแบบ NTFS มันก็จะไม่มี CPU ให้ใช้ดังนั้นมันจะช้ากว่าโดยไม่มี NTFS การบีบอัด แต่ทันทีที่ 7Zip สิ้นสุดการใช้ CPU CPU ดังกล่าวจะสามารถบีบอัด NTFS ได้เร็วขึ้นและในเวลานั้นการบีบอัด NTFS สามารถทำสิ่งต่าง ๆ ได้เร็วขึ้น

โดยส่วนตัวฉันไม่เคยใช้การบีบอัดแบบ NTFS ฉันชอบไฟล์ PISMO ที่เมานต์ตู้คอนเทนเนอร์ PFO (พร้อมการบีบอัดและมันยังอนุญาตให้ทำการสมัครสมาชิกได้ทั้งการบินและแอพโปร่งใส) มันให้อัตราส่วน compresion ที่ดีขึ้นและผลกระทบ CPU น้อยลง และเขียนได้ทันทีไม่จำเป็นต้องคลายการบีบอัดก่อนใช้งานเพียงติดตั้งและใช้งานในโหมดอ่านและเขียน

เนื่องจาก PISMO ทำการบีบอัด RAM ก่อนที่จะเขียนลงบนดิสก์มันสามารถทำให้ SSD ใช้งานได้นานขึ้นการทดสอบการบีบอัด NTFS ของฉันทำให้ฉันคิดว่ามันส่งข้อมูลไปยังดิสก์สองครั้งไม่บีบอัดเป็นครั้งแรกและหลังจากนั้นถ้ามันบีบอัดได้ .

เหตุใดความเร็วในการเขียนที่ถูกบีบอัดของ NTFS บน SSD ของฉันจึงอยู่ใกล้ 1/2 ของไฟล์ที่ไม่บีบอัดซึ่งมีไฟล์มากกว่าบีบอัดที่ขนาด 1/2 หรือขนาดที่บีบอัดต่ำกว่า? ใน AMD Threadripper 2950 ของฉัน (32 คอร์และ 64 เธรด) ที่มี 128GiB ของ ram (fast CPU, CPU ที่เร็วมาก) ที่ใช้งานน้อยกว่า 1% ดังนั้นจึงมี CPU มากมายที่จะทำการบีบอัดได้เร็วกว่าความเร็วสูงสุดของ SSD สูงสุดอาจเป็นเพราะ การบีบอัด NTFS เริ่มขึ้นหลังจากบล็อก 64KiB ถูกส่งไปยังดิสก์ที่ไม่มีการบีบอัดแล้วเขียนทับด้วยรุ่นที่บีบอัด ... โอ้ถ้าฉันทำบนเครื่องเสมือนที่ใช้งาน Linux บนโฮสต์และ Windows บนแขกแล้วแคช Linux จะแจ้งให้ฉัน และความเร็วนั้นเร็วกว่ามาก (Linux ทำการแคช NTFS ที่ไม่บีบอัดซึ่งเขียนโดย windows guest และหลังจากที่พวกมันถูกเขียนทับด้วยข้อมูลที่ถูกบีบอัด linux จะไม่ส่งข้อมูลที่ไม่บีบอัดไปยังดิสก์

คำแนะนำของฉันอย่าใช้การบีบอัดแบบ NTFS ยกเว้นในเครื่องเสมือนแขกที่ใช้ Windows ถ้าโฮสต์เป็น Linux และไม่เคยถ้าคุณใช้ซีพียูมากถ้า CPU ของคุณไม่เร็วพอ

Modern SSD มี RAM ภายในแคชขนาดใหญ่ดังนั้นการเขียน + overwtite ที่เกิดจากการบีบอัด NTFS สามารถบรรเทาได้ด้วยระบบแคชภายใน SSD

การทดสอบของฉันทำที่ SSD "สวย" โดยไม่มี RAM ภายในสำหรับแคชภายใน SSD เมื่อฉันทำซ้ำกับ RAM แคชความเร็วในการเขียนนั้นเร็วกว่า แต่ไม่ใช่อย่างที่คิด

ทำการทดสอบของคุณเองและใช้ไฟล์ขนาดใหญ่ (ใหญ่กว่าการติดตั้งรวมทั้งหมดเพื่อหลีกเลี่ยงการซ่อนแคช)

บางสิ่งบางคนไม่ทราบเกี่ยวกับการบีบอัดไฟล์ NTFS ... ไฟล์ใด ๆ ของ 4KiB หรือต่ำกว่าจะไม่บีบอัดไฟล์ NTFS เพราะไม่มีวิธีลดขนาดอย่างน้อย 4KiB

การกด co แบบ NTFS นั้นใช้ 64KiB บีบอัดและถ้ามันสามารถลดหนึ่งคลัสเตอร์ (4KiB) ก็จะถูกบีบอัดเขียน 64KiB คือ 16 บล็อก 4KiB (consecutives)

หากไฟล์ 8KiB เมื่อการบีบอัดสิ้นสุดผลลัพธ์สุดท้ายมากกว่า 4KiB ไฟล์จะไม่บันทึกคลัสเตอร์ใด ๆ ดังนั้นจึงไม่มีการบีบอัดไฟล์เขียน ... และอื่น ๆ ... การกดทับต้องได้รับ 4KiB อย่างน้อย

อ่าและสำหรับการบีบอัดแบบ NTFS นั้น NTFS ต้องมีขนาดคลัสเตอร์เท่ากับ 4KiB

ลองทำแบบทดสอบ: ใช้คลัสเตอร์ 128KiB บน NTFS บน SSD คุณจะเห็นว่าประสิทธิภาพการทำงานของการเขียนความเร็วในการอ่านเพิ่มขึ้นอย่างมาก

ระบบไฟล์บน SSD ที่มีคลัสเตอร์ 4KiB กำลังสูญเสียความเร็วในกรณีส่วนใหญ่มากกว่า 50% ที่หายไป ... ดูมาตรฐานใด ๆ ที่ทดสอบด้วยขนาดบล็อกที่แตกต่างกันตั้งแต่ 512Bytes ถึง 2MiB ส่วนใหญ่ SSD เขียนได้สองเท่า ความเร็วเมื่อใช้ขนาดคลัสเตอร์ 64KiB (หรือ 128KiB) มากกว่า 4KiB

ต้องการความรู้สึกที่แท้จริงใน SSD ของคุณหรือไม่ ห้ามใช้คลัสเตอร์ 4KiB บนระบบไฟล์ใช้ 128KiB

ใช้คลัสเตอร์ 4KiB เท่านั้นหากไฟล์ของคุณมากกว่า 99% น้อยกว่า 128KiB

ฯลฯ ฯลฯ ฯลฯ ... ทดสอบทดสอบและทดสอบเคสของคุณเอง

หมายเหตุ: สร้างพาร์ติชันระบบ NTFS ด้วย diskpart ในโหมดคอนโซลขณะติดตั้ง Windows ด้วยคลัสเตอร์ 128KiB หรือจาก Windows อื่น แต่ไม่อนุญาตให้ฟอร์แมต Windows ในขณะที่อยู่ในส่วนกราฟิกของตัวติดตั้ง (มันจะฟอร์แมตเป็นคลัสเตอร์ NTFS 4KiB)

Windows ของฉันทั้งหมดได้รับการติดตั้งบนพาร์ติชัน NTFS แบบคลัสเตอร์ 128KiB บน> 400GiB SSD (SLC)

หวังว่าทุกอย่างจะชัดเจน M $ ไม่ได้บอกว่าฉันเขียน NTFS ที่บีบอัดอย่างไรการทดสอบของฉันบอกฉันว่าเขียนสองครั้ง (64KiB ไม่บีบอัดจากนั้น <= 60KiB compreesed) ไม่ใช่แค่ครั้งเดียว

ระวัง: Windows พยายามที่จะ NTFS บีบอัด dirs ภายในบางส่วนไม่ว่าคุณจะบอกว่าไม่มีการบีบอัด NTFS วิธีเดียวที่จะหลีกเลี่ยงได้จริง ๆ เช่นถ้ามีขนาดคลัสเตอร์ NFTS แตกต่างจาก 4KiB เนื่องจากการบีบอัด NTFS ใช้ได้กับพาร์ติชัน NTFS ขนาด 4KiB เท่านั้น

ฉันเห็นความคิดเห็นของผู้อื่นและฉันคิดว่าคนมักจะลืมสถานการณ์ที่มีประโยชน์ที่สุดที่การบีบอัดไฟล์ / โฟลเดอร์ NTFS มีข้อได้เปรียบที่ยอดเยี่ยมสำหรับ SSD: เครื่องมือพัฒนาที่ทันสมัย Matlab ที่ได้รับอนุญาตจากมหาวิทยาลัยของฉันมีในโฟลเดอร์การติดตั้ง (สำหรับผู้ใช้ทั่วไปแบบอ่านอย่างเดียว) ตามจำนวนข้อมูลต่อไปนี้:

ข้อมูล 28.5 GB ขนาด 30.6 GB บนดิสก์มีไฟล์ 729.246 และโฟลเดอร์ 15.000 (!!!)

นี่คือแล็ปท็อปของฉันที่มี SSD 500 GB ซึ่งพาร์ทิชัน windows คือ 200 GB

ฉันรู้ว่า Matlab ค่อนข้างสุดขีดในเรื่องนี้ แต่ devtools จำนวนมากมีคุณสมบัติคล้ายกัน: ไฟล์ข้อความขนาดเล็กที่สามารถบีบอัดได้จำนวนมาก (ส่วนหัว, โค้ด, ไฟล์ XML) ฉันกำลังบีบอัด Matlab ทันทีก่อนที่ฉันจะติดตั้งIntel Quartus FPGA devtool และOctaveถูกบีบอัดไว้แล้วดังนี้:

ขนาดข้อมูล 1.55 GB บนดิสก์: 839 GB มีไฟล์ 34.362 ไฟล์ 1.955 โฟลเดอร์

สิ่งนี้เขียนครั้งเดียวและอ่าน zillions ครั้งในระหว่างการสร้างโครงการ มันทำให้รู้สึกดีที่จะใช้จ่ายบางส่วนพลังงาน CPU เพื่อขยายและบันทึกบางทีอาจจะเป็นครึ่งหนึ่งของพื้นที่ SSD ของคุณมีค่า

คุณต้องสร้างมาตรฐานสองครั้งเพื่อที่จะรู้ การบีบอัด ยังไม่ย่อ ลืมสวมใส่ SSD คุณต้องการ ssd และ CPU ที่รวดเร็วดังนั้นจึงไม่มีปัญหาคอขวดเกิดขึ้น

วันนี้ SSD ขนาด 512GB อยู่ที่ 50 bucks การเข้าถึงดิสก์ที่เร็วที่สุดสำหรับฉันคือการใช้ Linux เมื่อเป็นไปได้และกลไกคิวดิสก์ LIFO มากกว่า CFQ

Windows 10 สร้างกิจกรรมดิสก์ที่ไม่สิ้นสุดโดยติดตั้ง RAM 12GB บนแล็ปท็อปของฉัน ลินุกซ์มิ้นท์โหลดและการเข้าถึงดิสก์เกือบเป็นศูนย์เกิดขึ้นหลังจาก เว้นแต่คุณจะเริ่มต้น Windows มีวิธีทำให้ตัวเองไม่ว่างโดยไม่มีงานที่สามารถมองเห็นได้