เป็นเวลาหลายปีที่นักฆ่า OOMของระบบปฏิบัติการของฉันทำงานไม่ถูกต้องและนำไปสู่ระบบที่หยุดชะงัก
เมื่อการใช้หน่วยความจำสูงมากทั้งระบบมีแนวโน้มที่จะ "หยุด" (อันที่จริง: ช้ามาก ) เป็นเวลาหลายชั่วโมงหรือหลายวันแทนที่จะฆ่ากระบวนการเพื่อเพิ่มหน่วยความจำ
จำนวนสูงสุดที่ฉันบันทึกไว้คือ 7 วันก่อนลาออกเพื่อทำการรีเซ็ต
เมื่อ OOM ใกล้จะถึงแล้วiowaitนั้นสูงมาก (~ 70%) ก่อนที่จะกลายเป็นจำนวนที่ไม่สามารถวัดได้
เครื่องมือ: iotopแสดงให้เห็นว่าทุกโปรแกรมกำลังอ่านที่ปริมาณงานสูงมาก (ต่อสิบ MB / วินาที) จากฮาร์ดไดรฟ์ของฉัน
โปรแกรมเหล่านั้นกำลังอ่านอะไร
- ลำดับชั้นไดเรกทอรี?
- รหัสปฏิบัติการเอง?
ฉันไม่ได้ตอนนี้
[แก้ไข] ในเวลาที่ฉันเขียนข้อความนี้ (ในปี 2560) ฉันใช้ ArchLinux uptodate (4.9.27-1-lts) แต่เคยประสบปัญหานี้มาหลายปีแล้ว
ฉันประสบปัญหาเดียวกันกับลีนุกซ์รุ่นต่างๆและการตั้งค่าฮาร์ดแวร์ที่แตกต่างกัน
ปัจจุบัน (2019) ฉันใช้ Debian 9.6 (4.9.0) uptodate ฉันมีRAM จริง16 GB , SSD ที่ติดตั้งระบบปฏิบัติการของฉันและไม่มีพาร์ติชั่นการ สลับใด ๆ
เนื่องจากจำนวน ram ที่ฉันมีฉันไม่ต้องการเปิดใช้งานพาร์ติชัน swap เนื่องจากมันจะทำให้การปรากฏของปัญหาล่าช้าออกไป
นอกจากนี้การเปลี่ยน SSD บ่อยเกินไปอาจช่วยลดอายุการใช้งานของดิสก์ได้
โดยวิธีการที่ฉันได้ลองกับและไม่มีพาร์ทิชัน swap มันได้พิสูจน์แล้วว่าล่าช้าการปรากฏของปัญหา แต่ไม่ได้แก้ปัญหา
สำหรับฉันแล้วปัญหาเกิดจากการที่ลีนุกซ์หยดข้อมูลที่จำเป็นจากแคชซึ่งนำไปสู่ระบบแช่แข็งเพราะมันต้องอ่านทุกอย่างทุกครั้งจากฮาร์ดไดรฟ์
ฉันยังสงสัยว่า Linux จะไม่ปล่อยโค้ดเพจที่รันได้ของโปรแกรมที่กำลังรันซึ่งจะอธิบายว่าทำไมโปรแกรมที่ปกติไม่อ่านข้อมูลจำนวนมากทำตัวแบบนี้ในสถานการณ์นี้
ฉันได้ลองหลายอย่างแล้วโดยหวังว่าจะแก้ไขปัญหานี้
หนึ่งคือการตั้งค่า/proc/sys/vm/min_free_kbytesเป็น1000000(1 GB)
เนื่องจาก1 GBนี้ควรจะว่างฉันจึงคิดว่า Linux จะสงวนหน่วยความจำนี้เพื่อแคชข้อมูลสำคัญ
แต่มันก็ไม่ได้ผล
นอกจากนี้ฉันคิดว่ามีประโยชน์ที่จะเพิ่มว่าแม้ว่ามันจะฟังดูยอดเยี่ยมในทางทฤษฎีการ จำกัด ขนาดของหน่วยความจำเสมือนกับขนาดของหน่วยความจำกายภาพโดยการกำหนด/proc/sys/vm/overcommit_memoryให้2เป็นไปไม่ได้ในทางเทคนิคในสถานการณ์ของฉันเพราะชนิดของแอปพลิเคชัน ที่ฉันใช้ต้องการหน่วยความจำเสมือนมากกว่าที่พวกเขาใช้อย่างมีประสิทธิภาพด้วยเหตุผลบางอย่าง
ตามไฟล์/proc/meminfoที่Commited_ASคุ้มค่ามักจะสูงขึ้นกว่าสองเท่าของ RAM ที่มีอยู่จริงในระบบของฉัน (16 GB, Commited_ASมักจะ> 32 GB)
ฉันเคยประสบปัญหานี้กับ/proc/sys/vm/overcommit_memoryค่าเริ่มต้นของ: 0และในขณะที่ฉันได้กำหนดเป็น: 1เพราะฉันต้องการโปรแกรมที่จะถูกฆ่าโดยOOM killerแทนที่จะทำผิดเพราะพวกเขาไม่ได้ตรวจสอบค่าตอบแทนmallocเมื่อ การจัดสรรถูกปฏิเสธ
เมื่อฉันพูดถึงปัญหานี้เกี่ยวกับIRCฉันได้พบผู้ใช้ Linux รายอื่นที่ประสบปัญหาเดียวกันนี้ดังนั้นฉันเดาว่าผู้ใช้จำนวนมากกังวลเรื่องนี้
สำหรับฉันแล้วนี่เป็นสิ่งที่ไม่สามารถทำได้แม้กระทั่ง Windows ก็ยังดีกว่าด้วยการใช้หน่วยความจำสูง
หากคุณต้องการข้อมูลเพิ่มเติมมีข้อเสนอแนะโปรดบอกฉัน
เอกสารประกอบ:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/
พวกเขาพูดเกี่ยวกับเรื่องนี้:
ทำไม killer linux out-of-memory (OOM) จึงไม่ทำงานโดยอัตโนมัติ แต่ทำงานบน sysrq-key
ทำไมบางครั้ง OOM-killer จึงไม่สามารถฆ่าหมูทรัพยากรได้
การโหลด OOM Killer
ไว้ล่วงหน้าเป็นไปได้ไหมที่จะเรียกใช้ OOM-killer ในการบังคับให้สลับสับเปลี่ยน?
จะหลีกเลี่ยงเวลาแฝงที่สูงใกล้กับสถานการณ์ OOM ได้อย่างไร?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843
min_free_kbytesไม่เกี่ยวข้องไม่ใช่การสำรองสำหรับหน้าแคช AFAICT ไม่มี vm sysctls อนุญาตให้จองหน่วยความจำใด ๆ โดยเฉพาะสำหรับหน้าแคชเช่น จำกัด MAP_ANONYMOUS การจัดสรร :(.