Auditing

🔍 Deep Dive: Advanced Auditing Methodology

RAM-FLOW provides more than raw data; it offers a methodology to bridge the gap between Python's high-level objects and the Operating System's reality.

Why the "Final Audit" differs from the "Execution Tree"

A common question is: "Why is the Residual Leak higher than the sum of my tracked functions?"

• Execution Tree (Net Self): This is a surgical measurement. It calculates the memory delta inside your decorated function. It is designed to find the specific "culprit" function.
• Final Reclamation Audit: This is the System Truth. It includes:
  • Runtime Overhead: Internal buffers for logging, string formatting, and temporary objects.
  • C-Level Allocations: Libraries like oracledb, numpy, or cryptography allocate memory in C, which is often invisible to Python’s Garbage Collector (GC) until the process fully releases it.

⚓ The Oracle "Double-Lock" Trap

Database operations are the #1 cause of OOM (Out Of Memory) crashes. Memory is often held in two places:

• Driver Level: Internal C-buffers (like cx_Oracle or oracledb) that are only released when db.close() is called.
• Application Level: The Python variables (lists/dicts) storing the result sets.

Warning: RAM-FLOW exposes this trap: If your report shows a BLOATED status after the connection is closed, it means your Python variables are still holding the data hostage in RAM.

🛡️ Handling Negative Leak Values (Reclamation State)

During the final audit, Python’s GC may trigger a massive cleanup of objects created before the tracker started. This results in a negative delta.

RAM-FLOW stabilizes these to 0.00 MB to represent a Perfect Reclamation State, ensuring report clarity and avoiding confusing "negative memory" metrics.