OOM, 또는 massif/valgrind에 표시 될 때 충돌이 발생하지 않는 메모리 누수

Question

무한정 성장할 내부 C++ 응용 프로그램이 있습니다. 따라서 RSS를 실제로 죽이는 논리를 구현해야했습니다. 주문의 유사성을 유지하기 위해 특정 피크 크기 (2.0G)에 도달합니다. 그러나 이것은 이상한 행동을 보여주었습니다.

먼저, Valgrind w/memcheck를 통해 응용 프로그램을 실행하고 여기 저기에 임의의 메모리 누수를 수정했습니다. 그러나 이러한 메모리 누수의 정도는 10 메가 바이트에서 측정되었습니다. 이는 실제 메모리 누수가 없다는 것을 의미하기 때문에 의미가 있습니다. 응용 프로그램 측면에서 메모리 관리가 좋지 않을 수 있습니다.

다음으로, Valgrind w/massif를 사용하여 메모리가 어디로가는 지 확인하고 이것이 이상하게 들립니다. 피크 스냅 샷은 161M이며 RSS 필드를 사용하여 볼 수있는 1.9G + 피크 근처는 없습니다. 가장 큰 소비량은 std :: string에서 기대할 수있는 곳이지만 비정상적인 것은 아닙니다.

마지막으로, 이것이 가장 수수께끼인데, 우리가이 메모리 누수를 알기 전에 실제로 AWS에서이 서비스를 테스트하고 있었고 즐겁게 CC2에서 많은 수의 직원을 지정했습니다. 8XL 기계, 44 노동자. RAM은 60.5G이고 스왑은 없습니다. 한 달 빨리 감기 : 나는 주인을 보러 간다 - 그리고 낮게 보아라. 그러면 그것은 RAM에서 끝나게된다 - 그러나! 프로세스는 여전히 잘 실행되고 있으며, 메모리 사용의 다양한 단계에 고착되어 있습니다. 800M에서 1.9G로 거의 고르게 분산되어 있습니다. 가끔씩 dmesg은 메모리를 할당 할 수 없다는 Xen 오류를 인쇄하지만 그 외의 프로세스는 결코 죽지 않고 적극적으로 처리합니다 (즉, 멈추지 않았습니다).

여기에 누락 된 것이 있습니까? 그것은 근본적으로 작동하지만, 저의 삶에 대해, 나는 그 이유를 알 수 없습니다. 무엇을 다음에 찾아야하는지에 대한 좋은 추천이 될 것입니까? 내가 알아낼 수있는 도구가 있습니까?

Answer 1

valgrind memcheck는 메모리를 "포기"할 때만 발견합니다. while(1) vec.push_back(n++);은 사용 가능한 모든 메모리를 채우지 만 누출을보고하지 않습니다. 사물의 소리에 의해 많은 공간을 차지하는 어딘가에서 줄을 모으고 있습니다. 나는 많은 메모리를 사용하지만 실제로 그것을 유출하지 않는 코드에서도 작업했습니다. valgrind가 행복한 곳은 모두 누수가 아닙니다!]. 때로는 메모리 할당에 일부 마커를 추가하거나 메모리를 할당하는 위치를 나타 내기 위해 마커를 추가하기 만하면됩니다.

std:: 함수에는 일반적으로 Allocator 인수가 있습니다. 여러 개의 다른 메모리 풀을 구현하면 메모리를 할당하는 위치를 알 수 있습니다.

프로세스에 메모리가 조각화되어있어 힙에 여유 공간이 많지 않은 경우도 있습니다. 예를 들어 다음과 같이 추가 할 수 있습니다. 캐릭터 라인의 사이즈