Linux oom-killer 디버깅 - 스왑 사용이 거의 없음

Linux oom-killer 디버깅 - 스왑 사용이 거의 없음

우리는 항상 실행되는 시스템을 구축했습니다. 이는 데이터 그래프를 수집하고 표시합니다. 오랜 시간 동안 아무런 변경 사항도 적용하지 않으면 결국 움킬러 이벤트가 발생하게 됩니다. 이렇게 하면 (oom 점수가 높은) 기본 프로세스가 종료되고 소프트웨어가 다시 시작됩니다.

기본 지식: 시스템은 CentOS 6이고 커널은 2.6.32.26입니다. 시스템에는 2G 메모리와 4G 스왑 공간이 있습니다. 애플리케이션은 Qt 3이 포함된 C++로 작성되었습니다.

매분마다 /proc/meminfo 및 /proc/slabinfo의 내용을 긁어 모으기 위해 cron 작업을 설정했습니다. 다음은 meminfo 데이터에서 발견한 가장 흥미로운 흔적입니다(최신 oom-killer는 차트 오른쪽에 있습니다). 메모리 정보

SUnreclaim은 oom-killer가 나타날 때까지 계속해서 증가합니다. SUnreclaim의 경사 변화는 디스플레이를 전환하는 위치입니다.

labinfo 데이터의 몇 가지 흥미로운 흔적은 다음과 같습니다. 보드 정보 크기

제가 보기엔 뭔가가 새거나 부서지는 것 같아요. 그것이 무엇이든 내 프로세스가 종료되면 정리되는 것처럼 보이지만 솔직히 여기서 무슨 일이 일어나고 있는지 전혀 모릅니다.

무엇이 누출되고 있는지 어떻게 알 수 있나요?

업데이트: 프로세스 초기에 ps 출력으로 시작했습니다(여기에는 표시되지 않음). 우리의 모든 프로세스에 대한 RSS 값은 "정상" 수준으로 빠르게 상승한 다음 동일하게 유지됩니다. 이것이 일반 메모리로 실행되는 프로세스라면 도움이 필요하지 않습니다. 대신, 우리는 스왑 불가능한 메모리가 할당되도록 하는 작업을 수행하고 있습니다.

업그레이드 조언에 따르면, 코드베이스는 이전 라이브러리에 대한 종속성이 너무 많아서 지금은 3 시리즈 커널로 전환할 수도 없습니다.

답변1

두 가지 질문을 하셨습니다.

1) OOM Killer가 실행 중이고 스왑이 없는 경우 이는 vm.swappiness 설정과 관련이 있을 수 있습니다. 1로 설정해 보세요. 오래되고 해킹 가능성이 높은 커널(shudder)에서 0으로 설정하면(제가 기억하는 대로) 스왑이 완전히 비활성화됩니다. 이는 아마도 원하는 것이 아닐 것입니다.

2) 누출을 식별하는 것은 증가하는 RSS 값이나 다른 지표를 찾기 위해 ps auxww를 반복적으로 실행하는 것만큼 간단할 수 있습니다.

이 모든 말은 ...

커널이 매우 오래되었습니다. PHP는 5.3으로 제한됩니다(해킹 가능성 높음). OpenSSL에 문제가 있습니다. 많은 관련 라이브러리가 매우 오래되어 메모리 누수의 원인이 될 수 있습니다.

최신 릴리스로 업그레이드하는 것이 가장 좋습니다. 간단한 업그레이드로 메모리 누수를 해결하는 최신 코드를 설치할 수 있습니다.

관련 정보