Linux OOM 킬러가 프로세스를 종료하지 못하게하는 방법은 무엇입니까?

물리적 메모리는 적지 ​​만 스왑 공간이 충분할 때 Linux OOM 킬러가 프로세스를 종료하지 않도록하려면 어떻게해야합니까?

OOM killing을 비활성화하고 sysctl vm.overcommit_memory = 2로 오버 커밋했습니다.

VM에는 3GB의 완전 무료 조각화되지 않은 스왑이 있으며 OOM 강제 종료중인 프로세스의 최대 메모리 사용량은 200MB 미만입니다.

장기 스와핑이 성능면에서 끔찍하다는 것을 알고 있지만 메모리 요구 사항이 훨씬 큰 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

이것은 두 가지 요소의 조합으로 문제가있는 것으로 보입니다.

• 가상 머신 사용
• 가능한 커널 버그.

이것은 왜 이런 일이 발생하는지 설명하는 줄 중 하나입니다.

3 월 7 일 02:43:11 myhost 커널 : memcheck-amd64 호출 oom-killer : gfp_mask = 0x24002c2, order = 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에서 호출 ) 32 비트 시스템에서 직접 커널 액세스 할 수있는 표준 896MiB 범위를 벗어난 영역에 대한 메모리를 매핑하는 경향이 있습니다. x86_64 HighMem/Normal에서는 크기가 3GiB 이상인 모든 페이지를 커버하는 것 같습니다.

DMA3232 비트 DMA 장치에서 액세스 할 수있는 메모리에 사용되는 영역이 포함되어 있습니다. 즉, 4 바이트 포인터로 주소를 지정할 수 있습니다. 나는 DMA16 비트 DMA 장치에 대한 것이라고 생각 합니다.

일반적으로, 사용 가능한 모든 가상 주소를 이미 포함하고 Normal있다면 메모리가 부족한 시스템 에는 존재하지 않습니다 DMA32.

OOM kill 이유는 HighMem0 페이지를 사용할 수 있는 영역에 대한 메모리 할당이 있기 때문입니다 . 메모리 부족 처리기가이 영역에 스왑, 다른 프로세스 또는 기타 트릭을 사용하여 사용할 페이지를 갖도록하는 방법을 절대적으로 제공 할 수없는 경우 OOM-killer는이를 종료합니다.

부팅시 호스트 VM 풍선으로 인해 발생한다고 생각합니다. KVM 시스템에는 두 가지 값을 설정할 수 있습니다.

• 현재 메모리
• 사용 가능한 메모리

이것이 작동하는 방식은 사용 가능한 메모리까지 서버에 메모리를 핫 추가 할 수 있다는 것입니다. 그러나 시스템에는 실제로 현재 메모리가 제공됩니다.

KVM VM이 부팅되면 가능한 최대 메모리 할당량 (사용 가능한 메모리)으로 시작합니다. 점차적으로 시스템의 부팅 단계에서 KVM은 풍선을 사용하여이 메모리를 클로킹하여 현재의 메모리 설정을 그대로 유지합니다.

내 생각은 여기에서 일어난 일입니다. Linode를 사용하면 메모리를 확장하여 시스템을 시작할 때 훨씬 더 많은 것을 제공 할 수 있습니다.

이는 Normal/HighMem시스템 수명이 시작될 때 영역 이 있음을 의미합니다 . 하이퍼 바이저가 풍선을 치우면 메모리 관리자에서 일반 영역이 사라집니다. 그러나, 나는이 영역이되어에서 할당 할 수 있습니다 말했다 여부 플래그가 설정 의심 하지 때해야 클리어. 이로 인해 커널은 존재하지 않는 영역에서 할당을 시도합니다.

이 문제를 해결하는 데는 두 가지 옵션이 있습니다.

1. 이것을 커널 메일 링리스트에 가져와 이것이 실제로 버그인지, 예상되는 행동인지 또는 내가 말하는 것과 전혀 관련이 없는지 확인하십시오.

2. linode가 시스템의 '사용 가능한 메모리'를 '현재 메모리'와 동일한 1GiB 할당으로 설정하도록 요청하십시오. 따라서 시스템은 부팅 할 때 절대 팽창하지 않으며 정상 영역을 얻지 않으므로 플래그를 명확하게 유지합니다. 행운을 빕니다.

6GiB, 현재 1GiB에 사용 가능한 KVM 설정에서 고유 한 VM을 설정하고 동일한 커널을 사용하여 테스트를 실행하여 위에서 본 이러한 동작이 발생하는지 확인하여 이러한 경우인지 테스트 할 수 있습니다. 그렇다면 '사용 가능'설정을 1GiB 전류와 동일하게 변경하고 테스트를 반복하십시오.

나는 여기에 많은 교육 된 추측을 하고이 답변 사이에 약간의 내용을 읽었지만, 내가 말하는 것은 이미 요약 된 사실에 맞는 것 같습니다.

내 가설을 테스트하고 결과를 모두 알려주십시오.

헤드 라인 질문에 대답하려면 oom_score_adj(kernel> = 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이 호출되는 이유를 파악하고 처리하는 것이 좋습니다.

몇 가지 생각 (위의 의견에서)과 interresting에 대한 링크는 귀하의 상황에 대해 읽습니다.

• 1) 현재 커널 및 구성 (& cpu)으로 3Gb 이상을 처리 할 수 ​​있는지 확인하는 것이 좋습니다 (3Gb가 시스템 및 OS에 대한 제한 인 경우 초과하고 있음). 2) 스와핑을 허용하고 스와핑 서브 시스템이 있고 작동 중입니다. 행운을 빕니다 (귀하의 설정 및 사양에 따라 방법이 설명되지 않습니다. 검색 엔진이 도움이 될 것입니다). 그리고 커널 테이블을 넘치지 않아야합니다 (pid의 nb? 또는 다른 것 (일부는 커널 컴파일 타임에 설정 될 수 있음)).

• 모든 것 (하드웨어 또는 vm의 시뮬레이션 된 하드웨어 등)이 64 비트인지 확인하십시오. (예 : https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 참조 ). CPU 및 호스트 OS 및 vm 하위 시스템 및 vm OS는 모두 64 비트를 지원해야합니다. 그렇지 않으면 실제 64 비트 vm이 없습니다.

• 좋은 읽을 거리들 :

  • oom-killer killing 프로세스의 원인을 진단하는 방법 : 바로이 사이트에서. 멋진 링크 ( 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/ : "OOM 킬러 이름 지정"은 무엇보다도 "비가 시적인"그룹을 만들고 프로세스를 넣는 방법을 보여줍니다.
  • 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 : 실제로 무슨 일이 있었는지 알 수있는 자세한 방법을 제공하는 훌륭한 답변입니다 (그러나 ... 32 비트 질문을 대상으로하므로 ymmv. 여전히 놀라운 읽기 및 답변).

• 그리고 마지막으로 : http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html 은 프로세스가 oom killer에 의해 대상이되는 것을 방지하는 방법을 보여줍니다! ( echo -17 > /proc/PROCESSPID/oom_adj) 변경이 발생하기 쉬울 수 있으며 나쁜 일이 될 수 있습니다 (이제 시스템이 주요 범죄자를 단순히 죽일 수 없기 때문에 다른 종류의 장애가 발생하기 때문에 ...)주의해서 사용하십시오. @iain은 "oom_adj"는 이전 커널 용이며 최신 커널에서는 "oom_score_adj"로 대체해야합니다. 감사합니다, Iain)

언급 된 oom_score_adj프로세스에 대한 언급 외에도 (많이 도움이되지는 않을 것입니다-아마도 프로세스가 먼저 종료 될 가능성은 줄어들지 만, 메모리를 많이 사용하는 프로세스 시스템이므로 최종적으로 복구 될 때까지 아마 복구되지 않을 것입니다 살해), 여기에 약간의 아이디어를 수정하십시오 :

• 설정하면 90으로 vm.overcommit_memory=2조정 vm.overcommit_ratio(또는 커널 오버 커밋 문서vm.overcommit_memory=0 참조 )
• vm.min_free_kbytes항상 실제 RAM을 확보하기 위해 증가시켜 OOM이 무언가를 죽일 필요가있는 기회를 줄입니다 (그러나 즉시 OOM이되기 때문에 그것을 과도하게 사용하지 마십시오).
• 증가 vm.swappiness(메이크업의 100에 더 쉽게 커널 스왑 )

당신은 OOM을하지 않는 경우에도 손에서 작업을 수행하는 데 너무 적은 메모리가 있다면, 그것은 참고 할 수있다 (또는하지 않을 수 있습니다) 극단적으로 느려질 - (충분한 RAM을 가진 시스템) 반 시간 작업이 쉽게 (몇 주 걸릴 수 있습니다 극단적 인 경우에 완료하거나 전체 VM을 정지시키기 위해 RAM이 스왑으로 교체 될 때). 스왑이 대량의 무작위 읽기 / 쓰기로 인해 SSD와 달리 고전적인 회전 디스크에있는 경우 특히 그렇습니다.

오버 커밋을 활성화하고 도움이되는지 확인하려고합니다. fork호출 내에서 프로세스가 실패한 것으로 보이며 초기 프로세스보다 많은 가상 메모리가 필요합니다. overcommit_memory=2프로세스가 OOM 킬러에 영향을주지는 않지만 프로세스를 너무 많이 할당하여 프로세스를 트리거하지 못하게합니다. 다른 프로세스는 관련 할당 오류 (예 : 연속 메모리 블록 확보)를 생성하여 여전히 OOM 킬러를 트리거하고 프로세스를 폐기 할 수 있습니다.

또는 여러 의견에서 알 수 있듯이 RAM을 더 구입하십시오.

짧은 이야기-다른 커널 버전을 사용해보십시오. 4.2.0-x 및 4.4.0-x 커널에서는 OOM 오류가 표시되었지만 3.19.0-x에서는 그렇지 않은 시스템이 있습니다.

긴 이야기 : (너무 오래 걸리지 않습니다!) 현재 Compaq DC5000을 여기에서 서비스하고 있습니다. 현재 512MB의 RAM (및 32-128MB와 같은 일부가 온보드 비디오에 제공됩니다.) NFS, 모니터가 연결되어 있으므로 가끔 로그인합니다 (Ubuntu Classic, Unity 없음).

우분투 HWE를 통해 나는 잠시 동안 3.19.x 커널을 실행하고 있었다. 그것은 200-300MB의 물건처럼 스왑 아웃되지만 결국 사용되지 않은 물건이었습니다. 나중에 말할 수있는 한 스왑 활동으로 인해 스왑 활동이 없을 것입니다.

4.2.0-x 커널과 4.4.0-x 커널에서 스왑으로 220MB 만 (즉, 1.3GB 사용 가능) chunky NFS 쓰기를 시작할 수 있으며 OOM killing 일을 시작합니다. 커널 버그인지 또는 "튜닝 문제"인지는 주장하지 않을 것입니다 (64MB는 보통은 괜찮지 만 ~ 400MB 정도의 시스템에서는 너무 높음).

그가 스왑을 사용하기를 기대한다고해서 어떻게 든 깨지고 있다고 말하는 사람들에게는 무례하지 않습니다. 모든면에서 당신은 틀 렸습니다. 빠르지는 않지만 512MB-1GB 시스템에서 1GB 또는 2GB를 스왑에 사용했습니다. 물론 일부 유형의 소프트웨어는 많은 양의 RAM이지만 많은 경우 (다른 커널에서 동일한 소프트웨어를 실행하기 때문에) 이것은 사실이 아닙니다.