30.1c Memory used vs. total: identifying memory leaks and stuck processes

📦 Virtualization and Cloud 📖 GPU Diagnostics and nvidia-smi Mastery

📘 Context Introduction

When running AI workloads on GPUs, memory is a precious resource. A single model training or inference job can consume gigabytes of GPU memory. But what happens when a process doesn't release memory after it finishes? Or when memory usage keeps climbing over time? These scenarios point to memory leaks or stuck processes. As an engineer new to AI infrastructure, learning to spot these issues early can save you from crashes, slowdowns, and wasted compute resources.

This guide will help you understand how to compare memory used vs. total memory using nvidia-smi, and how to identify when something is wrong.


⚙️ Understanding GPU Memory Basics

  • Total memory — The maximum amount of memory your GPU has available (e.g., 80 GB on an NVIDIA A100).
  • Used memory — The amount of memory currently consumed by running processes (e.g., model weights, activations, data batches).
  • Free memory — The difference between total and used memory.

A healthy system shows used memory fluctuating naturally as jobs start and stop. A problem arises when used memory stays high or keeps increasing without a corresponding active job.


📊 Key Metrics in nvidia-smi

When you run nvidia-smi, look for these two critical fields:

  • Memory-Usage — Shows used memory vs. total memory (e.g., 4096 MiB / 8192 MiB).
  • Processes — Lists all running processes using the GPU, including their PID and memory consumption.

For reference:

nvidia-smi
📤 Output: A table showing GPU index, name, memory usage, and a list of processes with their memory consumption.


🕵️ Identifying Memory Leaks

A memory leak occurs when a process allocates GPU memory but never frees it after finishing its work. Over time, this eats up available memory until no new jobs can start.

Signs of a memory leak: - Used memory stays high even after all visible processes have ended. - Memory usage increases steadily over time without a corresponding increase in workload. - You see "out of memory" errors when trying to launch new jobs, even though no active processes appear.

How to check: 1. Run nvidia-smi and compare Memory-Usage against the list of Processes. 2. If used memory is high but no processes are listed, that's a strong indicator of a leak. 3. Monitor over time — run watch -n 1 nvidia-smi to see if memory usage climbs without new processes starting.


📊 Visual Representation: GPU VRAM Framebuffer vs. Bar1 memory

This diagram displays GPU memory monitoring, separating physical VRAM framebuffer allocations from the BAR1 host-accessible memory space.

flowchart LR VRAM["GPU HBM/GDDR VRAM"] --> Framebuffer["Framebuffer Memory (Allocated to model weights)"] VRAM --> BAR1["BAR1 Memory (Host-accessible mappings for DMA transfers)"] classDef cpu fill:#eafaf1,stroke:#76b900,stroke-width:2px,rx:6px,ry:6px; classDef memory fill:#f0f7ff,stroke:#3498db,stroke-width:1.5px,rx:4px,ry:4px; classDef system fill:#f1f5f9,stroke:#64748b,stroke-width:1.5px; class VRAM cpu; class Framebuffer,BAR1 memory;

🛠️ Identifying Stuck Processes

A stuck process is a job that has crashed or hung but still holds onto GPU memory. It appears in the process list but is no longer doing useful work.

Signs of a stuck process: - A process appears in nvidia-smi with a PID but has been running for an unusually long time without progress. - Memory usage for that PID remains constant, even though the job should have completed. - Attempts to kill the process normally fail, or it refuses to release memory.

How to check: 1. Look at the Processes section in nvidia-smi — note the PID and memory consumption. 2. Use system tools to verify if the process is still responsive (e.g., check CPU usage or logs). 3. If the process is unresponsive, it's likely stuck.


📋 Comparison Table: Memory Leak vs. Stuck Process

Feature Memory Leak Stuck Process
Memory usage Increases over time or stays high Constant, tied to a specific PID
Process visible in nvidia-smi? Often no process listed Yes, a PID is shown
Cause Code bug — memory not freed after use Job crash or hang
Impact Gradual memory exhaustion Immediate memory block
Fix Restart GPU driver or reboot Kill the stuck process by PID

🧪 Practical Steps for New Engineers

Step 1: Baseline your system - Run nvidia-smi when no jobs are running. Note the baseline memory usage (should be near zero).

Step 2: Monitor during workloads - While a training job runs, check nvidia-smi periodically. Memory usage should be stable or slightly fluctuating.

Step 3: Investigate anomalies - If memory usage is high but no processes are listed → suspect a memory leak. - If a process is listed but won't die → suspect a stuck process.

Step 4: Take action - For a stuck process: identify the PID from nvidia-smi and use system commands to terminate it. - For a memory leak: restart the GPU driver or reboot the system to reclaim memory. Then investigate the application code.


✅ Summary

  • Memory used vs. total is your first diagnostic tool for GPU health.
  • A memory leak shows high usage with no visible processes.
  • A stuck process shows a persistent PID holding memory hostage.
  • Regular monitoring with nvidia-smi helps you catch these issues before they impact your AI workloads.

As you gain experience, you'll learn to spot these patterns quickly — saving time, compute resources, and frustration.