☰

커널 out_of_memory 오류의 원인은 무엇입니까?

tag-icon • tag-icon linux kernel memory-usage
커널 out_of_memory 오류의 원인은 무엇입니까?

나는 뛰고있어데비안 GNU/리눅스 5.0커널에서 간헐적으로 out_of_memory 오류가 발생합니다. 서버가 ping을 제외한 모든 응답에 응답하지 않으므로 서버를 재부팅해야 합니다.

# uname -a
Linux xxx 2.6.18-164.9.1.el5xen #1 SMP Tue Dec 15 21:31:37 EST 2009 x86_64
GNU/Linux

이것은 /var/log/messages의 중요한 부분인 것 같습니다.

Dec 28 20:16:25 slarti kernel: Call Trace:
Dec 28 20:16:25 slarti kernel: [<ffffffff802bedff>] out_of_memory+0x8b/0x203
Dec 28 20:16:25 slarti kernel: [<ffffffff8020f825>] __alloc_pages+0x245/0x2ce
Dec 28 20:16:25 slarti kernel: [<ffffffff8021377f>] __do_page_cache_readahead+0xc6/0x1ab
Dec 28 20:16:25 slarti kernel: [<ffffffff80214015>] filemap_nopage+0x14c/0x360
Dec 28 20:16:25 slarti kernel: [<ffffffff80208ebc>] __handle_mm_fault+0x443/0x1337
Dec 28 20:16:25 slarti kernel: [<ffffffff8026766a>] do_page_fault+0xf7b/0x12e0
Dec 28 20:16:25 slarti kernel: [<ffffffff8026ef17>] monotonic_clock+0x35/0x7b
Dec 28 20:16:25 slarti kernel: [<ffffffff80262da3>] thread_return+0x6c/0x113
Dec 28 20:16:25 slarti kernel: [<ffffffff8021afef>] remove_vma+0x4c/0x53
Dec 28 20:16:25 slarti kernel: [<ffffffff80264901>] _spin_lock_irqsave+0x9/0x14
Dec 28 20:16:25 slarti kernel: [<ffffffff8026082b>] error_exit+0x0/0x6e

전체 내용은 다음과 같습니다.http://pastebin.com/a7eWf7VZ

서버에 실제로 메모리가 부족하다고 생각했지만(실제 메모리는 1GB) Cacti 메모리 그래프는 괜찮아 보입니다...

친구가 여기서 나를 정정했습니다. 그는 보라색이 표시하기 때문에 그래프가 실제로 반전된다는 점에 주목했습니다.메모리 여유(제목에서 알 수 있듯이 메모리가 사용되지 않음)

메모리 사용량 그래프

그러나 이상하게도 로드 그래프는 커널이 충돌하기 직전에 지붕을 통과합니다.

평균 부하 그래프

자세한 내용은 어떤 로그를 확인하면 되나요?

업데이트:

주목할 만한 점은 충돌 당시 CPU 비율과 네트워크 트래픽 그래프가 모두 정상이었습니다. 유일한 이상은 평균 부하 그래프였습니다.

업데이트 2:

Passenger/Ruby를 배포했을 때 이런 일이 발생하기 시작한 것 같습니다. 이를 사용하면 topRuby가 대부분의 메모리와 상당한 양의 CPU를 사용하고 있는 것을 알 수 있습니다.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 5189 www-data  18   0  255m 124m 3388 S    0 12.1  12:46.59 ruby1.8            
14087 www-data  16   0  241m 117m 2328 S   21 11.4   3:41.04 ruby1.8            
15883 www-data  16   0  239m 115m 2328 S    0 11.3   1:35.61 ruby1.8

답변1

커널 메모리 부족 킬러에 대한 표시 OOM killed나 dmesg. 이를 통해 어떤 프로세스가 OOM 킬러의 대상이 되었는지 어느 정도 알 수 있습니다. 또한 다음 사항을 살펴보세요.

http://lwn.net/Articles/317814/

그리고

http://linux-mm.org/OOM_Killer

이 시스템의 기능은 무엇인가요? 동시에 스왑을 소모하고 있습니까? 충돌을 자세히 설명하는 외부 링크를 기반으로 하면 rsyslogd가 문제인 것 같습니다. 이는 앱을 주기적으로 다시 시작하는 것이 편리한 상황일 수 있습니다.

답변2

2.6.18은 아주 오래된 커널입니다. 특정 조건이 커널에서 무한 루프를 유발할 수 있는 문제에 부딪혔습니다. 이로 인해 메모리 고갈부터 I/O 대역폭까지 모든 것이 무한 루프에서 동일한 데이터를 디스크로 플러시하는 데 완전히 사용됩니다. 이로 인해 로드 스파이크가 발생하지만 CPU는 정상입니다. 사용.)

이러한 버그는 보고된 후 곧 수정되는 경향이 있으므로 커널 업그레이드는 이 문제를 쉽게 수정할 수 있습니다. 또한 커널을 업그레이드하면 무료로 일부 보안 수정 사항을 얻을 수 있습니다. :-)

답변3

또 다른 참고 사항으로 Cacti 및 이와 유사한 그래프가 특정 해상도(collectd는 기본적으로 5초, 선인장은 기본적으로 30초라고 생각함)에서 그래프가 표시되므로 화면에 반드시 표시되지 않는 30~60초의 기간이 있다는 점을 잊지 마세요. 그래프 ... 시스템이 완전히 정체되면 데이터 수집 데몬에도 영향을 미칩니다.

일반적인 /var/log/messages 또는 서비스별 /var/log/apache2/error.log 등의 로그 파일에서 추가로 유용한 정보를 찾을 수 있습니다.

그렇게 할 수 없다면 서비스를 살펴보고(위의 로그 추출에서 apache2를 발견했습니다) 서버에서 메모리 고갈 상황을 일으킬 수 있는지 확인하는 것이 좋습니다. (예: mod_prefork 및 php를 사용한 기본 아파치 구성은 시스템을 정지시킬 수 있어야 합니다).

관련 정보