OOM killer ไม่ทำงานใช่ไหม

41

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

สมมติว่าสคริปต์ง่าย ๆ ที่เพิ่งจัดสรรหน่วยความจำมากกว่าที่มีอยู่ในระบบ (ตัวอย่างเช่นอาร์เรย์ที่มีสตริงนับล้านตัวอย่าง) ถ้าฉันเรียกใช้สคริปต์เช่นนี้ (ในฐานะผู้ใช้ปกติ) เพียงแค่ได้รับหน่วยความจำทั้งหมดจนกว่าระบบจะหยุดทำงานอย่างสมบูรณ์ (เฉพาะ SysRQ REISUB เท่านั้น)

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

ดังนั้นคำถามของฉันคือ:

พฤติกรรมนี้เป็นปกติหรือไม่ เป็นเรื่องแปลกที่แอปพลิเคชันที่ดำเนินการในฐานะผู้ใช้ทั่วไปสามารถทำให้ระบบล่มได้ด้วยวิธีนี้ ...
มีวิธีใดบ้างที่ฉันสามารถทำให้ Ubuntu ฆ่าแอปพลิเคชั่นเหล่านั้นโดยอัตโนมัติเมื่อพวกเขาได้รับหน่วยความจำมากเกินไป

ข้อมูลเพิ่มเติม

Ubuntu 12.04.3
เคอร์เนล 3.5.0-44

RAM: ~ 3.7GB จาก 4GB (ใช้ร่วมกับการ์ดกราฟิก) * * * *

$ tail -n+1 /proc/sys/vm/overcommit_*
==> /proc/sys/vm/overcommit_memory <==
0

==> /proc/sys/vm/overcommit_ratio <==
50

$ cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/dm-1                               partition   4194300 344696  -1

kernel

— ซาเลม
แหล่งที่มา

ฉันไม่แน่ใจว่าทำไมมันไม่ทำงาน ลองtail -n+1 /proc/sys/vm/overcommit_*และเพิ่มผลลัพธ์ ดูที่นี่: ฉันจะกำหนดค่า oom-killer ได้อย่างไร

— kiri

แล้วเกิดอะไรขึ้นกับพื้นที่สว็อปของคุณ คุณสามารถโพสต์เอาต์พุต vmstat บางอย่างเช่น #vmstat 1 100 หรือสิ่งนั้นได้หรือไม่ และยังแสดงให้เราเห็น cat / etc / fstab สิ่งที่ควรจะเกิดขึ้นคือการใช้หน่วยความจำในปริมาณที่แน่นอนคุณควรเริ่มเขียนเพื่อสลับ กระบวนการฆ่าไม่ควรเกิดขึ้นจนกว่าหน่วยความจำและพื้นที่สว็อปจะ "เต็ม"

— j0h

ลอง #swapon -a

— j0h

@ j0h ด้วยการสลับดูเหมือนว่าจะทำงานได้ดี (หลังจากเวลาผ่านไปกระบวนการขัดข้องกับบางสิ่งบางอย่างAllocation failed) แต่หากไม่มีการสลับจะทำให้คอมพิวเตอร์หยุดทำงาน มันควรจะทำงานด้วยวิธีนี้ (ฆ่าเมื่อใช้ swap) เท่านั้น?

— เซเลม

2

ด้วย SysRq คุณสามารถเรียกใช้ OOM (SysRq + F iirc)

— Lekensteyn

36

จากเอกสาร อย่างเป็นทางการ/proc/sys/vm/* :

oom_kill_allocating_task

สิ่งนี้เปิดใช้งานหรือปิดใช้งานการฆ่าภารกิจที่เรียกใช้ OOM ในสถานการณ์ที่หน่วยความจำไม่เพียงพอ

หากสิ่งนี้ถูกตั้งค่าเป็นศูนย์ OOM killer จะสแกนผ่านรายการงานทั้งหมดและเลือกงานตามการวิเคราะห์พฤติกรรมเพื่อฆ่า โดยปกติแล้วจะเลือกงานการแฮ็กหน่วยความจำอันธพาลที่เพิ่มหน่วยความจำจำนวนมากเมื่อถูกฆ่า

ถ้าสิ่งนี้ถูกตั้งค่าเป็นไม่เป็นศูนย์นักฆ่า OOM จะฆ่างานที่ทำให้เกิดสภาวะหน่วยความจำไม่เพียงพอ เป็นการหลีกเลี่ยงการสแกนรายการงานที่มีราคาแพง

หากเลือก panic_on_oom จะมีความสำคัญมากกว่าค่าใด ๆ ที่ใช้ใน oom_kill_allocating_task

ค่าเริ่มต้นคือ 0

เพื่อสรุปเมื่อตั้งค่าoom_kill_allocating_taskเป็น1แทนที่จะสแกนระบบของคุณเพื่อค้นหากระบวนการที่จะฆ่าซึ่งเป็นงานที่มีราคาแพงและช้าเคอร์เนลก็จะฆ่ากระบวนการที่ทำให้ระบบออกจากหน่วยความจำ

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

นอกจากนี้จะเห็นได้ชัดยิ่งขึ้นเพียงแค่ฆ่างานที่ทำให้เกิดปัญหาดังนั้นฉันจึงไม่เข้าใจว่าทำไมจึงตั้งเป็นค่า0เริ่มต้น

สำหรับการทดสอบคุณสามารถเขียนไฟล์หลอกที่ถูกต้อง/proc/sys/vm/ซึ่งจะถูกเลิกทำการรีบูทครั้งต่อไป:

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

สำหรับการแก้ไขแบบถาวรให้เขียนสิ่งต่อไปนี้ไปยัง/etc/sysctl.confหรือไปยังไฟล์ใหม่ภายใต้/etc/sysctl.d/โดยมี.confนามสกุล ( /etc/sysctl.d/local.confตัวอย่าง):

vm.oom_kill_allocating_task = 1

— Teresa e Junior
แหล่งที่มา

2

มันตั้งค่าเป็น 0 เสมอใน Ubuntu หรือไม่? เพราะฉันจำได้ว่ามันเคยฆ่าโดยอัตโนมัติ แต่เมื่อสองสามเวอร์ชั่นหยุดทำเช่นนั้น

— skerit

1

@ เซริทเรื่องนี้ฉันไม่รู้จริงๆ แต่มันถูกตั้งค่าเป็น 0 ในเมล็ดที่ฉันใช้ในปี 2010 (Debian, Liquorix และ GRML)

— Teresa e Junior

"นอกจากนี้มันจะเห็นได้ชัดมากขึ้นเพียงแค่ฆ่างานที่ทำให้เกิดปัญหาดังนั้นฉันจึงล้มเหลวที่จะเข้าใจว่าทำไมมันถึงตั้งเป็นค่า0เริ่มต้น" - เนื่องจากกระบวนการที่ร้องขอหน่วยความจำไม่จำเป็นต้องเป็นกระบวนการที่ "ทำให้เกิดปัญหา" หากกระบวนการ A hogs 99% ของหน่วยความจำของระบบ แต่กระบวนการ B ซึ่งใช้ 0.9% เกิดขึ้นเป็นหนึ่งที่ก่อให้เกิดนักฆ่า OOM โดยโชคไม่ดี B ไม่ได้ "ทำให้เกิดปัญหา" และไม่มีเหตุผลที่จะ ฆ่าบีมีที่เป็นนโยบายความเสี่ยงกระบวนการหน่วยความจำต่ำ unproblematic ทั้งหมดถูกฆ่าตายโดยบังเอิญเพราะการที่แตกต่างกันใช้หน่วยความจำของกระบวนการหนี

— Mark Amery

1

@ MarkAmery ปัญหาที่แท้จริงคือ Linux แทนที่การฆ่ากระบวนการที่ต้องการแล้วก็เริ่มฟาดฟันอย่างช้า ๆ แม้ว่าvm.admin_reserve_kbytesจะเพิ่มขึ้นเป็น128 MBก็ตาม การตั้งค่าvm.oom_kill_allocating_task = 1ดูเหมือนว่าจะบรรเทาปัญหาไม่ได้แก้ปัญหา (และ Ubuntu ได้จัดการกับ fork bombs โดยปริยายแล้ว)

— Teresa e Junior

1

อาจจะสง่างามกว่านี้sudo sysctl -w vm.oom_kill_allocating_task=1

— Pablo A

9

อัปเดต: ข้อผิดพลาดได้รับการแก้ไข

คำตอบของ Teresaนั้นเพียงพอที่จะแก้ไขปัญหาและเป็นเรื่องที่ดี

นอกจากนี้ฉันได้ยื่นรายงานข้อผิดพลาดเพราะนั่นเป็นพฤติกรรมที่ไม่แน่นอน

— int_ua
แหล่งที่มา

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

— shapecatcher

7

อาจได้รับการแก้ไขในปี 2014 ในปี 2018 (และ 18.04) นักฆ่า OOM ยังไม่ได้ทำอะไรอีกเลย

— skerit

0

คุณสามารถลองใช้earlyoomนักฆ่า OOM ที่ทำงานในพื้นที่ผู้ใช้และพยายามที่จะฆ่ากระบวนการที่ใหญ่ที่สุดในสถานการณ์ OOM

— qwr
แหล่งที่มา

-1

ก่อนอื่นฉันขอแนะนำการอัปเดตเป็น 13.10 (ล้างการติดตั้งบันทึกข้อมูลของคุณ)

หากคุณไม่ต้องการอัปเดตให้เปลี่ยน vm.swappiness เป็น 10 และหากคุณพบปัญหาเกี่ยวกับ ram ติดตั้ง zRAM

— Brask
แหล่งที่มา

2

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

— Teresa e Junior

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

— Brask

ในทางทฤษฎี zRAM เป็นสิ่งที่ดี แต่มันก็เป็น CPU หิวและโดยทั่วไปจะไม่คุ้มค่า หน่วยความจำโดยทั่วไปราคาถูกกว่าไฟฟ้า และสำหรับแล็ปท็อปที่อัพเกรดแรมมีราคาแพงกว่าการใช้งานซีพียูก็ไม่เป็นที่พึงปรารถนา

— Teresa e Junior

สิ่งที่เขาขอคือการมีระบบที่มีเสถียรภาพมากขึ้นและการเปลี่ยน swappiness จะทำให้ระบบของเขาใช้ทรัพยากร CPU มากขึ้นใช่ แต่สิ่งที่เขา จำกัด คือ ATM และมีข้อผิดพลาดคือหน่วยความจำเขาต้องการแก้ไขปัญหาไม่ใช่บทเรียนทฤษฎี เกิดอะไรขึ้นเมื่อคุณติดตั้ง zRAM

— Brask

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

— Teresa e Junior