จะทำให้ Linux OOM killer ไม่ฆ่ากระบวนการของฉันได้อย่างไร

ฉันจะให้ Linux OOM killer ไม่ฆ่ากระบวนการของฉันได้อย่างไรเมื่อหน่วยความจำกายภาพต่ำ แต่มีพื้นที่สว็อปมาก?

ฉันปิดใช้งานการฆ่า OOM และ overcommit ด้วย sysctl vm.overcommit_memory = 2

VM มี swap ที่ไม่มีการจัดระเบียบฟรี 3 GB และกระบวนการที่ OOM ถูกฆ่านั้นมีการใช้หน่วยความจำสูงสุดน้อยกว่า 200MB

ฉันรู้ว่าการแลกเปลี่ยนในระยะยาวจะน่ากลัวสำหรับประสิทธิภาพ แต่ฉันต้องใช้ swap ในตอนนี้เพื่อทำการทดสอบการทำงานภายใต้ valgrind ที่ความต้องการหน่วยความจำยิ่งใหญ่กว่ามาก

Mar  7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0
Mar  7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0
Mar  7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar  7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar  7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18
Mar  7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2
Mar  7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc
Mar  7 02:43:11 myhost kernel: Call Trace:
Mar  7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50
Mar  7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd
Mar  7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f
Mar  7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406
Mar  7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0
Mar  7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0
Mar  7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a
Mar  7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71
Mar  7 02:43:11 myhost kernel: Mem-Info:
Mar  7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0
Mar  7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0
Mar  7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0
Mar  7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674
Mar  7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0
Mar  7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0
Mar  7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
 mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36
0 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972
Mar  7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag
ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t
mp:0kB pages_scanned:792 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0
Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
Mar  7 02:43:11 myhost kernel: 71 total pagecache pages
Mar  7 02:43:11 myhost kernel: 42 pages in swap cache
Mar  7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093
Mar  7 02:43:11 myhost kernel: Free swap  = 3118172kB
Mar  7 02:43:11 myhost kernel: Total swap = 3334140kB
Mar  7 02:43:11 myhost kernel: 262014 pages RAM
Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
Mar  7 02:43:11 myhost kernel: 8149 pages reserved
Mar  7 02:43:11 myhost kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Mar  7 02:43:11 myhost kernel: [ 2054]     0  2054     5101        1      15       4      283             0 upstart-udev-br
Mar  7 02:43:11 myhost kernel: [ 2063]     0  2063    12362        1      28       4      184         -1000 systemd-udevd
Mar  7 02:43:11 myhost kernel: [ 3342]   102  3342     9780        1      23       3       89             0 dbus-daemon
Mar  7 02:43:11 myhost kernel: [ 3423]     0  3423    10864        1      26       3       85             0 systemd-logind
Mar  7 02:43:11 myhost kernel: [ 3441]     0  3441    15344        0      34       3      184         -1000 sshd
Mar  7 02:43:11 myhost kernel: [ 3450]     0  3450     4786        0      14       3       43             0 atd
Mar  7 02:43:11 myhost kernel: [ 3451]     0  3451     5915        0      17       4       65             0 cron
Mar  7 02:43:11 myhost kernel: [ 3457]   101  3457    63962        0      28       3      202             0 rsyslogd
Mar  7 02:43:11 myhost kernel: [ 3516]     0  3516     3919        1      13       3      156             0 upstart-file-br
Mar  7 02:43:11 myhost kernel: [ 3518]     0  3518     4014        0      13       3      265             0 upstart-socket-
Mar  7 02:43:11 myhost kernel: [ 3557]     0  3557    66396        0      32       3     1802             0 fail2ban-server
Mar  7 02:43:11 myhost kernel: [ 3600]     0  3600     3956        1      13       3       39             0 getty
Mar  7 02:43:11 myhost kernel: [ 3601]     0  3601     3198        1      12       3       37             0 getty
Mar  7 02:43:11 myhost kernel: [ 3673]     0  3673    26411        1      55       3      252             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3740]  1000  3740    26411        1      52       3      253             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3741]  1000  3741     5561        0      16       3      431             0 bash
Mar  7 02:43:11 myhost kernel: [ 3820]   103  3820     7863        1      21       3      152             0 ntpd
Mar  7 02:43:11 myhost kernel: [ 3837]  1000  3837    31990        0      58       4    12664             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3841]  1000  3841    32006        0      59       4    12812             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3844]  1000  3844    31950        0      57       4    12035             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3849]  1000  3849    31902        0      56       4    11482             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3853]  1000  3853     1087        0       7       3       27             0 lsof
Mar  7 02:43:11 myhost kernel: [ 3854]     0  3854    26140        5      55       3      230             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3855]   104  3855    15699        0      33       3      202             0 sshd
Mar  7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-amd64-) score 11 or sacrifice child
Mar  7 02:43:11 myhost kernel: Killed process 3841 (memcheck-amd64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB

นี่คือ / proc / meminfo

MemTotal:        1015460 kB
MemFree:          277508 kB
MemAvailable:     322032 kB
Buffers:            8336 kB
Cached:            42208 kB
SwapCached:        46088 kB
Active:            58844 kB
Inactive:         116100 kB
Active(anon):      34784 kB
Inactive(anon):    89620 kB
Active(file):      24060 kB
Inactive(file):    26480 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       3334140 kB
SwapFree:        3215756 kB
Dirty:                16 kB
Writeback:             0 kB
AnonPages:        121128 kB
Mapped:            15072 kB
Shmem:                 4 kB
Slab:              22668 kB
SReclaimable:       8028 kB
SUnreclaim:        14640 kB
KernelStack:        2016 kB
PageTables:         2532 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3841868 kB
Committed_AS:     380460 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
DirectMap4k:       14208 kB
DirectMap2M:     1034240 kB
DirectMap1G:           0 kB

สิ่งนี้ดูเหมือนจะมีปัญหาในการรวมกันของสองปัจจัย:

• การใช้เครื่องเสมือน
• ข้อผิดพลาดเคอร์เนลที่เป็นไปได้

นี่เป็นส่วนหนึ่งของบรรทัดที่อธิบายสาเหตุที่เกิดขึ้น:

7 มี.ค. 02:43:11 เคอร์เนล myhost: memcheck-amd64- เรียกใช้ oom-killer: gfp_mask = 0x24002c2, คำสั่ง = 0, oom_score_adj = 0

บรรทัดอื่น ๆ คือ:

Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

| บรรทัดแรกคือหน้ากาก GFP ที่กำหนดไว้สำหรับการจัดสรร โดยทั่วไปจะอธิบายถึงสิ่งที่เคอร์เนลได้รับอนุญาต / ไม่ได้รับอนุญาตให้ทำตามคำขอนี้ หน้ากากบ่งบอกถึงพวงธงมาตรฐาน บิตสุดท้าย '2' อย่างไรก็ตามบ่งชี้ว่าการจัดสรรหน่วยความจำควรมาจากHighMemโซน

หากคุณมองอย่างใกล้ชิดที่เอาต์พุต OOM คุณจะไม่เห็นHighMem/Normalโซนใดๆ อยู่จริง

Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem(โดยทั่วไปเรียกอีกอย่างว่าNormalx86_64) มีแนวโน้มที่จะแมปหน่วยความจำสำหรับโซนที่อยู่นอกช่วงมาตรฐาน 896MiB ซึ่งสามารถเข้าถึงเคอร์เนลได้โดยตรงบนระบบ 32 บิต ใน x86_64 HighMem/Normalดูเหมือนว่าจะครอบคลุมทุกหน้าเหนือ 3GiB ในขนาด

DMA32มีโซนที่ใช้สำหรับหน่วยความจำที่สามารถเข้าถึงได้บนอุปกรณ์ DMA 32- บิตนั่นคือคุณสามารถระบุที่อยู่ด้วยตัวชี้ 4 ไบต์ ฉันเชื่อว่าDMAเป็นอุปกรณ์ DMA 16 บิต

โดยทั่วไปแล้วNormalจะไม่มีระบบหน่วยความจำเหลืออยู่เนื่องจากDMA32ครอบคลุมที่อยู่เสมือนที่มีอยู่ทั้งหมดแล้ว

สาเหตุที่คุณ OOM kill เกิดขึ้นเนื่องจากมีการจัดสรรหน่วยความจำสำหรับHighMemโซนที่มี 0 หน้า เนื่องจากตัวจัดการหน่วยความจำไม่เพียงพอที่จะทำให้โซนนี้มีหน้าให้ใช้โดยการแลกเปลี่ยนฆ่ากระบวนการอื่น ๆ หรือกลอุบายอื่น ๆ OOM-killer เพียงแค่ฆ่ามัน

ฉันเชื่อว่าสิ่งนี้เกิดจากโฮสต์ VM ballooning เมื่อบูตเครื่อง บนระบบ KVM มีสองค่าที่คุณสามารถตั้งค่าได้

• หน่วยความจำปัจจุบัน
• หน่วยความจำที่มีอยู่

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

เมื่อ KVM VM บูทขึ้นเครื่องจะเริ่มต้นด้วยการจัดสรรหน่วยความจำสูงสุดเท่าที่จะเป็นไปได้ (หน่วยความจำที่มีอยู่) ในระหว่างขั้นตอนการบู๊ตของระบบ KVM จะค่อย ๆ ดึงหน่วยความจำนี้กลับคืนมาโดยปล่อยให้คุณตั้งค่าหน่วยความจำปัจจุบันที่คุณมีอยู่แทน

ความเชื่อของฉันมันคือสิ่งที่เกิดขึ้นที่นี่ Linode ช่วยให้คุณสามารถขยายหน่วยความจำให้มากขึ้นเมื่อเริ่มต้นระบบ

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

ในแง่ของการแก้ไขปัญหานี้คุณมีสองตัวเลือก

1. นำรายการนี้ขึ้นมาในรายการส่งเมลเคอร์เนลเพื่อดูว่านี่เป็นข้อบกพร่องพฤติกรรมที่คาดหวังหรือไม่มีอะไรเกี่ยวข้องกับสิ่งที่ฉันพูด

2. ขอให้ linode ตั้งค่า 'หน่วยความจำที่มีอยู่' บนระบบให้เป็น 1GiB ที่ได้รับมอบหมายเช่นเดียวกับ 'หน่วยความจำปัจจุบัน' ดังนั้นระบบจะไม่ลูกโป่งและไม่เคยได้รับโซนปกติตอนบู๊ตทำให้ธงชัดเจน โชคดีที่ทำให้พวกเขาทำเช่นนั้น!

คุณควรทดสอบว่าเป็นกรณีนี้โดยตั้งค่า VM ของคุณเองในการตั้งค่า KVM ที่มีให้ 6GiB, ปัจจุบันเป็น 1GiB และรันการทดสอบของคุณโดยใช้เคอร์เนลเดียวกันเพื่อดูว่าพฤติกรรมนี้ที่คุณเห็นข้างต้นเกิดขึ้นหรือไม่ หากเป็นเช่นนั้นให้เปลี่ยนการตั้งค่า 'ที่มีอยู่' ให้เท่ากับ 1GiB ปัจจุบันและทำซ้ำการทดสอบ

ฉันกำลังทำการเดาที่ได้รับการศึกษามากมายที่นี่และการอ่านระหว่างบรรทัดเพื่อหาคำตอบนี้ แต่สิ่งที่ฉันกำลังพูดดูเหมือนจะสอดคล้องกับข้อเท็จจริงที่ระบุไว้แล้ว

ฉันขอแนะนำให้ทดสอบสมมติฐานของฉันและแจ้งให้เราทุกคนทราบผลลัพธ์

หากต้องการตอบคำถามพาดหัวให้ใช้oom_score_adj(เคอร์เนล> = 2.6.36) หรือสำหรับเมล็ดก่อนหน้า (> = 2.6.11) oom_adjดู man proc

/ proc / [pid] / oom_score_adj (ตั้งแต่ Linux 2.6.36) ไฟล์นี้สามารถใช้เพื่อปรับแก้ความไม่ดีฮิวริสติกที่ใช้ในการเลือกกระบวนการที่จะถูกฆ่าในสภาพหน่วยความจำไม่เพียงพอ ...

/ proc / [pid] / oom_adj (ตั้งแต่ Linux 2.6.11) ไฟล์นี้สามารถใช้เพื่อปรับคะแนนที่ใช้ในการเลือกกระบวนการที่ควรจะถูกฆ่าในสถานการณ์หน่วยความจำนอก (OOM) ...

ยังมีอีกมากมายให้อ่าน แต่การตั้งค่า oom_score_adj เป็น -1000 หรือ oom_adj ถึง -17 จะบรรลุสิ่งที่คุณต้องการ

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

ความคิดหลายประการ (จากความคิดเห็นของฉันด้านบน) และลิงก์ไปยังการสอดแทรกอ่านเกี่ยวกับสถานการณ์ของคุณ:

• ฉันขอแนะนำให้คุณตรวจสอบว่า 1) คุณสามารถใช้มากกว่า 3Gb กับเคอร์เนล & config ปัจจุบันของคุณ (& cpu) [เพราะหาก 3Gb เป็นข้อ จำกัด สำหรับระบบ & OS ของคุณคุณเกิน] 2) ให้คุณอนุญาตการสลับและระบบย่อยการสลับตำแหน่งอยู่และทำงานได้ โชคดี (ฉันจะไม่อธิบายว่ามันขึ้นอยู่กับการตั้งค่า & เฉพาะของคุณเครื่องมือค้นหาจะช่วยได้) และที่คุณไม่ได้ล้นตารางเคอร์เนล (nb ของ pids? หรืออย่างอื่น (บางคนอาจจะถูกตั้งค่าที่เวลารวบรวมเคอร์เนล)

• ตรวจสอบว่าสิ่งของทั้งหมด (ฮาร์ดแวร์หรือฮาร์ดแวร์จำลองของ vm ฯลฯ ) คือ 64 บิต (ดูตัวอย่าง: https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ) ระบบย่อย cpu & host & vm & vm OS ควรเปิดใช้งานแบบ 64 บิตไม่เช่นนั้นคุณจะไม่มี 64-bit vm จริง

• บางคนอ่านดี:

  • วิธีการวินิจฉัยสาเหตุของกระบวนการฆ่า oom-killer : บนเว็บไซต์นี้ ให้ลิงค์ที่น่าสนใจhttp://linux-mm.org/OOM_Killerและผู้ใช้รายอื่นแนะนำเครื่องมือ atop ซึ่งสามารถช่วยวินิจฉัยสิ่งที่เกิดขึ้น
  • https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12 แสดงแผนผังการตัดสินใจสำหรับ OOM (ของเวอร์ชั่นเก่าดังนั้น ymmv อ่านแหล่งที่มา ^^)
  • https://lwn.net/Articles/317814/ : "Taming the OOM killer" แสดงให้เห็นถึงวิธีการสร้างกลุ่ม "invicible" และวางกระบวนการของคุณ
  • http://eloquence.marxmeier.com/sdb/html/linux_limits.html : แสดงข้อ จำกัด เคอร์เนลทั่วไป
  • http://win.tue.nl/~aeb/linux/lk/lk-9.html : เป็นการอ่านที่ดี (พื้นที่ที่สูญเปล่าด้วยวิธีการจัดสรรบางอย่าง ฯลฯ ) แม้ว่าจะเป็นวันที่จริง ๆ (และอยู่เพียง 32- เท่านั้น สถาปัตยกรรมบิต ... )
  • http://bl0rg.krunch.be/oom-frag.htmlแสดงเหตุผลบางประการว่าทำไม "นักฆ่า OOM อาจถูกเรียกใช้แม้ว่าจะยังมีหน่วยความจำเหลืออยู่"
  • https://stackoverflow.com/questions/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left : ให้วิธีตรวจสอบว่าระบบของคุณจัดสรรหน่วยความจำอย่างไร
  • https://serverfault.com/a/724518/146493 : คำตอบที่ยอดเยี่ยมให้วิธี detailled รู้จริง ๆ ว่าเกิดอะไรขึ้น (แต่ ... กำหนดเป้าหมายเป็นคำถามแบบ 32 บิตดังนั้น ymmv ยังคงอ่านและตอบได้อย่างไม่น่าเชื่อ)

• และในที่สุด: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.htmlแสดงวิธีที่จะป้องกันไม่ให้กระบวนการของคุณถูกโจมตีโดยนักฆ่าอุ้ม! ( echo -17 > /proc/PROCESSPID/oom_adj) อาจมีแนวโน้มที่จะเปลี่ยนแปลงและอาจเป็นสิ่งที่ไม่ดี (ทำให้เกิดความล้มเหลวประเภทอื่นเนื่องจากระบบในขณะนี้ไม่สามารถฆ่าผู้กระทำผิดหลัก ... ) ใช้ด้วยความระมัดระวัง @iain โปรดทราบว่า "oom_adj" สำหรับเมล็ดที่เก่ากว่าและควรแทนที่ด้วย "oom_score_adj" ในที่ใหม่กว่า ขอบคุณฉัน)

นอกเหนือจากที่กล่าวถึงการoom_score_adjเพิ่มขึ้นของกระบวนการที่เป็นปัญหา (ซึ่งอาจไม่ช่วยได้มากนัก - จะทำให้มีโอกาสน้อยกว่าที่กระบวนการนั้นจะถูกฆ่าเป็นครั้งแรก แต่เนื่องจากเป็นเพียงกระบวนการหน่วยความจำที่เข้มข้นเท่านั้น ฆ่าแล้ว) นี่คือแนวคิดบางอย่างที่จะปรับแต่ง:

• ถ้าคุณตั้งค่าvm.overcommit_memory=2ยังบิดvm.overcommit_ratioไป 90 อาจ (หรือตั้งvm.overcommit_memory=0- ดูเอกสาร kernel overcommit )
• เพิ่มขึ้นvm.min_free_kbytesเพื่อรักษา RAM ทางกายภาพอยู่เสมอและลดโอกาสของ OOM ที่จะต้องฆ่าบางสิ่งบางอย่าง (แต่อย่าหักโหมเพราะ OOM จะเกิดขึ้นทันที)
• เพิ่มvm.swappinessเป็น 100 (เพื่อให้การสลับเคอร์เนลพร้อมใช้งานมากขึ้น )

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

ฉันจะลองเปิดใช้งาน overcommit และดูว่าช่วยได้หรือไม่ กระบวนการของคุณดูเหมือนจะล้มเหลวในการforkโทรซึ่งต้องใช้หน่วยความจำเสมือนมากเท่าที่กระบวนการเริ่มต้นมี overcommit_memory=2ไม่ทำให้กระบวนการของคุณมีภูมิคุ้มกันต่อนักฆ่า OOM แต่จะป้องกันกระบวนการของคุณจากการเรียกใช้งานโดยการจัดสรรมากเกินไป กระบวนการอื่นอาจทำให้เกิดข้อผิดพลาดในการจัดสรรที่ไม่เกี่ยวข้อง (เช่นการบล็อกหน่วยความจำต่อเนื่อง) ซึ่งยังทำให้เกิด OOM killer และทำให้กระบวนการของคุณถูกกำจัด

อีกทางเลือกหนึ่ง (และมากไปกว่านั้น) ตามที่ความคิดเห็นหลายข้อแนะนำให้ซื้อ RAM เพิ่มเติม

เรื่องสั้น - ลองใช้เคอร์เนลเวอร์ชันอื่น ฉันมีระบบที่แสดงข้อผิดพลาดของ OOM ด้วย 4.2.0-x และ 4.4.0-x kernels แต่ไม่ใช่ด้วย 3.19.0-x

เรื่องยาว: (ไม่ยาวเกินไป!) ฉันยังมี Compaq DC5000 ที่ให้บริการอยู่ที่นี่ - ปัจจุบันมี RAM 512MB (และบางส่วนของที่เช่น 32-128MB ถูกมอบให้กับวิดีโอออนบอร์ด .. ) ส่วนใหญ่ให้บริการ NFS ฉันมีจอภาพติดอยู่ดังนั้นบางครั้งฉันจะลงชื่อเข้าใช้ (Ubuntu Classic ไม่มีความสามัคคี)

ผ่าน Ubuntu HWE ฉันใช้งานเคอร์เนล 3.19.x อยู่ครู่หนึ่ง มันจะจบลงด้วยการแลกเปลี่ยนสิ่งของ 200-300MB แต่เห็นได้ชัดว่ามันเป็นสิ่งที่ไม่ได้ใช้ไม่มีกิจกรรมการแลกเปลี่ยนใด ๆ จากการแลกเปลี่ยนในภายหลังเท่าที่ฉันจะบอกได้

เคอร์เนล 4.2.0-x และตอนนี้เคอร์เนล 4.4.0-x ฉันสามารถเริ่มเขียน NFS แบบหนา ๆ ได้เพียง 220MB ในการแลกเปลี่ยน (เช่น 1.3GB ฟรี) และมันจะเริ่ม OOM ฆ่าสิ่งต่าง ๆ ฉันจะไม่เรียกร้องถ้ามันเป็นข้อผิดพลาดเคอร์เนลหรือ "ปัญหาการปรับแต่ง" (เช่นสำรอง 64MB ที่ปกติดี แต่สูงเกินไปในระบบ ~ 400MB หรือมากกว่านั้น?)

ไม่ดูหมิ่นคนที่บอกว่าจะทำลายเพราะเขาคาดหวังว่าจะใช้ swap; ด้วยความเคารพคุณผิด มันจะไม่เร็ว แต่ฉันเคยไป 1 หรือ 2GB ในการแลกเปลี่ยนในบางระบบ 512MB-1GB แน่นอนว่าซอฟท์แวร์บางตัวทำจากมอลส์เป็นพวงของแรม แต่ในกรณีของฉัน (เนื่องจากฉันใช้ซอฟต์แวร์เดียวกันบนเคอร์เนลที่แตกต่างกัน) นี่ไม่ใช่กรณีอย่างชัดเจน