/ var / log / messages를 사용하여 메모리 부족 디버그

42

메시지 로그에 다음 보고서가 표시됩니다.

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

이 문제가있는 경우 문제가되지 않습니다 httpd, mysqld또는 postfix하지만 난 문제를 디버깅을 계속할 수 있는지 궁금합니다.

PID 9163이 종료 된 이유에 대한 자세한 정보를 어떻게 얻을 수 있으며 리눅스가 종료 된 PID의 히스토리를 어딘가에 보관하는지 확실하지 않습니다.

메시지 로그 파일에서이 문제가 발생하면이 문제를 단계별로 해결하는 방법은 무엇입니까?

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

— 이베 델 로브 스키
소스

문제에 대한 모든 메시지가 무엇에 표시 dmesg됩니까?

— Stark07

OOM-linux-mm.org/OOM_Killer 에 대한 유용한 정보 .

— slm

57

커널은 이런 일이 발생하기 전에 많은 것들을 기록 할 것이지만 /var/log/messages, (r)syslogd구성 방법에 따라 대부분은 없을 것입니다 . 시험:

grep oom /var/log/*
grep total_vm /var/log/*

전자는 여러 번 나타나고 후자는 한두 곳에서만 나타납니다. 보고 싶은 파일입니다.

포함 된 파일 중 하나에서 원래 "메모리 부족"줄을 찾으십시오 total_vm. 그 줄 이전에 30 초에서 1 분 (더 많을 수도 있고 적을 수도 있음)은 다음과 같습니다.

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

또한 해당 행과 "메모리 부족"행 사이에 다음과 같은 헤더가있는 표를 찾아야합니다.

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

이것은 당신이 이미 알고있는 것보다 훨씬 더 많은 것을 말하지는 않지만 필드는 다음과 같습니다.

pid 프로세스 ID.
uid 사용자 ID.
tgid 스레드 그룹 ID
total_vm 가상 메모리 사용 (4 kB 페이지)
rss 상주 메모리 사용 (4 kB 페이지)
nr_ptes 페이지 테이블 항목
스왑 런트 스왑 엔트리
oom_score_adj 보통 0; 숫자가 낮 으면 OOM 킬러가 호출 될 때 프로세스가 종료 될 가능성이 적음을 나타냅니다.

당신은 대부분 무시할 수 nr_ptes와 swapents내가 믿는 있지만이 사망 할 사용자를 결정하는 요인이다. 이것은 반드시 가장 많은 메모리를 사용하는 프로세스는 아니지만 가능성이 높습니다. 선택 과정에 대한 자세한 내용 은 여기를 참조하십시오 . 기본적으로 가장 높은 oom 점수로 끝나는 프로세스가 종료됩니다. "메모리 부족"줄에보고 된 "점수"입니다. 불행히도 다른 점수는보고되지 않지만 그 표는 요인에 대한 힌트를 제공합니다.

다시 말하지만, 이것은 아마도 훨씬 더 켜 집보다 분명하지 않을 것이다 : 시스템 메모리가 부족하고 mysqld죽을 선택이 끝난 한 을 죽이는 가장 리소스를 해제하기 때문 . 이것은 꼭 mysqld잘못된 것을 의미 하는 것은 아닙니다. 테이블을 보면 당시에 다른 항목이 없는지 확인할 수 있지만 명확한 원인은 없을 수 있습니다. 실행중인 프로세스를 잘못 판단하거나 잘못 구성하여 시스템에 메모리가 부족할 수 있습니다.

— 미역취 속의 일종
소스

5

dmesg이것이 보장되는 곳입니다. /var/logsyslog 데몬이 읽는 경우 에만 있습니다 /dev/kmsg(보통 그렇습니다).

— Patrick

2

@Patrick 보러 갈 때에 따라 다릅니다 . 정상적인 파일 로그 중 하나에 기록 된 경우 (또는 로거와 어리석은 짓을 한 경우) 오랜 시간 동안있을 것입니다.이 시점까지 OP가 발생한 문제를 진단하려는 경우 어제 또는 전날 등에 dmesg는 시스템이 계속 실행 되어도 더 이상 레코드가 없을 수 있습니다 .

— goldilocks

6

이것의 핵심은 메시지 자체- 메모리 부족입니다 . Linux 커널에 가상 메모리 (물리적 RAM + 스왑)가 고갈되면 프로세스 종료가 시작되고 바로 여기서 일어난 일입니다. mysqld2GB 이상의 가상 메모리를 사용하고있는 것 같습니다 .

시스템에 얼마나 많은 RAM과 스왑이 있습니까? 여분의 RAM을 추가하거나 가능하지 않은 경우 여분의 스왑을 추가하는 것이 좋습니다. 최소한 프로세스가 종료되는 것을 방지하기위한 빠른 수정으로 스왑 파일을 추가 할 수 있습니다.

업데이트 : 가지고있는 RAM의 양을 보면 즉시 문제를 볼 수 있습니다. ~ 1.6GB의 RAM과 100MB의 스왑이 있지만 MySQL은 그보다 훨씬 많은 RAM을 사용하고 있습니다. 프로세스가 종료되는 이유를 설명합니다.

— mjturner
소스

total       used       free     shared    buffers     cached Mem:          1655        934        721          0         10         52  -/+ buffers/cache:        871        784 Swap:          109          6        103

이것은 프로세스가 종료되었을 때의 메모리 출력입니다

— ibedelovski

서식을 유지 한 채 원본 메시지에 붙여 넣을 수 있습니까? 더 쉽게 읽을 수 있습니다.

— mjturner 2016 년

나는 형식을 잘하지 못하지만 이미 원래 메시지에 붙여 넣습니다

— ibedelovski