ฉันจะทราบได้อย่างไรว่ามีอะไรค้างอยู่ในเครื่องของฉัน?

ฉันใช้งาน Arch บนเครื่องนี้:

3.40GHz i7 hexacore (4930K)

16GB DDR3 1600MHz RAM

2xSamsung 840 EVO SSDs ใน Raid0 (ใช้การโจมตีแบบ BTRFS)

เมื่อฉันรัน VMware บน Arch ของฉันด้วย VMs ไม่กี่ (2 หรือ 3) ให้พวกเขาแต่ละ 2-4 คอร์และ RAM 2GB แต่ละระบบของฉันเริ่มมีการค้างแบบสุ่ม ทุก ๆ สองสามนาทีระบบจะค้างไว้ที่ใดก็ได้จาก 10 ถึง 30 วินาทีแล้วเริ่มเคลื่อนที่อีกครั้งเพียงเพื่อหยุด 30 วินาทีในภายหลังจนกว่าฉันจะปิด VMs เมื่อระบบค้างเมาส์ยังคงทำงานได้ดี แต่แอปพลิเคชันหยุดการตอบสนองบนโฮสต์ - vmware ไม่ตอบสนอง firefox (ซึ่งเปิดในโฮสต์) ไม่ตอบสนอง ฯลฯ

เมื่อการแช่แข็งเกิดขึ้นถ้าฉันมีการตรวจสอบกระบวนการทำงานมันจะแสดงหลายคอร์ maxed out โดย vmware แต่ในเวลาเดียวกันก็มีคอร์ที่ไม่ได้ใช้อื่น ๆ ฉันมี RAM มากกว่าพอ - VM ใช้ทั้งหมด 6GB และโฮสต์เหลือ 10GB ฉันมีพื้นที่สว็อป 0 ดังนั้นจึงไม่มีวิธีการสลับใด ๆ ที่ทำให้ช้าลง

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

สิ่งนี้ไม่เคยเกิดขึ้นเมื่อฉันใช้ Debian 7 ดังนั้นฉันค่อนข้างมั่นใจว่าไม่ใช่ปัญหาฮาร์ดแวร์

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

จากหน้า btrfs gotchas :

ไฟล์ที่มีการเขียนแบบสุ่มจำนวนมากอาจมีการแยกส่วนอย่างรุนแรง (จำนวน 10,000+ รายการ) ซึ่งทำให้เกิดการทับข้อมูลบน HDD และการโหลด CPU หลายวินาทีในระบบที่มี SSD หรือ RAM จำนวนมาก

• บนเซิร์ฟเวอร์และเวิร์กสเตชันสิ่งนี้มีผลต่อฐานข้อมูลและอิมเมจเครื่องเสมือน

  • ตัวเลือกการเมาท์ nodatacow อาจมีการใช้งานที่นี่พร้อม gotchas ที่เกี่ยวข้อง

  ...

• อาการรวมถึง btrfs-transacti และ btrfs-endio-wri ใช้เวลาของ CPU มาก (ในหนามแหลมอาจถูกกระตุ้นโดยการซิงค์) คุณสามารถใช้ filefrag เพื่อค้นหาไฟล์ที่มีการแยกส่วนอย่างมาก (อาจทำงานไม่ถูกต้องกับการบีบอัด)

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

ในที่สุดฉันก็หดส่วนของ btrfs และ Logical Volume ที่มันอยู่ฉันสร้าง LV ใหม่และจัดรูปแบบเป็น ext4 จากนั้นใส่อิมเมจดิสก์ VM ที่ฉันมี (VirtualBox) บน "พาร์ติชัน"

อาจเป็นปัญหา hugepages แบบโปร่งใสที่เคอร์เนลเธรดkhugepagedกำลังขุด RAM ของคุณเพื่อจัดเรียงข้อมูลหรือทำให้ hugepages ออกมาจาก 4k

เคอร์เนลอาจตัดสินใจเปิดใช้งาน hugepages เนื่องจาก RAM ระบบของคุณค่อนข้างใหญ่

ตรวจสอบเนื้อหาของเคอร์เนลที่ปรับได้สองแบบ:

/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/mm/transparent_hugepage/defrag

หากเนื้อหาของพวกเขาคือalwaysคุณสามารถเปลี่ยนneverและดูว่า cpu spikes / freezes หายไป

ปัญหาได้รับการแก้ไขอย่างสมบูรณ์โดยไม่ได้ใช้ LUKS บนพาร์ติชัน ดังนั้นฉันจึงฟอร์แมตพาร์ติชันโดยตรงกับ BTRFS และไม่ใช่กับ LUKS ก่อน

ติดตั้งด้วยพารามิเตอร์ต่อไปนี้ด้วย:

/dev/sda2 /           btrfs       rw,noatime,space_cache,compress=lzo,ssd,discard,autodefrag,commit=0,thread_pool=8 0 0

เกี่ยวข้องกับประสิทธิภาพการเขียน dm-crypt (LUKS) Abysmal