Loading

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

Publiceringsdatum: Jul 14, 2026
Beskrivning

A scheduled or ad-hoc Tableau Prep flow runs on Tableau Server (Prep Conductor), reads its input data successfully, then fails — most often at or near the final output step — with an error such as:

System error: An error occurred while communicating with the data source. [SQLSTATE:57014] canceled — Something went wrong. Try rerunning the flow.

The flow frequently completes its input read and only fails when the output step materializes the result. Reruns fail the same way, and the job-level error can be misleading — it may surface a generic "communicating with the data source" message, an early-termination note, or an unrelated-looking error that masks the true cause. The underlying trigger is that the Server Resource Manager (SRM) has cancelled the Hyper query for exceeding the node's memory threshold.

Lösning

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.
Knowledge-artikelnummer

005388955

 
Laddar
Salesforce Help | Article