내 프로세스를 죽인 이유는 무엇입니까?
내 응용 프로그램은 Linux에서 백그라운드 프로세스로 실행됩니다. 현재 터미널 창의 명령 줄에서 시작됩니다.
최근 한 사용자가 한동안 애플리케이션을 실행하다가 이상하게 죽었습니다. 텍스트 :
살해
터미널에 있었다. 이것은 두 번 일어났습니다. 다른 터미널의 누군가가 프로세스를 종료하기 위해 kill 명령을 사용했는지 물었습니다. 아니.
어떤 조건에서 Linux가 내 프로세스를 종료하기로 결정합니까? 프로세스가 kill (9) 신호를받은 후 죽었 기 때문에 쉘이 "killed"로 표시되었다고 생각합니다. Linux가 kill 신호를 보낸 경우 시스템 로그 어딘가에 그것이 왜 죽었는지 설명하는 메시지가 있어야합니까?
사용자 나 sysadmin이 프로그램을 죽이지 않았다면 커널에있을 수 있습니다. 커널은 극심한 리소스 고갈 (mem + swap 소모를 생각)과 같은 예외적 인 상황에서만 프로세스를 종료합니다.
시험:
dmesg -T| grep -E -i -B100 'killed process'
어디 -B100킬 (kill)이 발생하기 전에 라인의 수를 의미한다.
Mac OS에서는 -T 를 생략하십시오 .
이 주제에 대한 좋은 기사 인 Taming the OOM killer .
요점은 리눅스입니다 overcommit을기억. 프로세스가 더 많은 공간을 요구할 때, Linux는 다른 프로세스가 요구하더라도 실제로 요청한 모든 메모리를 사용하지 않는다는 가정하에 해당 공간을 제공합니다. 프로세스는 요청할 때가 아니라 실제로 사용할 때 할당 된 메모리를 독점적으로 사용합니다. 이렇게하면 할당이 빨라지고 실제 보유한 것보다 더 많은 메모리를 "속임수"하고 할당 할 수 있습니다. 그러나 일단 프로세스가이 메모리를 사용하기 시작하면 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
이것이 당신을 도울 것입니다.
몇 가지 일반적인 솔루션 :
- 메모리 늘리기 (스왑 아님)
- 프로그램에서 메모리 누수를 찾아 수정하십시오.
- 모든 프로세스가 사용할 수있는 메모리 제한 (예 : JAVA_OPTS를 사용하여 JVM 메모리를 제한 할 수 있음)
- 로그 및 Google 참조 :)
이것은 Linux OOM (Out of Memory Manager) 입니다. 최근 성, 상주 크기 (단순히 할당 된 것이 아니라 사용중인 메모리) 및 기타 요인의 조합 인 ' 불량 ' 으로 인해 프로세스가 선택되었습니다 .
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 일 가능성이 높습니다. 그러나 다음 질문은 다음과 같습니다. 어떻게 방지합니까?
여러 가지 방법이 있습니다.
- 가능하면 시스템에 더 많은 RAM을 제공하십시오 (VM 인 경우 쉬움).
- OOM 킬러가 다른 프로세스를 선택하는지 확인하십시오.
- OOM Killer 비활성화
- OOM Killer가 비활성화 된 상태로 제공되는 Linux 배포판을 선택하십시오.
이 기사 덕분에 (2) 구현하기가 특히 쉽다는 것을 알았습니다 .
The PAM module to limit resources caused exactly the results you described: My process died mysteriously with the text Killed on the console window. No log output, neither in syslog nor in kern.log. The top program helped me to discover that exactly after one minute of CPU usage my process gets killed.
A tool like systemtap (or a tracer) can monitor kernel signal-transmission logic and report. e.g., 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
The filtering if block in that script can be adjusted to taste, or eliminated to trace systemwide signal traffic. Causes can be further isolated by collecting backtraces (add a print_backtrace() and/or print_ubacktrace() to the probe, for kernel- and userspace- respectively).
In an lsf environment (interactive or otherwise) if the application exceeds memory utilization beyond some preset threshold by the admins on the queue or the resource request in submit to the queue the processes will be killed so other users don't fall victim to a potential run away. It doesn't always send an email when it does so, depending on how its set up.
One solution in this case is to find a queue with larger resources or define larger resource requirements in the submission.
You may also want to review man ulimit
Although I don't remember ulimit resulting in Killed its been a while since I needed that.
We have had recurring problems under Linux at a customer site (Red Hat, I think), with OOMKiller (out-of-memory killer) killing both our principle application (i.e. the reason the server exists) and it's data base processes.
In each case OOMKiller simply decided that the processes were using to much resources... the machine wasn't even about to fail for lack of resources. Neither the application nor it's database has problems with memory leaks (or any other resource leak).
I am not a Linux expert, but I rather gathered it's algorithm for deciding when to kill something and what to kill is complex. Also, I was told (I can't speak as to the accuracy of this) that OOMKiller is baked into the Kernel and you can't simply not run it.
In my case this was happening with a Laravel queue worker. The system logs did not mention any killing so I looked further and it turned out that the worker was basically killing itself because of a job that exceeded the memory limit (which is set to 128M by default).
Running the queue worker with --timeout=600 and --memory=1024 fixed the problem for me.
The user has the ability to kill his own programs, using kill or Control+C, but I get the impression that's not what happened, and that the user complained to you.
root has the ability to kill programs of course, but if someone has root on your machine and is killing stuff you have bigger problems.
If you are not the sysadmin, the sysadmin may have set up quotas on CPU, RAM, ort disk usage and auto-kills processes that exceed them.
Other than those guesses, I'm not sure without more info about the program.
I encountered this problem lately. Finally, I found my processes were killed just after Opensuse zypper update was called automatically. To disable zypper update solved my problem.
Solved this issue by increasing swap size:
https://askubuntu.com/questions/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04
참고URL : https://stackoverflow.com/questions/726690/what-killed-my-process-and-why
'your programing' 카테고리의 다른 글
| Java에서 정적 메서드가 추상이 될 수없는 이유 (0) | 2020.10.03 |
|---|---|
| Entity Framework에서 생성 된 SQL을 보려면 어떻게합니까? (0) | 2020.10.03 |
| 메모장 ++에서 자동 서식 / 들여 쓰기 XML / HTML 방법 (0) | 2020.10.03 |
| 값 목록을 사용하여 pandas 데이터 프레임에서 행 선택 (0) | 2020.10.03 |
| C ++에서 ifstream을 사용하여 한 줄씩 파일 읽기 (0) | 2020.10.03 |