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

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

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

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디버깅 을 계속하려면 어떻게 해야 하는지 궁금합니다.mysqldpostfix

PID 9163이 종료된 이유에 대한 추가 정보를 어떻게 얻을 수 있으며 Linux가 종료된 PID에 대한 기록을 어딘가에 보관하는지 확실하지 않습니다.

메시지 로그 파일에 이런 문제가 발생하면 이 문제를 어떻게 단계별로 해결합니까?

# free -m

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

답변1

커널은 이 일이 발생하기 전에 많은 내용을 기록했을 것입니다. 그러나 구성 /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가상 메모리 사용(4kB 페이지 기준)
  • RSS상주 메모리 사용(4kB 페이지 단위)
  • nr_ptes페이지 테이블 항목
  • 교환항목 교환
  • oom_score_adj일반적으로 0; 숫자가 낮을수록 OOM 킬러가 호출될 때 프로세스가 종료될 가능성이 낮아집니다.

당신은 대부분 무시할 수 있지만 nr_ptes나는 swapents이것이 누가 살해되는지 결정하는 요소라고 믿습니다. 이는 반드시 가장 많은 메모리를 사용하는 프로세스는 아니지만 그럴 가능성이 매우 높습니다. 선발 과정에 대한 자세한 내용은여기를 보아라. 기본적으로 가장 높은 oom 점수로 끝나는 프로세스가 종료됩니다. 이는 "메모리 부족" 줄에 보고된 "점수"입니다. 불행히도 다른 점수는 보고되지 않지만 해당 표는 요인 측면에서 몇 가지 단서를 제공합니다.

다시 말하지만, 이는 명백한 사실을 밝히는 것 이상은 아닐 것입니다. 시스템에 메모리가 부족하여 mysqld죽도록 선택되었습니다.죽이면 가장 많은 자원이 방출되기 때문입니다.. 이것은 반드시 mysqld잘못된 일을 하고 있다는 뜻은 아닙니다 . 테이블을 보고 당시에 다른 문제가 발생했는지 확인할 수 있지만 명확한 원인은 없을 수 있습니다. 실행 중인 프로세스를 잘못 판단하거나 잘못 구성했기 때문에 시스템에 메모리가 부족할 수 있습니다.

답변2

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

시스템에 얼마나 많은 RAM과 스왑이 있습니까? 추가 RAM을 추가하거나, 가능하지 않은 경우 추가 스왑을 추가하는 것을 고려해 보겠습니다. 적어도 프로세스가 종료되는 것을 방지하기 위한 빠른 수정으로 스왑 파일을 추가할 수 있습니다.

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

관련 정보