메모리가 어디에서 소비되는지 알아보십시오.

Question

며칠 동안 실행될 수있는 비교적 큰 숫자의 응용 프로그램 코드가 있으며 결국에는 일부 숫자가 유출됩니다. 모든 것은 C++로 작성되어 제 3 자 라이브러리를 사용하고 GCC 4.6을 사용하여 컴파일됩니다. 이 코드는 전체에서 공유 포인터를 사용합니다.

시간이 지남에 따라 코드의 메모리 소비는 (공유 된) 모든 메모리가 모두 소모 될 때까지 증가하고 충돌합니다. 알고리즘 적으로 코드는 시간이 지남에 따라 메모리를 구축해서는 안되기 때문에 어딘가에 버그가있을 것입니다.

valgrind의 누수 검사기를 통해 작은 예제를 실행했는데 모두 괜찮다고보고했습니다. 내 생각에 공유 포인터가 실수로 임의의 장소에서 생성되어 불필요한 데이터가 프로세스에서 해제되는 것을 방지 할 수 있다고 생각했습니다. (하지만 이는 단지 추측에 불과합니다.)

하루가 끝나면 디버깅하는 방법이 부족합니다. 아이디어가 있으십니까?

Answer 1

이미 valgrind 도구를 사용할 수 있으므로 대용량 도구를 실행하는 것이 좋습니다.

Massif는 메모리 할당 원본을 추적하며 보고서는 각 할당 사이트/함수가 생성 한 바이트 수를 나타냅니다. 이것은 메모리 파열이 어디에서 유래했는지 이해하는 데 도움이됩니다.

Answer 2

누출이없는 경우에도 메모리 조각화가 발생할 수 있습니다.

Linux를 사용하는 경우 jemalloc 할당자를 사용하는 것이 좋습니다. 그것은 리눅스에서 뛰어납니다. 그것은 많은 아키텍쳐에서 실행되며 zLinux에서도 성공적으로 사용되었습니다 (IBM zSeries 메인 프레임에서). 분명히, 캐싱 STL 관련 메모리 할당에 LD_PRELOAD=/usr/lib/libjemalloc.so <app>

Answer 3

GNU의 된 libstdC++ 기본값 : 당신은 심지어 응용 프로그램이나 라이브러리를 다시 할 필요가 없습니다, 단지 jemalloc를 구축하고이 같은 LD_PRELOAD 세트를 사용하여 응용 프로그램을 시작 - 그것은 사용하기 정말 쉽습니다 마이크로 벤치 마크 속도 때문에. 그러나 실제 효과는 tcmalloc 및 jemalloc와 같은 할당자를 사용할 때 속도와 메모리 사용량 모두에서 상당히 부정적인 경향이 있습니다. tcmalloc은 환경에서 GLIBCPP_FORCE_NEW = 1 및 GLIBCXX_FORCE_NEW = 1을 설정하여이 동작을 비활성화하지만 (각각 libstdc++ 버전 3.3 및 3.4), 그렇게하지 않는 다른 할당자를 알고 있습니다. 따라서 일반적으로 응용 프로그램을 시작할 때 적절한 환경 변수를 설정하는 것이 좋습니다.