Bagaimana cara mendapatkan pembunuh OOM Linux untuk tidak membunuh proses saya?

28

Bagaimana saya membuat pembunuh OOM Linux tidak membunuh proses saya ketika memori fisik rendah tetapi ada banyak ruang swap?

Saya telah menonaktifkan pembunuhan OOM dan overcommit dengan sysctl vm.overcommit_memory = 2.

VM memiliki 3 GB swap bebas yang benar-benar gratis dan proses yang sedang dibunuh OOM memiliki penggunaan memori maksimal kurang dari 200MB.

Saya tahu bahwa pertukaran jangka panjang akan mengerikan untuk kinerja, tetapi saya perlu menggunakan swap sekarang untuk melakukan pengujian fungsional di bawah valgrind di mana persyaratan memori jauh lebih besar.

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

Ini adalah / 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

linux swap oom

— Coder
sumber

8

Sangat jelas dari jejak panggilan bahwa kernel tidak memiliki cukup memori. Adapun mengapa itu tidak bertukar, yang dapat memiliki banyak penyebab berbeda, yang semuanya terlalu panjang untuk dijelaskan sepenuhnya dalam 500 karakter. Tapi milikmu sepertinya tidak ada halaman yang dapat direklamasi ( all_unreclaimableya). Ini adalah halaman-halaman yang dikunci dalam RAM, umumnya karena disematkan atau digunakan oleh kernel. Tidak ada yang tersisa di RAM yang dapat ditukar saat itu; semua yang bisa ditukar sudah ada. Sekali lagi, solusinya adalah lebih banyak RAM.

— Michael Hampton

1

@MichaelHampton Sisa memori digunakan oleh aplikasi reguler. Mengapa kernel tidak dapat mendorong mereka untuk bertukar? Harap jawab pertanyaan saya, "Jika apa yang Anda katakan itu benar, lalu bagaimana mungkin ada proses yang pernah bercabang setelah semua memori fisik digunakan?"

— Coder

1

@MichaelHampton Saya menonaktifkan forking dan sekarang fail2ban memanggil pembunuh oom yang menyebabkan proses saya terbunuh. Apa gunanya melakukan swap jika kernel tidak mau menggunakannya? Lebih penting lagi, bagaimana cara mengkonfigurasi kernel sehingga berhenti kehabisan memori.

— Coder

4

@MatthewIfe: Jika Anda tahu jawabannya, silakan kirim di sini. Situs Stack Exchange adalah untuk kepentingan semua orang yang membaca, bukan hanya OP yang mengajukan pertanyaan.

— R ..

4

Bertukar dalam VM tidak dianggap sebagai Praktik Terbaik. Alokasikan lebih banyak memori nyata ke VM Anda. Jika Anda tidak dapat menambahkan lebih banyak memori, bawa di rumah ke perangkat fisik daripada meninggalkannya di rental berukuran kecil.

— Criggie

36

Ini tampaknya menjadi masalah dalam kombinasi dua faktor:

Menggunakan mesin virtual.
Kemungkinan bug kernel.

Ini adalah sebagian dari garis yang menjelaskan mengapa ini terjadi:

7 Maret 02:43:11 myhost kernel: memcheck-amd64- dipanggil oom-killer: gfp_mask = 0x24002c2, order = 0, oom_score_adj = 0

Baris lainnya adalah ini:

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

Baris pertama adalah topeng GFP yang ditugaskan untuk alokasi. Ini pada dasarnya menjelaskan apa yang diizinkan / tidak boleh dilakukan kernel untuk memuaskan permintaan ini. Topeng menunjukkan banyak bendera standar. Bit terakhir, '2' akan tetapi menunjukkan alokasi memori harus berasal dari HighMemzona.

Jika Anda melihat dengan seksama pada output OOM, Anda akan melihat tidak ada HighMem/Normalzona sebenarnya.

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(umumnya juga disebut Normalpada x86_64) cenderung memetakan memori untuk zona di luar rentang 896MiB standar yang langsung dapat diakses oleh kernel pada sistem 32 bit. Pada x86_64 HighMem/Normaltampaknya menutupi semua halaman di atas ukuran 3GiB.

DMA32berisi zona yang digunakan untuk memori yang dapat diakses pada perangkat DMA 32-bit, yaitu Anda dapat mengatasinya dengan pointer 4 byte. Saya percaya DMAuntuk perangkat DMA 16-bit.

Secara umum, pada sistem memori rendah Normaltidak akan ada, mengingat itu sudah DMA32mencakup semua alamat virtual yang tersedia.

Alasan Anda membunuh OOM adalah karena ada alokasi memori untuk HighMemzona dengan 0 halaman tersedia. Mengingat kehabisan memori handler sama sekali tidak ada cara untuk memuaskan membuat zona ini memiliki halaman untuk digunakan dengan bertukar, membunuh proses lain atau trik lain, pembunuh OOM hanya membunuhnya.

Saya percaya ini disebabkan oleh balon host VM pada saat boot up. Pada sistem KVM, ada dua nilai yang bisa Anda atur.

Memori saat ini.
Memori yang tersedia.

Cara kerjanya adalah Anda dapat menambahkan memori ke server hingga memori yang tersedia. Namun sistem Anda sebenarnya diberi memori saat ini.

Ketika VM KVM melakukan booting, itu dimulai dengan penjatahan memori maksimum yang mungkin diberikan (memori yang tersedia). Secara bertahap selama fase boot sistem KVM mencakar kembali memori ini menggunakan balonnya, dan membuat Anda memiliki pengaturan memori saat ini yang Anda miliki.

Keyakinan saya itulah yang terjadi di sini. Linode memungkinkan Anda untuk memperluas memori, memberi Anda lebih banyak saat sistem dimulai.

Ini berarti bahwa ada Normal/HighMemzona di awal masa pakai sistem. Ketika hypervisor melenyapkannya, zona normal dengan benar menghilang dari manajer memori. Tapi, saya menduga bahwa pengaturan bendera apakah zona tersebut tersedia untuk dialokasikan dari tidak dibersihkan ketika seharusnya. Ini mengarahkan kernel untuk mencoba mengalokasikan dari zona yang tidak ada.

Dalam hal menyelesaikan ini, Anda memiliki dua opsi.

Bawa ini pada mailing list kernel untuk melihat apakah ini benar-benar bug, perilaku yang diharapkan atau tidak ada hubungannya sama sekali dengan apa yang saya katakan.
Minta linode untuk mengatur 'memori yang tersedia' pada sistem menjadi tugas 1GiB yang sama dengan 'memori saat ini'. Dengan demikian sistem tidak pernah balon dan tidak pernah mendapatkan zona Normal saat boot, menjaga bendera jelas. Semoga berhasil membuat mereka melakukan itu!

Anda harus dapat menguji apakah ini masalahnya dengan mengatur VM Anda sendiri dalam pengaturan KVM yang tersedia untuk 6GiB, aktif ke 1GiB dan menjalankan pengujian Anda menggunakan kernel yang sama untuk melihat apakah perilaku yang Anda lihat di atas terjadi. Jika ya, ubah pengaturan 'tersedia' untuk menyamai arus 1GiB dan ulangi pengujian.

Saya membuat banyak dugaan terpelajar di sini dan membaca di antara garis-garis agak untuk datang dengan jawaban ini, tetapi apa yang saya katakan tampaknya cocok dengan fakta yang sudah diuraikan.

Saya sarankan menguji hipotesis saya dan membiarkan kita semua tahu hasilnya.

— Matthew Ife
sumber

4

Itu jawaban yang menyeluruh (dan dijelaskan dengan baik)!

— Olivier Dulac

2

Ya, jawaban yang sangat baik ... Jauh lebih bermanfaat daripada komentar orang-orang bahwa "OP harus secara membuta mempercayai pesan-pesan kernel" tanpa upaya untuk menjelaskan mengapa ruang swap yang tersedia tidak digunakan.

— Michael Martinez

31

Untuk menjawab pertanyaan utama Anda, gunakan oom_score_adj(kernel> = 2.6.36) atau untuk kernel sebelumnya (> = 2.6.11) oom_adj, lihat man proc

/ proc / [pid] / oom_score_adj (sejak Linux 2.6.36) File ini dapat digunakan untuk menyesuaikan kejahatan heuristik yang digunakan untuk memilih proses mana yang terbunuh dalam kondisi kehabisan memori ...

/ proc / [pid] / oom_adj (sejak Linux 2.6.11) File ini dapat digunakan untuk menyesuaikan skor yang digunakan untuk memilih proses mana yang harus dimatikan dalam situasi kehabisan memori (OOM) ...

Ada banyak lagi yang harus dibaca tetapi pengaturan oom_score_adj ke -1000 atau oom_adj ke -17 akan mencapai apa yang Anda inginkan.

Masalahnya adalah sesuatu yang lain akan terbunuh. Mungkin akan lebih baik untuk menentukan mengapa OOM dipanggil dan menghadapinya.

— user9517 mendukung GoFundMonica
sumber

4

+1 untuk "selesaikan masalah yang mendasarinya". Apakah mungkin bahwa perangkat lunak yang menyinggung (atau sesuatu yang lain) baru saja mencoba untuk memotong sebagian besar inti? Permintaan memori yang lebih banyak , yang akan membawa hal-hal ke wilayah peringatan merah, yang cenderung memicu pembunuh OOM.

— MadHatter mendukung Monica

11

@Coder: Pemrogram kernel Linux dan kernel Linux jelas tahu lebih banyak dari Anda. Proses Anda terbunuh karena (meskipun ada protes) tidak ada cukup memori. Jika Anda merasa ini tidak benar, maka ajukan laporan bug . Jika Anda tidak akan mendengarkan apa yang dikatakan orang-orang yang berpengetahuan luas maka mungkin Anda harus membayar untuk dukungan Anda karena saran itu sepadan dengan apa yang Anda bayar untuk itu. Saran tidak akan berbeda tetapi Anda akan membayarnya jadi akan lebih menghargainya.

— user9517 mendukung GoFundMonica

4

@Coder Saya bukan programmer, sayangnya. Hanya saja itu terjebak di antara dua kemungkinan: bahwa kernel tidak tahu cara menggunakan VM, dan bahwa seorang programmer telah membuat kesalahan, saya tahu yang mana uang saya aktif.

— MadHatter mendukung Monica

1

@coder aku 'seseorang'. Biarkan saya tahu cara berhubungan.

— Matthew Ife

1

@ MadHatter dari menjalankan sistem linux 1000s saya dapat memberitahu Anda: BUKAN kasus yang bisa berasumsi tidak ada masalah dalam manajemen memori atau bagian lain dari kernel. Ini tidak seperti platform unix tingkat tinggi dan sementara semuanya biasanya berfungsi dengan baik, tidak masuk akal untuk mengambil kedua sisi dengan cara dogmatis.

— Florian Heigl

12

Beberapa pemikiran (dari komentar saya di atas), dan tautan ke interresting membaca tentang situasi Anda:

Saya sarankan Anda memeriksa bahwa 1) Anda dapat memberi alamat lebih dari 3Gb dengan kernel & config (& cpu) Anda saat ini [karena jika 3Gb adalah batas untuk sistem & os Anda, Anda melebihi itu]. 2) Anda mengizinkan swapping dan subsistem swapping sudah ada dan berfungsi. semoga berhasil (saya tidak akan menjelaskan caranya, karena tergantung pada pengaturan & spesifik Anda. Mesin pencari akan membantu). DAN bahwa Anda tidak melimpahi tabel kernel (nb pids? Atau yang lainnya (beberapa mungkin dapat diatur pada waktu kompilasi kernel).
Periksa apakah semuanya (perangkat keras, atau perangkat keras vm yang disimulasikan, dll.) Adalah 64 bit. (lihat misalnya: https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). Subsistem cpu & host OS & vm & vm OS semuanya harus diaktifkan 64-bit, jika tidak, Anda tidak akan memiliki vm 64-bit nyata
Beberapa bacaan bagus:
- Cara mendiagnosis penyebab proses pembunuhan oom-killer : di situs ini. Memberikan tautan yang bagus, http://linux-mm.org/OOM_Killer , dan pengguna lain memperkenalkan alat di atas, yang dapat membantu mendiagnosis apa yang terjadi
- https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12 menunjukkan pohon keputusan untuk OOM (dari versi yang lebih lama, jadi ymmv. Baca sumbernya ^^)
- https://lwn.net/Articles/317814/ : "Menjinakkan pembunuh OOM" menunjukkan, di antaranya, cara membuat grup "tak terlihat" dan memasukkan proses Anda di dalamnya
- http://eloquence.marxmeier.com/sdb/html/linux_limits.html : menunjukkan beberapa batasan umum kernel
- http://win.tue.nl/~aeb/linux/lk/lk-9.html : adalah bacaan yang baik (ruang terbuang dengan beberapa metode alokasi, dll) meskipun benar-benar bertanggal (dan dengan demikian hanya mendukung 32- arsitektur bit ...)
- http://bl0rg.krunch.be/oom-frag.html menunjukkan beberapa alasan mengapa "Pembunuh OOM dapat dipanggil bahkan ketika masih ada banyak memori yang tersedia"
- https://stackoverflow.com/questions/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left : memberikan cara untuk memeriksa bagaimana sistem Anda mengalokasikan memori
- https://serverfault.com/a/724518/146493 : jawaban yang sangat baik memberikan cara yang tepat untuk mengetahui apa yang sebenarnya terjadi (tapi ... menargetkan pertanyaan 32-bit, jadi ymmv. Masih membaca dan menjawab yang luar biasa, meskipun).
dan akhirnya: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html menunjukkan cara untuk mencegah proses Anda menjadi sasaran oleh pembunuh bayaran! ( echo -17 > /proc/PROCESSPID/oom_adj). Bisa rentan terhadap perubahan, dan bisa menjadi hal yang buruk (menyebabkan kegagalan jenis lain karena sistem sekarang tidak bisa begitu saja membunuh pelaku utama ...) Gunakan dengan hati-hati. @ iain perhatikan bahwa "oom_adj" adalah untuk kernel yang lebih lama, dan harus diganti dengan "oom_score_adj" di kernel yang lebih baru. Terima kasih, Iain)

— Olivier Dulac
sumber

1

oom_adj hanya berlaku untuk kernel yang lebih lama, yang lebih baru menggunakan oom_score_adj.

— user9517 mendukung GoFundMonica

disclaimer: Saya tidak dapat memberikan info lebih lengkap daripada beberapa tautan di atas, karena saya tidak dapat mengakses sistem linux saat ini ... dan ada begitu banyak hal untuk diperiksa. Mungkin seseorang akan turun tangan dan memberikan prosedur langkah demi langkah yang bagus ... (jawaban serverfault, yang terakhir dari tautan "bacaan baik" dalam jawaban saya, seperti itu, dan merupakan bacaan yang luar biasa.)

— Olivier Dulac

6

selain itu disebutkan oom_score_adjpeningkatan untuk proses yang dimaksud (yang mungkin tidak akan banyak membantu - itu akan membuatnya lebih kecil kemungkinannya bahwa proses itu akan dibunuh PERTAMA, tetapi karena itu hanya sistem proses intensif memori mungkin tidak akan pulih sampai akhirnya dibunuh), berikut adalah beberapa ide untuk mengubah:

jika Anda mengatur vm.overcommit_memory=2, juga men vm.overcommit_ratio- tweak ke mungkin 90 (atau, set vm.overcommit_memory=0- lihat kernel overcommit docs )
meningkatkan vm.min_free_kbytesagar selalu menjaga beberapa RAM fisik gratis dan dengan demikian mengurangi kemungkinan OOM perlu membunuh sesuatu (tapi jangan berlebihan, karena akan OOM langsung).
naik vm.swappinessmenjadi 100 (untuk membuat swap kernel lebih mudah )

Perhatikan bahwa jika Anda memiliki memori terlalu sedikit untuk menyelesaikan tugas yang dihadapi, bahkan jika Anda tidak OOM, itu mungkin (atau mungkin tidak) menjadi sangat lambat - pekerjaan setengah jam (pada sistem dengan RAM yang cukup) dapat dengan mudah memakan waktu beberapa minggu ( ketika RAM diganti dengan swap) untuk menyelesaikan dalam kasus yang ekstrim, atau bahkan menggantung seluruh VM. Itu terutama terjadi jika swap ada pada disk rotasi klasik (bukan SSD) karena pembacaan / penulisan acak yang sangat mahal.

— Matija Nalis
sumber

3

Saya akan mencoba mengaktifkan overcommit dan melihat apakah itu membantu. Proses Anda tampaknya gagal di dalam forkpanggilan, yang membutuhkan memori virtual sebanyak proses awalnya. overcommit_memory=2tidak membuat proses Anda kebal terhadap pembunuh OOM, itu hanya mencegah proses Anda memicu itu dengan mengalokasikan terlalu banyak. Proses lain dapat menghasilkan kesalahan alokasi yang tidak terkait (misalnya mendapatkan blok memori yang berdekatan), yang masih memicu pembunuh OOM dan membuat proses Anda dibuang.

Atau (dan lebih tepatnya), seperti yang disarankan beberapa komentar, beli lebih banyak RAM.

— Dmitry Grigoryev
sumber

0

Cerpen - coba versi kernel yang berbeda. Saya memiliki sistem yang menunjukkan kesalahan OOM dengan kernel 4.2.0-x dan 4.4.0-x, tetapi tidak dengan 3.19.0-x.

Ceritanya panjang: (tidak terlalu lama!) Saya punya Compaq DC5000 yang masih beroperasi di sini - saat ini dengan 512MB RAM (dan sebagian dari itu, seperti 32-128MB, diberikan ke video onboard ..) Sebagian besar melayani NFS, saya punya monitor yang terhubung sehingga kadang-kadang saya akan login (Ubuntu Classic, no Unity.)

Melalui Ubuntu HWE saya menjalankan kernel 3.19.x untuk sementara waktu; itu akan berakhir seperti 200-300MB barang, tapi ternyata itu barang yang tidak digunakan, tidak akan ada aktivitas swap dari itu harus menukar nanti sejauh yang saya tahu.

4.2.0-x kernel dan sekarang 4.4.0-x kernel, saya dapat memulai chunky NFS menulis untuk itu, hanya 220MB ke dalam swap (yaitu 1.3GB gratis), dan itu akan mulai membunuh hal-hal OOM. Saya tidak akan mengklaim apakah itu bug kernel atau "masalah tuning" (seperti cadangan 64MB yang biasanya baik-baik saja, tetapi terlalu tinggi pada sistem ~ 400MB atau lebih?)

Tidak ada rasa tidak hormat kepada mereka yang mengatakan itu entah bagaimana melanggar hanya karena ia mengharapkan untuk menggunakan swap; dengan segala hormat Anda salah. Ini tidak akan cepat, tetapi saya menggunakan 1 atau 2GB ke swap pada beberapa sistem 512MB-1GB. Tentu saja beberapa jenis perangkat lunak mlock banyak RAM tetapi dalam kasus saya (karena saya menjalankan perangkat lunak yang sama hanya pada kernel yang berbeda) ini jelas bukan itu masalahnya.

— pengguna367995
sumber