如何用Valgrind获取程序运行时的内存占用大小？

Great question! Valgrind is awesome for catching memory leaks and debugging memory issues, but it's not the most straightforward tool for measuring full RAM and cache usage. Let's walk through how you can use Valgrind for parts of this, plus better tools for getting the complete picture.

Using Valgrind for Memory & Cache Data #

Valgrind has specialized tools that can give you targeted memory-related metrics, even if they don't cover every aspect of total RAM usage.

1. Heap Memory Usage: Massif #

If you're focused on heap memory allocation (the memory your program requests with malloc/new), Valgrind's Massif tool is perfect. It tracks heap memory over time and generates a detailed report of peaks and allocation patterns.

• Run your program with Massif:

  valgrind --tool=massif ./your_program
  

• This creates a file named massif.out.<pid> (replace <pid> with your program's process ID). To read the formatted report, use:

  ms_print massif.out.<pid>
  

• The report will show you peak heap memory, allocation hotspots, and how memory usage changes during execution. Keep in mind: Massif doesn't track stack memory, global variables, or shared library memory—only heap allocations.

2. Cache Usage: Cachegrind #

For memory cache behavior (L1/L2/LLC cache hits, misses, and utilization), Valgrind's Cachegrind is designed exactly for this. It simulates cache interactions to show how your program uses CPU caches.

• Run with Cachegrind:

  valgrind --tool=cachegrind ./your_program
  

• The output file is cachegrind.out.<pid>. Use this command to get an annotated breakdown:

  cg_annotate cachegrind.out.<pid>
  

• You'll get stats like cache miss rates, total cache references, and even per-function cache behavior. This helps you understand how much of your data is sitting in cache vs. being pulled from main RAM.

Better Tools for Total RAM Usage #

If you need the full picture of physical RAM your program is using (including heap, stack, globals, shared libraries, etc.), Valgrind isn't the best choice—it slows down your program drastically (10-100x slower) and doesn't track all memory regions. Instead, use these system-level tools:

• top/htop: Real-time monitoring. For a specific process, run top -p <pid> and look at the RES field (Resident Memory Size)—this is the actual physical RAM your program is using. htop is a more user-friendly, colored alternative.
• ps: Quick one-off stats. Run:

  ps -o pid,rss,vsz,cmd -p <pid>
  

  rss is physical memory in KB, vsz is total virtual memory.
• pmap: Detailed memory mapping. Get a breakdown of every memory region your process uses with:

  pmap -x <pid>
  

  Sum the RSS column to get total physical RAM usage.
• smem: Smart memory accounting. This tool accounts for shared memory (so you don't double-count shared libraries used by multiple processes). Run:

  smem -t -k -p -u <pid>
  

  Look for the RSS or USS (Unique Set Size) field for your process's actual unique RAM usage.
• perf: Advanced memory performance. For cache stats and memory bandwidth, use:

  perf stat -e cache-misses,cache-references ./your_program
  

  This gives you real hardware-level cache metrics without Valgrind's overhead.

A quick note: If you just need total RAM usage, stick with top, ps, or smem—they're fast and accurate. Reserve Valgrind for when you need to debug memory leaks or analyze cache behavior at the code level.

内容的提问来源于stack exchange，提问作者david