Tableau Server (Prep Conductor) – Prep flow fails at the output step with "[SQLSTATE:57014] canceled" when Server Resource Manager (SRM) cancels Hyper for memory

Work through the following steps in order, stopping when the issue is resolved. The goal is to give the flow's output step more memory headroom on the node that runs flow processing.

Step 1 — Reduce the volume the output step has to materialise at once

The most in-your-control fix. Lowering peak memory at the output step often keeps the node under the SRM limit.

1. Trim unneeded output columns and rows before the output step.
2. Where possible, narrow the run (e.g. a shorter date range or a subset) to confirm the flow succeeds at lower volume — this both validates the cause and can serve as an interim workaround.
3. If the flow contains multiple heavy branches or unions/joins, consider splitting it into smaller sequential flows so less data is held in memory simultaneously.

Step 2 — Reduce competing workload on the flow-processing node

SRM enforces a limit on total memory across all processes on the node, so other heavy processes sharing the node make the flow more likely to be cancelled.

1. Identify the node running flow processing (from the failing job's backgrounder/flowprocessor logs).
2. Check what else runs on that node — a co-located viz-rendering process (vizqlserver) or other memory-heavy service reduces the headroom available to the flow.
3. Reschedule the flow to a window with lower competing load, or rebalance processes across nodes, as an interim measure.

Step 3 — Isolate Prep Conductor (flow processing) onto its own dedicated node

The most reliable fix where topology allows it: give flow processing a node where it isn't competing with viz rendering or other heavy workloads for memory.

1. Add or designate a node dedicated to the Backgrounder/Prep Conductor flow workload.
2. Move viz-rendering (vizqlserver) and other memory-intensive processes off that node.
3. Re-run the flow and confirm it completes.

Step 4 — Increase the memory available to the node

The most disruptive option, as it requires a hardware or infrastructure change.

1. If none of the above provides enough headroom, increase the physical/allocated memory on the flow-processing node so total usage stays under the SRM limit at peak.