cgroup 메모리 누수 문제 해결 기록

메모리 누수가 발생한 호스트는 클러스터 시스템으로 약 5일 동안 실행되었으며 메모리 사용량이 90%를 초과했습니다. 컨테이너를 중지합니다.

오랜 시간 실행한 후 클러스터 호스트의 메모리 사용량이 점차 증가하며 애플리케이션 OOM 현상이 발생합니다.

실제로 확인해보니 호스트의 전체 메모리 사용량이 높은 것으로 나타났으나, 실제 애플리케이션의 메모리 사용량이 낮거나 큰 이상은 발견되지 않았다.

메모리 사용량이 83.6%인 것을 볼 수 있는데, 상단에 표시되는 실제 메모리 사용량은 0.6%에 불과합니다. 메모리를 너무 많이 차지하는 애플리케이션은 없습니다.

사용자 애플리케이션 점유율 외에도 메모리 점유율에는 커널 점유율도 포함되므로 커널 메모리 점유율을 확인하세요.

Linux 파일 시스템 인터페이스를 사용하여 확인하세요.

점유율이 매우 높은 프로젝트가 슬래브 커널 점유율임을 알 수 있습니다.

계속해서 자세한 점유율을 확인하세요. 캐시 크기에 따라 정렬을 진행합니다:

kmalloc-2048, kmalloc-4096, kernfs_node_cache, kmalloc-1024, kmalloc-192, kmalloc -512가 모두 정상보다 높게 점유되었습니다. 호스트가 정상 값을 심각하게 초과했습니다.

커널 캐시가 너무 높으면 커널 캐시를 해제해 볼 수 있습니다.

그러나 위 작업을 수행한 후에도 메모리 사용량은 여전히 ​​크게 줄어들지 않습니다. 위에 표시된 SUnreclaim: 2447108과도 일치합니다. kB //slab 재활용 불가능한 메모리 크기입니다. 이 메모리는 해제될 수 없습니다.

kmalloc은 커널이 할당한 메모리인데 가장 중요한 참고자료는 kernfs_node_cache가 점유율이 높다는 점이라 이 항목의 기능을 검색해봤습니다.

분명히 이 현상은 커널 사용량이 기준을 심각하게 초과했기 때문에 발생하는 것이므로 검색 시 메모리 누수 키워드를 추가했고, centos7에서 docker-run --memory slab 캐시 누수 문제를 빠르게 발견했습니다

p>

이 문제는 docker run --rm --memory 1g hello-world를 반복적으로 실행할 때 centos7의 커널 메모리 사용량이 크게 증가하여 해제할 수 없음을 나타냅니다. 그리고 그 현상은 현재의 현상과 일치한다.

궁극적으로 이는 내부 커널 c 그룹 메모리 누수 문제를 가리킵니다: kmem 제어 그룹을 사용할 때 슬랩 누출로 인해 충돌이 발생합니다.

일반적인 이유는 kmem 제한 매개변수가 사용되는 경우입니다. 3.10 커널에서는 cgroup 할당된 메모리의 일부를 재활용 중에 해제할 수 없습니다. 더 깊은 이해를 위해서는 현재 문제를 먼저 해결하는 데 시간이 좀 걸릴 것입니다.

이 문제를 다시 판단하기 위해서는 위의 방법으로 해결이 가능하다면 문제라고 판단할 수 있습니다.

docker만 실행하는 머신에서 위의 명령문을 실행하여 slab 메모리 사용량을 확인해보면 메모리 사용량이 크게 늘어난 것을 확인할 수 있습니다. 그리고 최종 성능은 기존 환경의 문제와 일치하며, 총 메모리 사용량이 높고, 사용자 모드 메모리 사용량이 낮으며, 커널 메모리 사용량이 높아 출시할 수 없습니다.

커널 문제이고 명확한 재발 경로가 알려져 있기 때문에 두 가지 방법으로 해결할 수 있습니다.

결국 테스트 후 커널 버전을 변경하기로 결정했습니다. Ubuntu 18.04를 새 운영 체제로 사용합니다.

Linux 커널은 계층적 메모리 관리 방법을 사용합니다. 각 계층은 아래에서 위로 다른 문제를 해결합니다.

Slab은 메모리 할당의 일종입니다. 리눅스 운영 체제. 해당 작업은 프로세스 설명자와 같이 자주 할당 및 해제되는 일부 개체를 대상으로 하는 것입니다. 이러한 개체의 크기는 일반적으로 상대적으로 작습니다. 파트너 시스템을 직접 사용하여 할당 및 해제하면 많은 내부 문제가 발생합니다. 조각화되지만 처리 속도도 너무 느려집니다. slab 할당자는 동일한 유형의 개체를 하나의 범주(예: 프로세스 설명자)로 분류합니다. 이러한 개체가 적용될 때마다 slab 할당자는 해당 단위의 개체를 할당합니다. 나가서 해제할 시간이 되면 파트너 시스템으로 직접 반환되는 대신 해당 목록에 다시 저장되므로 이러한 내부 조각화를 방지할 수 있습니다. 슬랩 할당자는 할당된 객체를 버리지 않고 메모리에 해제하고 저장합니다. 나중에 새로운 객체가 요청되면 반복적인 초기화 없이 메모리에서 직접 가져올 수 있습니다.

Slab이 차지하는 메모리가 너무 높으면 Slab은 재활용 가능한 캐시를 수동으로 해제할 수 있습니다. 작업은 다음과 같습니다.

drop_caches의 네 가지 값은 다음과 같습니다. 의미: