Change Execution Limits

GoodData incorporates safeguards to prevent memory overflow, cache overflow, and excessively long computation times during data processing. These protective limits can be configured via Helm Chart values to ensure optimal performance and resource management for your data source computations.

Max Overall Result Size

The max size of the result from Data Source (database) in bytes. If the limit is reached, an error is returned and the computation ends in failure.

The following endpoints are affected by the raw result max size limit:

/api/v1/actions/workspaces/{workspaceId}/execution/afm/execute
/api/v1/actions/workspaces/{workspaceId}/execution/collectLabelElements

Helm Chart: platform_limits.max_result_bytes

Default is set to: 100 MB

Max Single Dimension Size

We can understand dimension as number of rows or columns in table or number of colors in heatmap. Theoretically there can be more than two or three dimensions. This value limits size of one dimension. No dimension can exceed this limit in the computed result.

The max size depends on whether the dimension has the measureGroup property or not. The property measureGroup represents a list of metrics. For an example containing the measureGroup property, look up itemIdentifiers in the Compute JSON example in the Access Raw Data Through API article.

The platform_limits.max_dimension_size property sets the limit for dimensions that are NOT using the measureGroup property.

The following endpoint is affected by this limit:

/api/v1/actions/workspaces/{workspaceId}/execution/afm/execute

Helm Chart:: platform_limits.max_dimension_size

Default is set to: 10,000

Max Column Size

The platform_limits.max_column_size property sets the limit for a dimension that is using the measureGroup property.

See Max Single Dimension Size for details.

The following endpoint is affected by this limit:

/api/v1/actions/workspaces/{workspaceId}/execution/afm/execute

Helm Chart:: platform_limits.max_column_size

Default is set to: 1,000

Max Cell Count

Cell count is number of all computed values. We can imagine it as volume. Table volume is rows * columns, heatmap volume is rows * columns * colors. Total cell count in result can’t exceed the limit.

The following endpoint is affected by this limit:

/api/v1/actions/workspaces/{workspaceId}/execution/afm/execute

Helm Chart:: platform_limits.max_result_cell_count

Default is set to: 1,000,000 cells

Adjust Resource Limits

When increasing any of the execution limits described above, it is recommended to proportionally adjust the resource requests and limits for the following pods to ensure stability and avoid potential OutOfMemory (OOM) terminations or performance degradation:

quiver-xtab
quiver-ml
quiver-cache
tabular-exporter

Recommended Scaling Strategy

Use a conservative approach when increasing resources, based on the coefficient N, which represents the multiplier by which the execution limits are increased.

Pod	CPU Limit Increase (millicored)	Memory Increase	Additional Notes
q`uiver-xtab`	Increase by `N × 100m`	Increase to `N × current memory`
`quiver-ml`	Increase by `N × 50m`	Increase to `N × current memory`
`quiver-cache`	Increase by `N × 50m`	–	Also increase mounted storage capacity by at least `N × current capacity`
`tabular-exporter`	Increase by `N × 100m`	Increase to `N × current memory`

Post-Scaling Tuning

After applying the increase, further tuning can be performed based on workload characteristics and observed usage patterns. To estimate the required sizing after increasing execution limits, monitor:

CPU and memory usage of the affected pods during traffic spikes.
Disk usage of the quiver-cache pod.

Continuous observation and incremental adjustments will help maintain optimal performance and prevent resource exhaustion.

Configure Rate Limits