Heap Space exhaustion during large Meteor.publish result sets

Problem Context

When a Meteor server publishes a collection containing thousands of documents, Node.js can throw a Heap Space exhaustion error. This occurs because each client subscription keeps a “head” of the data set, and the DDP merge-box on the client side buffers incoming added and changed messages.

Measurement Goal

The aim is to identify the precise point where server memory usage spikes before applying any optimization, such as pagination or subscription narrowing.

Constraints and Uncertainty

• Server memory scales linearly with active subscriptions and returned result size.
• Client-side MergeBox may introduce additional memory overhead, but its contribution is not well quantified.
• Existing instrumentation (e.g., process.memoryUsage()) provides snapshots but not a continuous view of memory pressure during subscription churn.

Unresolved Questions

1. Which metrics or instrumentation best capture the moment a single large publication pushes the Node.js heap beyond its limit?
2. How can we distinguish memory growth caused by a massive publication from that caused by many concurrent, smaller subscriptions?
3. What role does the client-side MergeBox play in overall memory consumption, and how can its impact be measured independently?