กิจกรรมการเขียนจำนวนมากบน SSD ทำให้ประสิทธิภาพของระบบนิวเคลียร์

ฉันสังเกตว่าเมื่อฉันเขียนแอพพลิเคชั่นอย่างหนักระบบทั้งหมดจะช้าลง เพื่อทดสอบเพิ่มเติมต่อไปนี้ฉันทำสิ่งนี้เพื่อทำ CPU (ค่อนข้างต่ำ), กิจกรรมดิสก์สูง:

john -incremental > file_on_SSD

สิ่งนี้จะบีบสตริงออกนับหมื่นต่อวินาทีไปยังไฟล์บนดิสก์ระบบของฉัน

เมื่อมันทำเช่นนี้เมาส์จะล่าช้า TTY ไม่ตอบสนองแอพพลิเคชั่น "จาง" และโดยทั่วไปคอมพิวเตอร์ทั้งหมดจะไม่สามารถใช้งานได้ ในที่สุดเมื่อฉันสามารถควบคุมได้ + C johnระบบจะกลับมาเต็มความแรงหลังจากไม่กี่วินาที

นี่เป็นตัวอย่างที่รุนแรง แต่ฉันมีปัญหาที่คล้ายกันที่มีกิจกรรมการเขียนน้อยมากเช่นการคัดลอกไฟล์ขนาดใหญ่จากแหล่งที่มาอย่างรวดเร็วหรือการแปลงรหัส

ดิสก์ระบบปฏิบัติการหลักของฉันคือ SSD ที่ค่อนข้างเร็ว ( OCZ Agility 60GB ) พร้อม EXT4 ถ้าฉันเขียนjohnเอาต์พุตไปยังดิสก์เชิงกลที่มี EXT4 ฉันจะไม่พบกับการทำงานแบบช้าลงแม้ว่าอัตราจะช้ากว่ามาก (SSD ทำได้ ~ 42,000 คำต่อวินาทีและกลไก 8,000 วัตต์ต่อวินาที) ปริมาณงานอาจเกี่ยวข้อง ดิสก์เชิงกลยังไม่มีส่วนเกี่ยวข้องกับระบบ มันเป็นเพียงข้อมูล

และฉันใช้เคอร์เนล 2.6.35-2 แต่ฉันสังเกตเห็นปัญหานี้เนื่องจากฉันได้รับ SSD นี้เมื่อฉันอาจใช้. 31 หรืออะไรบางอย่างจากช่วงเวลานั้น

ดังนั้นสิ่งที่ทำให้เกิดการชะลอตัว? ปัญหา EXT4? ปัญหาเคอร์เนล? ปัญหา SSD หรือไม่ ถูกทุกข้อ? อื่น ๆ อีก?

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

นี่เป็นปัญหาที่ทราบมานานแล้ว การใช้ FS ที่ปรับด้วย SSD เช่น Btrfs อาจช่วยได้ แต่อาจไม่ได้

ในที่สุดมันเป็นข้อผิดพลาดในระบบจัดการกำหนดการ / หน่วยความจำ IO เมื่อเร็ว ๆ นี้ได้มีการแก้ไขบางส่วนที่มุ่งแก้ไขปัญหานี้ ดูการแก้ไข: ปัญหาการตอบสนองของ Linux Desktop หรือไม่

ในที่สุดแพทช์เหล่านี้อาจเข้าไปในเคอร์เนลที่ฉีด แต่ในตอนนี้คุณอาจต้องคอมไพล์เคอร์เนลของคุณเองหากคุณต้องการแก้ไขปัญหานี้

มีบางสิ่งที่คุณสามารถตรวจสอบเพื่อลองปรับปรุงประสิทธิภาพ SSD ภายใต้ Linux

1. ตั้งจุดเมานท์เป็น 'noatime' กิจกรรมเพิ่มเติมที่อัปเดตเวลาเข้าถึงโดยทั่วไปจะเป็นการสิ้นเปลืองในกรณีใช้งานส่วนใหญ่ โดยเฉพาะอย่างยิ่งในกรณีของการปั๊มบรรทัดเดียวอย่างต่อเนื่องเป็นไฟล์คุณกำลังบังคับให้มีการปรับปรุงหลายระบบไฟล์สำหรับการเข้าถึงทุกครั้ง

2. ตรวจสอบลิฟต์ ลิฟท์เริ่มต้นสำหรับ distros ส่วนใหญ่ถูกตั้งค่าสำหรับ platters หมุนเข้าถึงแบบสุ่ม SSD ไม่จำเป็นต้องใช้ตรรกะเพิ่มเติมดังนั้นการตั้งค่าลิฟต์เป็น noop สามารถปรับปรุงประสิทธิภาพได้โดยการให้ฮาร์ดแวร์จัดการการเขียน

3. การเขียนผ่านการเขียนย้อนกลับ v นี่เป็นความลับอีกเล็กน้อย แต่คุณสามารถตรวจสอบวิธีการแคชที่ใช้กับhdparmอุปกรณ์ แคชการเขียนกลับมีผลกระทบทางบวกต่อประสิทธิภาพของ SSD เมื่อเปรียบเทียบกับการเขียนผ่าน

การแคชไฟล์ของคุณอาจถูกปรับอย่างไม่ถูกต้องสำหรับปริมาณงานของคุณ น่าเสียดายที่ Linux kernel โง่พอที่จะไม่จัดการเรื่องนี้โดยอัตโนมัติและค่าเริ่มต้นนั้นแย่มากถ้าคุณมี RAM จำนวนมากและอุปกรณ์บล็อกช้าพอ ดูhttps://lonesysadmin.net/2013/12/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/สำหรับรายละเอียด

ฉันขอแนะนำให้ลองปรับเปลี่ยน/etc/sysctl.confเช่นกัน

vm.dirty_background_ratio = 3
vm.dirty_ratio = 6

เพื่อลดแรงกดดัน RAM ที่เกิดจากการเขียนแคชเพื่อให้เคอร์เนลจัดการงานอื่น ๆ ได้ดีขึ้น สิ่งนี้จะทำการค้าเวลาแฝงที่ดีขึ้นสำหรับปริมาณงานที่ลดลง

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

vm.dirty_background_ratio = 5
vm.dirty_ratio = 80

โปรดทราบว่า*_ratioการตั้งค่าอ้างถึงเปอร์เซ็นต์ของ RAM ที่มีอยู่ หากคุณต้องการการควบคุมที่ดีขึ้นให้ใช้*_bytesการตั้งค่า ฉันใช้การกำหนดค่าต่อไปนี้เป็นการส่วนตัวสำหรับเวิร์กสเตชันของฉัน:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000

ที่ จำกัด การเขียนพื้นหลังแคชไว้ที่ 50 MB และบังคับให้เขียนแบบซิงค์หากขนาด 200 MB อยู่ในแคช