프로세스가 중단 된 이유와 이유는 무엇입니까?

내 응용 프로그램은 Linux에서 백그라운드 프로세스로 실행됩니다. 현재 터미널 창의 명령 행에서 시작됩니다.

최근에 사용자가 잠시 동안 응용 프로그램을 실행하고 있었고 신비롭게 죽었습니다. 텍스트 :

살해

터미널에 있었다. 이것은 두 번 일어났다. 다른 터미널의 누군가가 kill 명령을 사용하여 프로세스를 종료하는지 물었습니다. 아니.

Linux는 어떤 조건에서 프로세스를 종료하기로 결정합니까? kill (9) 신호를받은 후 프로세스가 종료 되었기 때문에 쉘에 "killed"가 표시되었다고 생각합니다. 리눅스가 강제 종료 신호를 보냈다면 시스템 로그에 왜 종료되었는지 설명하는 메시지가 있어야합니까?

사용자 또는 sysadmin이 프로그램을 종료하지 않은 경우 커널에있을 수 있습니다. 커널은 극단적 인 리소스 부족과 같은 예외적 인 상황에서만 프로세스를 종료합니다 (mem + swap 소진 생각).

시험:

dmesg -T| grep -E -i -B100 'killed process'

여기서 -B100kill이 발생하기 전에 줄 수를 나타냅니다.

Mac OS에서 -T 를 생략하십시오 .

이것은 주제에 대한 좋은 기사처럼 보입니다 : OOM 킬러 길들이기 .

요점은 리눅스 초과 커밋기억. 프로세스가 더 많은 공간을 요구할 때, 리눅스는 다른 프로세스에 의해 요구되는 경우에도 아무도 요청한 모든 메모리를 실제로 사용하지 않는다는 가정하에 해당 공간을 제공합니다. 프로세스는 요청할 때가 아니라 실제로 사용할 때 할당 한 메모리를 독점적으로 사용합니다. 이렇게하면 할당이 빨라지고 실제보다 더 많은 메모리를 "속임수"할당 할 수 있습니다. 그러나 일단 프로세스가이 메모리를 사용하기 시작하면, Linux는 자신이 가지고 있지 않은 메모리를 할당하는 데 너무 관대하다는 것을 인식 할 수 있으며 일부를 해제하려면 프로세스를 종료해야합니다. 종료되는 프로세스는 런타임 (장기 실행 프로세스가 더 안전함), 메모리 사용량 (욕심없는 프로세스가 덜 안전함) 및 기타 몇 가지 요소를 고려한 점수를 기반으로합니다. 프로세스가 종료 될 가능성을 줄이기 위해 조정할 수있는 값을 포함합니다. 이 기사에서 모두 자세히 설명합니다.

편집 : 여기 에 프로세스가 어떻게 선택되는지 잘 설명하는 또 다른 기사 가 있습니다 (커널 코드 예제로 주석이 달린). 이것에 대한 좋은 점은 다양한 규칙 뒤에있는 추론 에 대한 주석이 포함되어 있다는 것 badness()입니다.

OOMKiller가 언제 그리고 왜 호출되는지 설명하겠습니다.

512 RAM + 1GB 스왑 메모리가 있다고 가정하십시오. 이론적으로 CPU는 총 1.5GB의 가상 메모리에 액세스 할 수 있습니다.

이제는 전체 메모리의 1.5GB 내에서 모든 것이 제대로 실행되고 있습니다. 그러나 갑자기 (또는 점진적으로) 시스템이 점점 더 많은 메모리를 사용하기 시작했으며 사용 된 총 메모리의 약 95 %에 도달했습니다.

이제 모든 프로세스가 커널에서 많은 양의 메모리를 요청했다고 가정하십시오. 커널은 사용 가능한 메모리를 확인하고 프로세스에 더 많은 메모리를 할당 할 수있는 방법이 없음을 찾으십시오. 따라서 OOMKiller ( http://linux-mm.org/OOM ) 를 호출하거나 호출하는 메모리를 확보하려고 시도합니다 .

OOMKiller에는 모든 프로세스의 순위를 매기는 자체 알고리즘이 있습니다. 일반적으로 어떤 프로세스가 더 많은 메모리를 사용하는지는 살해 대상이됩니다.

OOMKiller 로그는 어디서 찾을 수 있습니까?

일반적으로 / var / log 디렉토리에 있습니다. /var/log/kern.log 또는 / var / log / dmesg

이것이 도움이되기를 바랍니다.

몇 가지 일반적인 솔루션 :

1. 메모리 증가 (스왑 아님)
2. 프로그램에서 메모리 누수를 찾아서 수정하십시오.
3. 모든 프로세스가 소비 할 수있는 메모리 제한 (예 : JAVA_OPTS를 사용하여 JVM 메모리를 제한 할 수 있음)
4. 로그와 구글을 참조하십시오 :)

Linux 메모리 부족 관리자 (OOM) 입니다. 프로세스는 ' 나쁨 '-최근 성, 거주자 크기 (할당 된 메모리가 아니라 사용중인 메모리) 및 기타 요인의 조합으로 선택되었습니다.

sudo journalctl -xb

다음과 같은 메시지가 나타납니다.

Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                    active_file:722 inactive_file:4126 isolated_file:0
                                    unevictable:0 dirty:5 writeback:0 unstable:0
                                    free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                    mapped:792 shmem:12802 pagetables:1651 bounce:0
                                    free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB

dwc와 Adam Jaskiewicz가 말했듯이 범인은 아마도 OOM Killer 일 것입니다. 그러나 다음에 나오는 질문은이 문제를 어떻게 방지합니까?

몇 가지 방법이 있습니다.

1. 가능한 경우 시스템에 더 많은 RAM을 제공하십시오 (VM의 경우에는 쉬움).
2. OOM 킬러가 다른 프로세스를 선택해야합니다.
3. OOM Killer 비활성화
4. OOM Killer가 비활성화 된 상태로 제공되는 Linux 배포판을 선택하십시오.

이 기사 덕분에 (2) 구현하기가 특히 쉽다는 것을 알았습니다 .

리소스를 제한 하는 PAM 모듈은 사용자가 설명한 결과와 정확히 일치합니다 . 콘솔 창에서 Killed 텍스트로 프로세스가 신비하게 죽었습니다 . syslog 또는 kern.log 에 로그 출력이 없습니다 . 최고 프로그램은 CPU 사용량을 정확히 후 1 분이 내 프로세스가 살해됩니다 것을 발견 나를 도왔다.

systemtap (또는 추적 프로그램)과 같은 도구는 커널 신호 전송 논리를 모니터링하고보고 할 수 있습니다. 예 : https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap .../sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

if해당 스크립트 의 필터링 블록을 조정하여 시스템 전체 신호 트래픽을 추적하도록 제거 할 수 있습니다. 역 추적을 수집하여 원인을 추가로 격리 할 수 ​​있습니다 ( 커널 및 사용자 공간에 대해 각각 a print_backtrace()및 / 또는 print_ubacktrace()프로브에 추가 ).

lsf 환경 (대화식 또는 기타)에서 애플리케이션이 큐 관리자 또는 큐에 제출할 자원 요청에 의해 사전 설정된 임계 값을 초과하는 메모리 사용률을 초과하면 프로세스가 종료되어 다른 사용자가 잠재적으로 피해를 입지 않습니다. 도망 치다 설정 방법에 따라 이메일을 보낼 때 항상 이메일을 보내지는 않습니다.

이 경우 한 가지 해결책은 제출시 더 많은 자원이있는 큐를 찾거나 더 큰 자원 요구 사항을 정의하는 것입니다.

검토하고 싶을 수도 있습니다 man ulimit

나는 그것을 필요로 한 이후 ulimit로 Killed그 결과를 가져온 것을 기억하지 못하지만 .

우리는 리눅스에서 고객 사이트 (Red Hat, 제 생각에는)에서 반복적 인 문제를 겪었습니다. OOMKiller (메모리 부족 킬러)는 우리의 주요 응용 프로그램 (즉, 서버가 존재하는 이유)과 데이터베이스 프로세스를 모두 죽였습니다.

각각의 경우에 OOMKiller는 단순히 프로세스가 많은 리소스를 사용하고 있다고 결정했습니다. 리소스 부족으로 인해 시스템이 실패하지는 않았습니다. 응용 프로그램이나 데이터베이스 모두 메모리 누수 (또는 다른 리소스 누수)에 문제가 없습니다.

나는 리눅스 전문가가 아니지만 무언가를 죽일 때와 죽일 것이 무엇인지를 결정하기위한 알고리즘이라는 것을 모았습니다. 또한, 나는 OOMKiller가 커널에 구워졌으며 단순히 실행할 수 없다는 말을 들었습니다 (이 정확도에 대해서는 말할 수 없습니다).

필자의 경우 이것은 Laravel 큐 작업자와 함께 발생했습니다. 시스템 로그에는 어떤 킬링도 언급되지 않았으므로 더 자세히 보았고 메모리 제한을 초과하는 작업 (기본적으로 128M으로 설정 됨) 때문에 작업자가 기본적으로 자신을 죽이는 것으로 나타났습니다.

와 큐 노동자를 실행 --timeout=600하고 --memory=1024나를 위해 문제를 해결.

사용자는 kill 또는 Control + C를 사용하여 자신의 프로그램을 죽일 수는 있지만 발생하지 않은 인상을 받았으며 사용자가 귀하에게 불만을 표시했습니다.

root는 물론 프로그램을 죽일 수 있지만 누군가가 컴퓨터에 뿌리를두고 물건을 죽이는 경우 더 큰 문제가 있습니다.

sysadmin이 아닌 경우 sysadmin이 CPU, RAM, ort 디스크 사용량 및 할당량을 초과하는 자동 종료 프로세스에 할당량을 설정했을 수 있습니다.

그 추측 외에도 프로그램에 대한 자세한 정보가 없으면 확실하지 않습니다.

최근 에이 문제가 발생했습니다. 마지막으로 Opensuse zypper 업데이트가 자동으로 호출 된 직후 프로세스가 종료되었음을 알았습니다. zypper 업데이트를 비활성화하면 문제가 해결되었습니다.

스왑 크기를 늘려이 문제를 해결했습니다 .

/ubuntu/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04