ปิดตัวจัดการ Linux OOM ตามค่าเริ่มต้นหรือไม่

OOM killer บน Linux สร้างความเสียหายให้กับแอพพลิเคชั่นต่าง ๆ ทุกครั้งและดูเหมือนว่าไม่ค่อยมีการพัฒนาเคอร์เนลมากนักเพื่อปรับปรุงสิ่งนี้ จะเป็นการดีกว่าหากเป็นวิธีปฏิบัติที่ดีที่สุดในการตั้งค่าเซิร์ฟเวอร์ใหม่เพื่อย้อนกลับค่าเริ่มต้นในหน่วยความจำที่มีมากเกินไปนั่นคือปิด ( vm.overcommit_memory=2) เว้นแต่คุณรู้ว่าคุณต้องการใช้งานโดยเฉพาะหรือไม่? และกรณีการใช้งานเหล่านั้นจะเป็นอย่างไรในที่ที่คุณรู้ว่าคุณต้องการ overcommitting

ในฐานะโบนัสเนื่องจากพฤติกรรมในกรณีที่vm.overcommit_memory=2ขึ้นอยู่กับvm.overcommit_ratioและสลับพื้นที่จะมีกฎอะไรที่ดีสำหรับการปรับขนาดสองหลังเพื่อให้การตั้งค่าทั้งหมดนี้ทำงานอย่างมีเหตุผล

การเปรียบเทียบที่น่าสนใจ (จากhttp://lwn.net/Articles/104179/ ):

บริษัท เครื่องบินค้นพบว่าถูกกว่าการบินเครื่องบินด้วยน้ำมันเชื้อเพลิงน้อยลง เครื่องบินจะเบาลงและใช้เชื้อเพลิงน้อยลงและประหยัดเงิน ในบางโอกาส แต่ปริมาณเชื้อเพลิงไม่เพียงพอและเครื่องบินก็จะพัง ปัญหานี้ได้รับการแก้ไขโดยวิศวกรของ บริษัท โดยการพัฒนากลไกพิเศษ OOF (นอกเชื้อเพลิง) ในกรณีฉุกเฉินผู้โดยสารได้รับเลือกและโยนออกจากเครื่องบิน (เมื่อจำเป็นให้ทำซ้ำขั้นตอน) ทฤษฎีขนาดใหญ่ได้รับการพัฒนาและสิ่งพิมพ์จำนวนมากได้ทุ่มเทให้กับปัญหาในการเลือกเหยื่อที่จะถูกขับออกมาอย่างถูกต้อง ควรเลือกเหยื่อแบบสุ่มหรือไม่? หรือควรเลือกคนที่หนักที่สุด? หรือเก่าแก่ที่สุด? หากผู้โดยสารจ่ายเพื่อไม่ให้ถูกขับออกมา ดังนั้นเหยื่อจะเป็นคนที่ยากจนที่สุดบนเรือ? และถ้าเป็นเช่นนั้นบุคคลที่มีน้ำหนักมากที่สุดได้รับเลือกจะมีข้อยกเว้นพิเศษในกรณีที่เป็นนักบินหรือไม่ ผู้โดยสารชั้นหนึ่งควรได้รับการยกเว้นหรือไม่ ตอนนี้มีกลไก OOF อยู่แล้วมันจะถูกเปิดใช้งานเป็นระยะ ๆ และจะขับผู้โดยสารออกแม้ว่าจะไม่มีการขาดแคลนเชื้อเพลิง วิศวกรยังคงศึกษาอย่างแม่นยำว่าเกิดความผิดปกตินี้อย่างไร

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

เพื่อตอบคำถามของคุณโดยเฉพาะ:

• ฉันไม่คิดว่ามันเป็นความคิดที่ดีที่จะปิด overcommit ในกรณีทั่วไป มีแอปพลิเคชั่นเพียงไม่กี่ตัวที่เขียนขึ้นเพื่อจัดการกับbrk(2) (และตัวห่อที่ใช้เช่นmalloc(3)) ที่ส่งคืนข้อผิดพลาดอย่างถูกต้อง เมื่อฉันทดลองสิ่งนี้ในงานก่อนหน้าของฉันมันก็เป็นเรื่องยุ่งยากมากกว่าที่จะทำให้ทุกอย่างสามารถจัดการกับข้อผิดพลาดออกจากหน่วยความจำได้มากกว่าที่จะจัดการกับผลของ OOM (ซึ่งในกรณีของเรา) มันแย่กว่าที่จะต้องเริ่มบริการเป็นครั้งคราวหาก OOM เกิดขึ้น - เราต้องรีบูตทั้งคลัสเตอร์เพราะ GFS เป็นกองนึ่งของอุจจาระ)
• คุณต้องการ overcommitting on สำหรับกระบวนการใด ๆ ที่ overcommits หน่วยความจำ ผู้ร้ายสองคนที่พบบ่อยที่สุดที่นี่คือ Apache และ JVM แต่แอปมากมายทำสิ่งนี้ในระดับที่สูงขึ้นหรือน้อยลง พวกเขาคิดว่าพวกเขาอาจต้องการความทรงจำมากมายในอนาคตดังนั้นพวกเขาจึงหยิบก้อนใหญ่ออกมาทันที ในระบบที่เปิดใช้งานเกินขีด จำกัด เคอร์เนลจะ "meh อะไรก็ตามมารบกวนฉันเมื่อคุณต้องการเขียนไปยังหน้าเหล่านั้น" และไม่มีอะไรเลวร้ายเกิดขึ้น บนระบบ overcommit-off เคอร์เนลบอกว่า "ไม่คุณไม่มีหน่วยความจำมากขนาดนั้นถ้าคุณเขียนมันได้ทุกอย่างในอนาคตฉันมีกระดูกดังนั้นจึงไม่มีหน่วยความจำสำหรับคุณ!" และการจัดสรรล้มเหลว เนื่องจากไม่มีอะไรออกไปที่นั่น "โอ้, ตกลง, ฉันจะมีส่วนของข้อมูลกระบวนการที่น้อยกว่านี้ได้ไหม?" จากนั้นกระบวนการ (a) หยุดทำงานด้วยข้อผิดพลาดหน่วยความจำไม่เพียงพอหรือ (b) ไม่ตรวจสอบรหัสส่งคืนจาก malloc คิดว่าไม่เป็นไรและเขียนไปยังตำแหน่งหน่วยความจำที่ไม่ถูกต้องทำให้เกิด segfault โชคดีที่ JVM ทำทุกอย่างล่วงหน้าเมื่อเริ่มต้น (ดังนั้น JVM ของคุณจะเริ่มต้นหรือตายทันทีซึ่งคุณมักสังเกตเห็น) แต่ Apache ทำเรื่องสนุก ๆ กับเด็กใหม่แต่ละคนซึ่งอาจมีผลกระทบที่น่าตื่นเต้นในการผลิต "ประเภทของความตื่นเต้น)
• ฉันไม่ต้องการตั้งค่า overcommit_ratio สูงกว่าค่าเริ่มต้น 50% อีกครั้งจากการทดสอบของฉันถึงแม้ว่าการตั้งค่าประมาณ 80 หรือ 90 อาจฟังดูเจ๋ง แต่เคอร์เนลต้องการหน่วยความจำขนาดใหญ่ในเวลาที่ไม่สะดวกและระบบที่โหลดเต็มซึ่งมีอัตราส่วน overcommit สูงมีแนวโน้มว่าจะมีหน่วยความจำสำรองไม่เพียงพอ เมื่อเคอร์เนลต้องการมัน (นำไปสู่ความกลัวโรคระบาดและ oopses) ดังนั้นการเล่นด้วย overcommit จึงเป็นการแนะนำโหมดความล้มเหลวที่สนุกสนานยิ่งขึ้น - แทนที่จะเพียงแค่รีสตาร์ทกระบวนการใดก็ตามที่มี OOMed เมื่อหน่วยความจำของคุณไม่เพียงพอตอนนี้เครื่องของคุณก็ล้มเหลว น่ากลัว!
• พื้นที่สว็อปในระบบที่ปราศจากข้อผิดพลาดขึ้นอยู่กับจำนวนหน่วยความจำที่ร้องขอ แต่ไม่ได้ใช้ที่แอพพลิเคชั่นของคุณต้องการ การออกกำลังกายสิ่งที่จำเป็นในกรณีที่เฉพาะเจาะจงคือการออกกำลังกายสำหรับผู้อ่าน

โดยพื้นฐานแล้วประสบการณ์ของฉันคือการปิดโอเวอร์คอมมันเป็นการทดลองที่ดีซึ่งไม่ค่อยได้ผลเช่นเดียวกับในทางปฏิบัติในทางทฤษฎี นี้อย่างสอดคล้องกับประสบการณ์ของฉันกับ tunables อื่น ๆ ใน kernel - นักพัฒนาลินุกซ์เคอร์เนลมักจะฉลาดกว่าที่คุณและเริ่มต้นทำงานที่ดีที่สุดสำหรับกว้างใหญ่กว้างใหญ่กรณีส่วนใหญ่ ปล่อยให้พวกเขาอยู่คนเดียวและไปหากระบวนการที่มีการรั่วไหลและแก้ไข

อืมฉันไม่มั่นใจอย่างเต็มที่จากการโต้แย้งเพื่อสนับสนุน overcommit และ OOM killer ... เมื่อ womble เขียน

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

เขาอธิบายเกี่ยวกับสถานการณ์แวดล้อมที่ overcommit และ OOM killer ไม่ได้บังคับใช้หรือไม่กระทำ 'จริงๆ' (หากแอปพลิเคชันทั้งหมดจัดสรรหน่วยความจำตามต้องการและมีหน่วยความจำเสมือนเพียงพอที่จะจัดสรรหน่วยความจำเขียนจะติดตามการจัดสรรหน่วยความจำ ข้อผิดพลาดดังนั้นเราจึงไม่สามารถพูดเกี่ยวกับระบบที่มีการ overcommit ได้แม้ว่าจะมีการเปิดใช้งานกลยุทธ์การ overcommit) นั่นเป็นเรื่องของการรับเข้าโดยนัยที่ overcommit และ OOM killer ทำงานได้ดีที่สุดเมื่อไม่จำเป็นต้องมีการแทรกแซงซึ่งพวกเขาส่วนใหญ่สนับสนุนกลยุทธ์นี้เท่าที่ฉันสามารถบอกได้ (และฉันยอมรับว่าฉันไม่สามารถบอกได้มาก ... ) Morover หมายถึงแอพพลิเคชั่นที่มีพฤติกรรมเฉพาะเมื่อมีการจัดสรรหน่วยความจำล่วงหน้าทำให้ฉันคิดว่าการจัดการที่เฉพาะเจาะจงสามารถปรับได้ในระดับการกระจายแทนที่จะเป็นค่าเริ่มต้น

สำหรับสิ่งที่เกี่ยวข้องกับ JVM ก็คือเครื่องเสมือนซึ่งจำเป็นต้องจัดสรรทรัพยากรทั้งหมดที่จำเป็นสำหรับการเริ่มต้นดังนั้นจึงสามารถสร้างสภาพแวดล้อมที่ 'ปลอม' สำหรับแอปพลิเคชันและแยกทรัพยากรที่มีอยู่ออกจากโฮสต์ สิ่งแวดล้อมเท่าที่จะทำได้ ดังนั้นมันอาจจะดีกว่าที่จะให้มันล้มเหลวในการเริ่มต้นแทนหลังจากที่ในขณะที่เป็นผลมาจากสภาพ OOM 'ภายนอก' (เกิดจากการ overcommit / OOM นักฆ่า / อะไรก็ตาม) หรือทุกข์ทรมานสำหรับเงื่อนไขดังกล่าวรบกวนตัวเอง กลยุทธ์การจัดการ OOM ภายใน (โดยทั่วไป VM ควรได้รับทรัพยากรที่ต้องการตั้งแต่เริ่มต้นและระบบโฮสต์ควร 'เพิกเฉย' พวกเขาจนกว่าจะสิ้นสุดเช่นเดียวกับจำนวนหน่วยความจำฟิสิคัลที่ใช้ร่วมกับการ์ดกราฟิกที่ไม่เคยมีมา - - สัมผัสโดย OS)

เกี่ยวกับ Apache ฉันสงสัยว่าการให้เซิร์ฟเวอร์ทั้งหมดถูกฆ่าและรีสตาร์ทเป็นครั้งคราวนั้นดีกว่าการปล่อยให้เด็กคนเดียวพร้อมกับการเชื่อมต่อเดียวล้มเหลวจากการเริ่มต้น (= การเชื่อมต่อของเด็ก / การเชื่อมต่อ) (ราวกับว่ามันเป็นอินสแตนซ์ใหม่ทั้งหมดของ JVM ที่สร้างขึ้นหลังจากอินสแตนซ์อื่นทำงานได้ระยะหนึ่ง) ฉันเดาว่า 'ทางออก' ที่ดีที่สุดอาจขึ้นอยู่กับบริบทที่เฉพาะเจาะจง ตัวอย่างเช่นเมื่อพิจารณาถึงบริการอีคอมเมิร์ซอาจเป็นการดีกว่าที่จะมีบางครั้งการเชื่อมต่อกับแผนภูมิช็อปปิ้งที่ล้มเหลวแบบสุ่มแทนการสูญเสียบริการทั้งหมดโดยมีความเสี่ยงเช่นการขัดขวางการสรุปคำสั่งซื้อที่กำลังดำเนินอยู่หรือ (อาจแย่กว่านั้น) กระบวนการชำระเงินผลที่ตามมาทั้งหมดของคดี (อาจไม่เป็นอันตราย แต่อาจเป็นอันตราย - และแน่นอนเมื่อเกิดปัญหาขึ้น

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

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

ยิ่งไปกว่านั้นมันอาจไม่เป็นความจริงที่การฆ่ากระบวนการที่เป็นไปได้น้อยลงนั้นเป็นทางเลือกที่ดีเสมอ ตัวอย่างเช่นบนสภาพแวดล้อมเดสก์ท็อป (ลองคิดถึง nettop หรือเน็ตบุ๊กที่มีทรัพยากร จำกัด ตัวอย่าง) ผู้ใช้อาจเรียกใช้เบราว์เซอร์ที่มีหลายแท็บ (ดังนั้นการใช้หน่วยความจำ - สมมติว่านี่เป็นตัวเลือกแรกสำหรับ OOMK) รวมถึงแอปพลิเคชั่นอื่น ๆ (ตัวประมวลผลคำที่ไม่มีข้อมูลที่บันทึกไว้ไคลเอนต์โปรแกรมอ่านไฟล์ PDF โปรแกรมเล่นสื่อ ... ) รวมถึง daemons (ระบบ) สองสามตัวรวมถึงตัวจัดการไฟล์บางตัว ตอนนี้มีข้อผิดพลาดของ OOM เกิดขึ้นและ OOMK เลือกที่จะฆ่าเบราว์เซอร์ในขณะที่ผู้ใช้กำลังทำบางสิ่งที่ 'สำคัญ' ผ่านเน็ต ... ผู้ใช้จะต้องผิดหวัง ในอีกทางหนึ่งให้ปิดตัวจัดการไฟล์ไม่กี่ตัว '

อย่างไรก็ตามฉันคิดว่าผู้ใช้ควรเปิดใช้งานเพื่อตัดสินใจด้วยตัวเองในสิ่งที่ต้องทำ ในระบบเดสก์ท็อป (= โต้ตอบ) ซึ่งค่อนข้างง่ายในการทำหากมีทรัพยากรเพียงพอที่จะสำรองไว้เพื่อขอให้ผู้ใช้ปิดแอปพลิเคชันใด ๆ (แต่การปิดแท็บบางแท็บก็เพียงพอแล้ว) และจัดการตัวเลือกของเขา ประกอบด้วยการสร้างไฟล์ swap เพิ่มเติมหากมีพื้นที่เพียงพอ) สำหรับบริการ (และโดยทั่วไป) ฉันจะพิจารณาการปรับปรุงเพิ่มเติมที่เป็นไปได้อีกสองประการ: อย่างหนึ่งคือการบันทึก intervents ของ OOM killer เช่นเดียวกับกระบวนการเริ่มต้น / การฟอร์กความล้มเหลวในลักษณะที่ความล้มเหลวนั้น แจ้งให้ทราบถึงกระบวนการที่ออกการสร้างกระบวนการใหม่หรือการฟอร์ก - ดังนั้นเซิร์ฟเวอร์เช่น Apache ที่มีแพตช์ที่เหมาะสมสามารถให้การบันทึกที่ดีขึ้นสำหรับข้อผิดพลาดบางอย่าง); สิ่งนี้สามารถทำได้โดยไม่แยกจาก overcommit / OOMK ที่กำลังดำเนินการอยู่; ในสถานที่ที่สอง แต่ไม่ใช่สำหรับความสำคัญกลไกสามารถสร้างขึ้นเพื่อปรับแต่งอัลกอริทึม OOMK - ฉันรู้ว่ามันเป็นไปได้ในระดับหนึ่งในการกำหนดนโยบายเฉพาะในกระบวนการโดยพื้นฐานกระบวนการ แต่ฉันมุ่ง กลไกการกำหนดค่า 'รวมศูนย์' ตามรายชื่อแอปพลิเคชั่น (หรือรหัส) หนึ่งรายการหรือมากกว่านั้นเพื่อระบุกระบวนการที่เกี่ยวข้องและให้ความสำคัญในระดับหนึ่ง (ตามแอตทริบิวต์ที่ระบุไว้) กลไกดังกล่าวควร (หรืออย่างน้อยก็สามารถ) เป็นเลเยอร์เพื่อให้อาจมีรายการผู้ใช้กำหนดระดับบนสุดรายการที่กำหนดระบบ - (กระจาย -) และรายการที่กำหนดแอปพลิเคชัน (ระดับล่าง) (ดังนั้น ตัวอย่างเช่นตัวจัดการไฟล์ DE สามารถสั่งให้ OOMK ฆ่าตัวอย่างได้อย่างปลอดภัย

Morover สามารถให้ API เพื่อให้แอปพลิเคชันสามารถเพิ่มหรือลดระดับ 'ความสำคัญ' ในขณะใช้งาน (สำหรับวัตถุประสงค์ในการจัดการหน่วยความจำและไม่คำนึงถึงลำดับความสำคัญในการดำเนินการ) ดังนั้นโปรเซสเซอร์ Word อาจเริ่มต้นด้วย 'ความสำคัญ' ต่ำ แต่เพิ่มขึ้นเนื่องจากข้อมูลบางส่วนถูกเก็บไว้ก่อนที่จะล้างไปยังไฟล์หรือการดำเนินการเขียนกำลังดำเนินการและความสำคัญลดลงอีกครั้งเมื่อการดำเนินการดังกล่าวสิ้นสุดลง (คล้ายกันผู้จัดการไฟล์สามารถเปลี่ยนระดับเมื่อมันผ่านจาก liting ไฟล์เพื่อจัดการกับข้อมูลและ viceversa แทนที่จะใช้กระบวนการแยกต่างหากและ Apache สามารถให้ความสำคัญกับเด็กที่แตกต่างกันในระดับที่แตกต่างกันหรือเปลี่ยนสถานะลูกตามนโยบายบางอย่างที่ตัดสินใจโดย sysadmins และเปิดเผยผ่าน Apache - หรือเซิร์ฟเวอร์ชนิดอื่น ๆ - การตั้งค่า) แน่นอน, API ดังกล่าวสามารถและจะถูกทำร้าย / ใช้ในทางที่ผิด แต่ฉันคิดว่านั่นเป็นข้อกังวลเล็กน้อยเมื่อเทียบกับเคอร์เนลที่ฆ่ากระบวนการโดยพลการเพื่อเพิ่มหน่วยความจำโดยไม่มีข้อมูลที่เกี่ยวข้องใด ๆ เกี่ยวกับสิ่งที่เกิดขึ้นในระบบ (และการใช้หน่วยความจำ ไม่เพียงพอที่เกี่ยวข้องหรือ 'ตรวจสอบความถูกต้อง' สำหรับฉัน) - เฉพาะผู้ใช้ผู้ดูแลระบบและผู้เขียนโปรแกรมเท่านั้นที่สามารถตัดสินได้ว่ากระบวนการนั้นยังคง 'จำเป็นสำหรับเหตุผลบางประการเหตุผลคืออะไรและ / หรือหากแอปพลิเคชันอยู่ในสถานะผู้นำ เพื่อการสูญหายของข้อมูลหรือความเสียหาย / ปัญหาอื่น ๆ หากถูกฆ่า; อย่างไรก็ตามอาจมีข้อสันนิษฐานบางอย่างเช่นการค้นหาแหล่งข้อมูลบางประเภท (ตัวอธิบายไฟล์ซ็อกเก็ตเครือข่าย ฯลฯ ) ที่ได้มาจากกระบวนการและการดำเนินการที่รอดำเนินการสามารถบอกได้ว่ากระบวนการควรอยู่ในสถานะ 'ที่สูงกว่า หนึ่งชุด

หรือเพียงหลีกเลี่ยง overcommitting และปล่อยให้เคอร์เนลทำสิ่งที่เคอร์เนลต้องทำจัดสรรทรัพยากร (แต่ไม่ช่วยพวกมันโดยพลการอย่างที่นักฆ่า OOM ทำ) กระบวนการตั้งเวลาป้องกันความอดอยากและการหยุดชะงัก (หรือช่วยชีวิตจากพวกมัน) การแยกพื้นที่หน่วยความจำและอื่น ๆ ...

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

แน่นอนทุกอย่าง IMHO

หากหน่วยความจำของคุณถูกใช้อย่างหมดจดโดยกระบวนการในระดับที่อาจเป็นภัยคุกคามต่อความเสถียรของระบบดังนั้นนักฆ่า OOM จะเข้ามาในภาพ เป็นหน้าที่ของ OOM Killer ที่จะฆ่ากระบวนการจนกว่าหน่วยความจำจะเพียงพอสำหรับการทำงานที่ราบรื่นของกระบวนการที่เหลือ OOM Killer ต้องเลือกกระบวนการ "ดีที่สุด" เพื่อฆ่า "ดีที่สุด" ที่นี่หมายถึงกระบวนการที่จะเพิ่มหน่วยความจำสูงสุดเมื่อฆ่าและยังมีความสำคัญกับระบบน้อยที่สุด เป้าหมายหลักคือการฆ่ากระบวนการน้อยที่สุดที่จะลดความเสียหายที่เกิดขึ้นและในเวลาเดียวกันก็เพิ่มจำนวนหน่วยความจำที่เพิ่มขึ้น เพื่ออำนวยความสะดวกนี้เคอร์เนลจะรักษา oom_score สำหรับแต่ละกระบวนการ คุณสามารถดู oom_score ของแต่ละกระบวนการในระบบไฟล์ / proc ภายใต้ไดเรกทอรี pid

# cat /proc/10292/oom_score

สูงกว่ามูลค่าของ oom_score ของกระบวนการใด ๆ ที่สูงกว่าคือโอกาสในการถูก OOM Killer ถูกฆ่าในสถานการณ์ที่หน่วยความจำไม่เพียงพอ

เครดิต: - เคอร์เนล Linux กำลังเริ่มต้น OOM killer