BadOutOfMemory
BadServer limits
BadOutOfMemory means the server could not allocate what your request needed. On embedded servers it is usually the size of what you asked for; on software servers it is usually accumulated load from too many subscriptions, monitored items or sessions. Reduce the request first, then reduce the load.
What you actually see
Requests start failing under load while smaller requests still succeed, and the server may recover on its own once clients back off.
Why it happens
- Too many monitored items or subscriptions in totalEach monitored item costs a queue, and each subscription costs bookkeeping and a notification buffer. Servers advertise MaxMonitoredItemsPerSubscription in ServerCapabilities; where that value is absent or zero, collectors default to a very large number and can walk straight into the memory ceiling.
- Oversized queue sizesQueue size multiplies with monitored item count. Setting a large queue on every item as a precaution turns a modest tag list into a large fixed allocation. Size queues from the ratio of publishing interval to sampling interval, not from a global default.
- A single very large request or responseA browse of a huge folder, a read of a large array, or a history read over a long window can exceed what the server can assemble at once. This usually appears alongside BadEncodingLimitsExceeded or BadResponseTooLarge on different products.
- Session and channel accumulationOrphaned sessions from a reconnect loop hold their diagnostics and their subscriptions until they time out. A connect storm therefore turns into a memory problem, not just a session-count problem.
- A constrained embedded targetController-embedded servers work within a few megabytes. There is no configuration that adds memory, so the only fix is to ask for less: fewer items, smaller queues, longer intervals.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Shrink the failing request firstHalve the batch: fewer nodes per read, fewer monitored items per CreateMonitoredItems call, a shorter history window, a browse with MaxReferencesPerNode set and BrowseNext for the rest. If the smaller request succeeds, you have both a workaround and a measurement of the ceiling.
- Read the server limits and respect themRead MaxMonitoredItemsPerSubscription, MaxSubscriptionsPerSession, MaxSessions and the operation limits under Server/ServerCapabilities/OperationLimits. Configure the collector to those numbers instead of to library defaults.
- Cut queue sizes and distinct publishing intervalsSet queue size from the publishing to sampling ratio plus a small margin, and minimise the number of distinct publishing intervals, since each distinct interval forces another subscription with its own overhead.
- Find and clear orphaned sessionsRead SessionDiagnosticsArray under Server/ServerDiagnostics and identify sessions with no recent activity. Shorten the revised session timeout so dead sessions age out, then fix the client that produced them.
- Stagger reconnects and cap outstanding requestsAdd jitter and bounded exponential backoff to client reconnects, and cap the number of outstanding Publish requests. Staggering client connects is the most effective single client-side measure against the load spikes that trigger this.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| open62541 (C) | Memory limits are set in the server configuration and are typically small on embedded targets. Reducing monitored item count and queue size is the only realistic lever; the allocator will not grow. |
| UA-.NETStandard (C#) | Session, subscription and monitored item limits live in the server configuration, and the diagnostics nodes report current counts. Watch the counts rather than waiting for the allocation failure. |
| OPC Publisher | Where the server does not advertise MaxMonitoredItemsPerSubscription, it defaults to a very large value. Set the limit explicitly in the configuration when the target server is small. |
| Siemens S7-1500 | Subscription and monitored item budgets are bounded by controller resources and firmware. Size the tag list against the documented limits for your firmware and verify with the vendor documentation. |
| Ignition | Tag group configuration drives the subscription and monitored item count on the server. Consolidating groups and lengthening slow-tag rates reduces server-side allocation directly. |
| node-opcua | A container or process memory limit produces the same symptom as a small device. Where you run the server yourself, check the process resident set and any container limit before concluding the code is at fault. |
What it looks like in the log
CreateMonitoredItems failed: BadOutOfMemory after 8000 items
Allocation failure while assembling response; request aborted
Subscription creation refused: server memory budget exhaustedConfirm the fix
Rebuild the subscription set within the advertised limits and confirm the server sustains it through a full shift with no refusals and stable memory reported in its diagnostics.
Stop it happening again
Design to the advertised operation limits, size queues deliberately, keep the number of distinct publishing intervals small, and alarm on monitored item and session counts crossing a threshold below the server limit.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.