Làm thế nào để có được kẻ giết người OOM Linux để không giết quá trình của tôi?


28

Làm cách nào để kẻ giết OOM Linux không giết các tiến trình của tôi khi bộ nhớ vật lý thấp nhưng có nhiều dung lượng trao đổi?

Tôi đã vô hiệu hóa OOM kill và overcommit với sysctl vm.overcommit_memory = 2.

VM có 3 GB trao đổi không phân mảnh hoàn toàn miễn phí và các quá trình đang bị OOM giết có mức sử dụng bộ nhớ tối đa dưới 200 MB.

Tôi biết rằng việc hoán đổi dài hạn sẽ rất tệ cho hiệu năng, nhưng tôi cần sử dụng trao đổi ngay bây giờ để thực hiện kiểm tra chức năng theo valgrind khi yêu cầu bộ nhớ lớn hơn nhiều.

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

Đây là / 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

8
Rõ ràng là rõ ràng từ dấu vết cuộc gọi rằng hạt nhân không có đủ bộ nhớ. Về lý do tại sao nó không trao đổi, điều đó có thể có nhiều nguyên nhân khác nhau, tất cả đều quá dài để giải thích đầy đủ trong 500 ký tự. Nhưng bạn có vẻ như không có trang nào có thể lấy lại được ( all_unreclaimablelà có). Đây là những trang bị khóa vào RAM, thường là do chúng được ghim hoặc sử dụng bởi kernel. Không có gì bạn còn lại trong RAM là có thể hoán đổi vào thời điểm đó; tất cả mọi thứ có thể đã được trao đổi đã được. Một lần nữa, giải pháp là RAM nhiều hơn.
Michael Hampton

1
@MichaelHampton Phần còn lại của bộ nhớ đang được sử dụng bởi các ứng dụng thông thường. Tại sao hạt nhân không thể đẩy chúng để trao đổi? Hãy trả lời câu hỏi của tôi "Nếu những gì bạn nói là đúng thì làm thế nào bất kỳ quá trình nào có thể rẽ nhánh sau khi tất cả bộ nhớ vật lý được sử dụng?"
Coder

1
@MichaelHampton Tôi vô hiệu hóa việc giả mạo và bây giờ fail2ban gọi kẻ giết người oom khiến quy trình của tôi bị giết. Điểm có trao đổi là gì nếu kernel không sử dụng nó? Quan trọng hơn, làm cách nào để cấu hình kernel để nó hết bộ nhớ.
Coder

4
@MatthewIfe: Nếu bạn biết câu trả lời, xin vui lòng gửi nó ở đây. Các trang web Stack Exchange là vì lợi ích của tất cả những người đọc, không chỉ OP đã đặt câu hỏi.
R ..

4
Trao đổi trong VM không được coi là Thực tiễn Tốt nhất. Phân bổ thêm bộ nhớ thực cho VM của bạn. Nếu bạn không thể thêm nhiều bộ nhớ hơn, hãy mang nó vào phần cứng vật lý thay vì để nó trong một khoản cho thuê quá nhỏ.
Criggie

Câu trả lời:


36

Đây có vẻ là vấn đề kết hợp của hai yếu tố:

  • Sử dụng máy ảo.
  • Một lỗi kernel có thể.

Đây là một phần của một trong những dòng mô tả lý do tại sao điều này xảy ra:

Ngày 7 tháng 3 02:43:11 hạt nhân myhost: memcheck-amd64- đã gọi oom-killer: gfp_mask = 0x24002c2, order = 0, oom_score_adj = 0

Dòng khác là đây:

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

| Dòng đầu tiên là mặt nạ GFP được chỉ định cho phân bổ. Về cơ bản, nó mô tả những gì kernel được phép / không được phép làm để bão hòa yêu cầu này. Mặt nạ cho thấy một loạt các cờ tiêu chuẩn. Tuy nhiên, bit cuối cùng, '2' chỉ ra việc cấp phát bộ nhớ sẽ đến từ HighMemvùng.

Nếu bạn nhìn kỹ vào đầu ra OOM, bạn sẽ thấy không có HighMem/Normalvùng nào thực sự tồn tại.

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(thường được gọi là Normaltrên x86_64) có xu hướng ánh xạ bộ nhớ cho các vùng bên ngoài phạm vi 896MiB tiêu chuẩn có thể truy cập trực tiếp kernel trên các hệ thống 32 bit. Trên x86_64 HighMem/Normaldường như bao gồm tất cả các trang có kích thước trên 3GiB.

DMA32chứa một vùng được sử dụng cho bộ nhớ có thể truy cập được trên các thiết bị DMA 32 bit, đó là bạn có thể xử lý chúng bằng các con trỏ 4 byte. Tôi tin DMAlà dành cho các thiết bị DMA 16 bit.

Nói chung, trên các hệ thống bộ nhớ thấp Normalsẽ không tồn tại, do đã DMA32bao gồm tất cả các địa chỉ ảo có sẵn.

Lý do bạn giết OOM là vì có phân bổ bộ nhớ cho một HighMemvùng có sẵn 0 trang. Do trình xử lý hết bộ nhớ hoàn toàn không có cách nào để thỏa mãn làm cho vùng này có các trang để sử dụng bằng cách hoán đổi, giết các tiến trình khác hoặc bất kỳ thủ thuật nào khác, OOM-killer chỉ giết chết nó.

Tôi tin rằng điều này là do máy chủ VM đang khởi động. Trên các hệ thống KVM, có hai giá trị bạn có thể đặt.

  • Bộ nhớ hiện tại.
  • Bộ nhớ có sẵn.

Cách thức hoạt động này là bạn có thể thêm bộ nhớ vào máy chủ của mình vào bộ nhớ khả dụng. Hệ thống của bạn tuy nhiên thực sự được cung cấp bộ nhớ hiện tại.

Khi máy ảo KVM khởi động, nó sẽ bắt đầu với việc phân bổ tối đa bộ nhớ có thể được cung cấp (bộ nhớ khả dụng). Dần dần trong giai đoạn khởi động của hệ thống, KVM vuốt lại bộ nhớ này bằng cách sử dụng bóng của nó, thay vào đó là cài đặt bộ nhớ hiện tại mà bạn có.

Tôi tin rằng đó là những gì đã xảy ra ở đây. Linode cho phép bạn mở rộng bộ nhớ, cung cấp cho bạn nhiều hơn khi khởi động hệ thống.

Điều này có nghĩa là có một Normal/HighMemkhu vực vào đầu đời của hệ thống. Khi máy ảo hóa bay nó đi, vùng bình thường sẽ biến mất khỏi trình quản lý bộ nhớ. Nhưng, tôi nghi ngờ rằng cài đặt cờ cho dù khu vực nói trên có sẵn để phân bổ không bị xóa khi cần. Điều này dẫn đến kernel cố gắng phân bổ từ một vùng không tồn tại.

Về mặt giải quyết điều này, bạn có hai lựa chọn.

  1. Đưa cái này lên danh sách gửi thư kernel để xem đây có thực sự là một lỗi không, hành vi dự kiến ​​hay không có gì để làm với những gì tôi đang nói.

  2. Yêu cầu linode đặt 'bộ nhớ khả dụng' trên hệ thống thành cùng một nhiệm vụ 1GiB như 'bộ nhớ hiện tại'. Do đó, hệ thống không bao giờ có bóng và không bao giờ có vùng Bình thường khi khởi động, giữ cho cờ rõ ràng. Chúc may mắn nhận được chúng để làm điều đó!

Bạn có thể kiểm tra xem đây có phải là trường hợp không bằng cách thiết lập VM của riêng bạn trong cài đặt KVM có sẵn cho 6GiB, hiện tại là 1GiB và chạy thử nghiệm của bạn bằng cùng một hạt nhân để xem hành vi này bạn thấy ở trên có xảy ra không. Nếu có, hãy thay đổi cài đặt 'khả dụng' bằng với dòng 1GiB và lặp lại thử nghiệm.

Tôi đang thực hiện một loạt các phỏng đoán có giáo dục ở đây và đọc phần giữa các dòng để đưa ra câu trả lời này, nhưng những gì tôi đang nói dường như phù hợp với các sự kiện đã nêu.

Tôi đề nghị kiểm tra giả thuyết của tôi và cho tất cả chúng ta biết kết quả.


4
Đó là một câu trả lời thấu đáo (và được giải thích rõ ràng)!
Olivier Dulac

2
Có, câu trả lời tuyệt vời ... Cách hữu ích hơn nhiều so với nhận xét của mọi người rằng "OP nên tin tưởng một cách mù quáng vào các thông điệp kernel" mà không cố gắng giải thích tại sao không gian hoán đổi có sẵn không được sử dụng.
Michael Martinez

31

Để trả lời câu hỏi tiêu đề của bạn, hãy sử dụng oom_score_adj(kernel> = 2.6.36) hoặc cho các hạt nhân trước đó (> = 2.6.11) oom_adj, xem man Proc

/ Proc / [pid] / oom_score_adj (kể từ Linux 2.6.36) Tập tin này có thể được sử dụng để điều chỉnh độ xấu heuristic được sử dụng để chọn quá trình bị giết trong điều kiện hết bộ nhớ ...

/ Proc / [pid] / oom_adj (kể từ Linux 2.6.11) Tập tin này có thể được sử dụng để điều chỉnh điểm số được sử dụng để chọn quá trình nào sẽ bị giết trong tình huống hết bộ nhớ (OOM) ...

Có nhiều thứ để đọc hơn nhưng đặt oom_score_adj thành -1000 hoặc oom_adj thành -17 sẽ đạt được những gì bạn muốn.

Rắc rối là một cái gì đó khác sẽ bị giết. Có lẽ sẽ tốt hơn nếu xác định lý do tại sao OOM được viện dẫn và giải quyết vấn đề đó.


4
+1 cho "giải quyết vấn đề cơ bản". Có thể là phần mềm vi phạm (hoặc một cái gì đó khác) vừa cố gắng để malloc một khối lớn của lõi? Đó là yêu cầu thêm bộ nhớ, sẽ đưa mọi thứ vào lãnh thổ báo động đỏ, có xu hướng kích hoạt kẻ giết người OOM.
MadHatter hỗ trợ Monica

11
@Coder: Các lập trình viên nhân Linux và nhân Linux rõ ràng biết nhiều hơn bạn. Quá trình của bạn đã bị giết bởi vì (bất chấp sự phản đối của bạn) không có đủ bộ nhớ. Nếu bạn nghĩ rằng điều này là không chính xác thì nộp báo cáo lỗi . Nếu bạn không lắng nghe những người hiểu biết rõ ràng phải nói gì thì có lẽ bạn nên trả tiền cho sự hỗ trợ của mình vì lời khuyên xứng đáng với những gì bạn trả cho nó. Lời khuyên sẽ không khác nhưng bạn sẽ trả tiền cho nó vì vậy sẽ coi trọng nó hơn.
user9517 hỗ trợ GoFundMonica

4
@Coder Tôi không có lập trình viên, thật đáng buồn. Chỉ có một trong hai khả năng: đó là kernel không biết sử dụng VM và lập trình viên đã mắc lỗi, tôi biết tiền nào của tôi.
MadHatter hỗ trợ Monica

1
@coder Tôi là 'ai đó'. Hãy cho tôi biết làm thế nào để liên lạc.
Matthew Ife

1
@MadHatter từ việc chạy 1000 hệ thống linux Tôi có thể nói với bạn: KHÔNG phải trường hợp nào người ta có thể cho rằng không có vấn đề gì trong việc quản lý bộ nhớ hoặc bất kỳ phần nào khác của kernel. Đây không giống như một nền tảng unix cao cấp và trong khi mọi thứ thường hoạt động tốt, thì không thể chấp nhận một trong hai bên theo bất kỳ cách giáo điều nào.
Florian Heigl

12

Một số suy nghĩ (từ ý kiến ​​của tôi ở trên) và các liên kết đến các bài đọc xen kẽ về tình huống của bạn:

  • Tôi khuyên bạn nên kiểm tra xem 1) bạn có thể nhập nhiều hơn 3Gb với kernel & config (& cpu) hiện tại của bạn [vì nếu 3Gb là giới hạn cho hệ thống & os của bạn, bạn sẽ vượt quá nó]. 2) rằng bạn cho phép hoán đổi và hệ thống con hoán đổi đang hoạt động. chúc may mắn (tôi sẽ không giải thích làm thế nào, vì nó phụ thuộc vào cài đặt và thông tin cụ thể của bạn. Công cụ tìm kiếm sẽ giúp đỡ). VÀ rằng bạn không tràn vào bảng kernel (nb của pids? Hoặc bất cứ thứ gì khác (một số có thể được đặt ở thời gian biên dịch kernel).

  • Kiểm tra xem toàn bộ (phần cứng hoặc phần cứng mô phỏng của vm, v.v.) là 64 bit. (xem ví dụ: https://askubfox.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit- Processor/313381 ). Hệ điều hành cpu & máy chủ lưu trữ & hệ điều hành vm & hệ điều hành vm đều phải được bật 64 bit, nếu không bạn sẽ không có vm 64 bit thực

  • Một số bài đọc tốt:

  • và cuối cùng: http://www.oracle.com/technetwork/articles/servers-st Storage-dev / oom-killer-1911807.html cho thấy một cách để ngăn chặn quá trình của bạn khỏi mục tiêu của kẻ giết người oom! ( echo -17 > /proc/PROCESSPID/oom_adj). Có thể dễ bị thay đổi và có thể là một điều tồi tệ (gây ra các loại lỗi khác vì hệ thống bây giờ không thể đơn giản là giết chết người vi phạm chính ...) Hãy thận trọng. @iain lưu ý rằng "oom_adj" dành cho các nhân cũ hơn và nên được thay thế bằng "oom_score_adj" trong các phần mới hơn. Cảm ơn, Iain)


1
oom_adj chỉ hợp lệ cho các nhân cũ hơn, những cái mới hơn sử dụng oom_score_adj.
user9517 hỗ trợ GoFundMonica

từ chối trách nhiệm: Tôi không thể cung cấp nhiều thông tin chi tiết hơn so với một số liên kết ở trên, vì hiện tại tôi không thể truy cập hệ thống linux ... và có rất nhiều điều cần kiểm tra. Có lẽ ai đó sẽ bước vào và cung cấp các quy trình từng bước tốt đẹp ... (câu trả lời của serverfault, cuối cùng của liên kết "đọc tốt" trong câu trả lời của tôi, giống như vậy, và là một cách đọc đáng kinh ngạc.)
Olivier Dulac

6

bên cạnh oom_score_adjsự gia tăng được đề cập cho quá trình đang được đề cập (có lẽ sẽ không giúp được gì nhiều - nó sẽ làm giảm khả năng quá trình đó sẽ bị giết ĐẦU TIÊN, nhưng đó chỉ là hệ thống xử lý chuyên sâu về bộ nhớ có thể sẽ không phục hồi cho đến khi cuối cùng bị giết), đây là một vài ý tưởng để điều chỉnh:

  • nếu bạn đặt vm.overcommit_memory=2, cũng điều chỉnh vm.overcommit_ratiothành có thể 90 (cách khác, đặt vm.overcommit_memory=0- xem tài liệu overcommit kernel )
  • tăng vm.min_free_kbytesđể luôn giữ một số RAM vật lý miễn phí và do đó giảm khả năng OOM cần phải giết một cái gì đó (nhưng đừng lạm dụng nó, vì nó sẽ OOM ngay lập tức).
  • tăng lên vm.swappiness100 (để trao đổi kernel dễ dàng hơn )

Lưu ý rằng nếu bạn có quá ít bộ nhớ để hoàn thành nhiệm vụ trong tay, ngay cả khi bạn không OOM, nó có thể (hoặc không) trở nên TUYỆT VỜI chậm - công việc nửa giờ (trên hệ thống có đủ RAM) có thể dễ dàng mất vài tuần ( khi RAM được thay thế bằng trao đổi) để hoàn thành trong các trường hợp cực đoan hoặc thậm chí treo toàn bộ VM. Đó là trường hợp đặc biệt nếu trao đổi nằm trên các đĩa quay cổ điển (trái ngược với SSD) do việc đọc / ghi ngẫu nhiên lớn rất tốn kém trên chúng.


3

Tôi sẽ cố gắng kích hoạt overcommit và xem nếu điều đó giúp. Quá trình của bạn dường như thất bại trong một forkcuộc gọi, đòi hỏi nhiều bộ nhớ ảo như quy trình ban đầu. overcommit_memory=2không làm cho quá trình của bạn miễn nhiễm với kẻ giết OOM, nó chỉ ngăn quá trình của bạn kích hoạt nó bằng cách phân bổ quá nhiều. Các quy trình khác có thể tạo ra các lỗi phân bổ không liên quan (ví dụ: có một khối bộ nhớ liền kề), điều này vẫn kích hoạt trình diệt OOM và xử lý quy trình của bạn.

Ngoài ra (và nhiều hơn nữa), như một số ý kiến ​​đề xuất, mua thêm RAM.


0

Truyện ngắn - thử một phiên bản kernel khác. Tôi có một hệ thống hiển thị lỗi OOM với các hạt nhân 4.2.0-x và 4.4.0-x, nhưng không phải với 3.19.0-x.

Câu chuyện dài: (không quá lâu!) Tôi đã có một Compaq DC5000 vẫn đang phục vụ ở đây - hiện có 512MB RAM (và một phần trong số đó, như 32-128 MB, được cung cấp cho video trên máy bay ..) NFS, tôi có một màn hình được nối với nó nên thỉnh thoảng tôi sẽ đăng nhập vào nó (Ubuntu Classic, không có Unity.)

Qua Ubuntu HWE tôi đã chạy kernel 3.19.x được một lúc; cuối cùng nó đã hoán đổi như 200-300 MB, nhưng rõ ràng đó là những thứ không được sử dụng, sẽ không có bất kỳ hoạt động hoán đổi nào từ nó phải trao đổi sau này theo như tôi có thể nói.

Hạt nhân 4.2.0-x và bây giờ là kernel 4.4.0-x, tôi có thể bắt đầu ghi NFS chunky vào nó, chỉ 220 MB vào trao đổi (tức là miễn phí 1,3 GB), và nó sẽ bắt đầu giết chết OOM. Tôi sẽ không yêu cầu nếu đó là lỗi kernel hoặc "vấn đề điều chỉnh" (như dự trữ 64 MB thường ổn, nhưng quá cao trên hệ thống ~ 400 MB hoặc hơn?)

Không tôn trọng những người đang nói rằng bằng cách nào đó phá vỡ chỉ vì anh ta mong đợi sử dụng trao đổi; với tất cả sự tôn trọng bạn đã sai. Sẽ không nhanh, nhưng tôi đã từng chuyển 1 hoặc 2GB vào trao đổi trên một vài hệ thống 512MB-1GB. Tất nhiên một số loại phần mềm có một loạt RAM nhưng trong trường hợp của tôi (vì tôi đang chạy cùng một phần mềm trên một hạt nhân khác) thì rõ ràng không phải vậy.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.