Skip to content

fix(logs): optimize LogRecord memory by removing redundant context#4977

Open
ajuijas wants to merge 4 commits intoopen-telemetry:mainfrom
ajuijas:issue-4957-logrecord-memory
Open

fix(logs): optimize LogRecord memory by removing redundant context#4977
ajuijas wants to merge 4 commits intoopen-telemetry:mainfrom
ajuijas:issue-4957-logrecord-memory

Conversation

@ajuijas
Copy link

@ajuijas ajuijas commented Mar 13, 2026

Optimized LogRecord memory usage in BatchLogRecordProcessor by clearing the Context object before buffering. Correlation IDs (TraceId, SpanId, TraceFlags) are still preserved.

Resolves #4957

Description

This PR optimizes memory usage in the Logging SDK by implementing a targeted context-clearing strategy in the BatchLogRecordProcessor.

Motivation:
Currently, each LogRecord stores a reference to the full Context it was created with. In high-throughput scenarios where logs are emitted within unique and large contexts (e.g., each request having unique baggage), these objects are pinned in memory as long as the logs are buffered in a processor like BatchLogRecordProcessor. This leads to significant memory inflation that scales with both the number of buffered logs and the size of the contexts.

Solution:
To fix the memory leak without breaking context access (e.g., for Baggage), we keep the context attribute in the API but clear it in the BatchLogRecordProcessor right before buffering. We do this by creating a shallow copy of the LogRecord and setting its context to None. This severs the memory-heavy reference before the log enters the long-lived queue, keeping the API compatible while achieving the performance fix.

Changes:

  • opentelemetry-sdk: Updated BatchLogRecordProcessor.on_emit to shallow-copy the record and clear its context reference.
  • opentelemetry-sdk: Added import copy to the SDK export module.
  • CHANGELOG.md: Added an entry for the memory optimization in the SDK.

Fixes #4957

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • Optimization (memory efficiency improvement)

How Has This Been Tested?

I performed local benchmarking and ran the full unit test suite to ensure correctness and quantify the memory savings.

  1. Memory Benchmark: Emitted 2,000 logs, each within a unique context containing ~50KB of baggage.
    • Before Fix: Memory usage increased by ~154.4 MB.
    • After Refined Fix: Memory usage increased by ~0.84 MB.
    • Result: Reduced memory overhead by >99%.
  2. Context Verification: Verified that a SimpleLogRecordProcessor can still correctly read Baggage items from log_record.context during emission.
  3. Unit Tests: Executed the full suite of log tests across opentelemetry-api and opentelemetry-sdk.
    • Total: 43 PASSED, 0 FAILED.

Does This PR Require a Contrib Repo Change?

  • No.

Checklist:

  • Followed the style guidelines of this project
  • Changelogs have been updated
  • Unit tests have been added/updated
  • Documentation has been updated (N/A)

@ajuijas ajuijas requested a review from a team as a code owner March 13, 2026 10:16
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Mar 13, 2026

CLA Signed

The committers listed above are authorized under a signed CLA.

Removed direct storage of the Context object in LogRecord to prevent
memory inflation when logs are buffered. Correlation IDs (TraceId,
SpanId, TraceFlags) are still preserved.

Resolves open-telemetry#4957
@ajuijas ajuijas force-pushed the issue-4957-logrecord-memory branch from 45c7255 to c77ecd0 Compare March 13, 2026 10:18
@herin049
Copy link
Contributor

Not sure if we want to completely remove the entire context from each log record since this will prevent log processors from accessing other useful information from the current context (e.g. baggage). Not sure how common these use cases might be, so it might be fine regardless.

ajuijas added 2 commits March 14, 2026 20:26
…etry#4957)

Clear LogRecord context references before buffering in the SDK to prevent memory inflation while maintaining context access for synchronous processors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

why does LogRecord store the entire context it was called with

3 participants