Skip to main content

Resource Allocation

Resource management is a feature that provides granular control over your computing resources. By creating distinct environments and allocating specific resource quotas, you can ensure performance, manage costs, and isolate workloads for different teams, projects, or applications.

This document outlines the concepts behind resource allocation and the hierarchy used to manage it.

Core Concepts: The Resource Hierarchy​

Resource allocation follows a clear, three-tiered hierarchy. At the highest level is the Workspace, which contains one or more Namespaces. Each Namespace, in turn, contains one or more Queues that run your deployments.

Compute Units (CUs) are allocated from the top down. A workspace has a total CU quota, which is then distributed among its namespaces. The resources of a namespace are further distributed among its queues.

This structure is illustrated below:

1. Workspaces​

A workspace is the primary container for your projects and resources. It has a total resource quota (measured in CUs) that is determined by its billing model. Different billing models offer different ways to manage this top-level quota:

  • Subscription: A fixed amount of CUs is purchased for a specific period.
  • Pay-as-you-go: Resources are consumed on demand, with a configurable quota ceiling to control costs.
  • Hybrid: A combination of fixed (subscription) and elastic (pay-as-you-go) resources.

2. Namespaces​

Within a workspace, you can create multiple namespaces to isolate resources and permissions. This is useful for separating development, testing, and production environments, or for dedicating resources to different teams. Each namespace is allocated a portion of the parent workspace's total CUs.

3. Queues​

Queues exist within a namespace and are the final destination for resource allocation. Deployments and session clusters are run in a specific queue. This mechanism prevents a single resource-intensive job from consuming all the resources in a namespace, which could disrupt other deployments.

Every namespace includes a default-queue, but you can create additional queues to further segment resources and manage job priorities, especially for batch deployments.

The Strategy for Scaling Resources​

The hierarchical structure dictates the strategy for adjusting your resource allocation.

  • Scaling Up (Top-Down): To increase resources, you start at the top. First, increase the workspace's total CU quota. Then, allocate those new resources to the desired namespace(s). Finally, assign the additional namespace resources to the specific queue(s).
  • Scaling Down (Bottom-Up): To decrease resources, you start at the bottom. First, reduce the CU allocation for the queues. This frees up resources at the namespace level. You can then reduce the namespace's allocation, which in turn frees up CUs at the workspace level.

Important Considerations​

  • Permissions: Ensure the user or role performing these actions has the necessary permissions for both viewing the target component (workspace/namespace) and reconfiguring its resources.
  • Queue Deletion: A queue that has an active deployment running in it cannot be deleted. You cannot delete the default-queue.
  • Minimum Resources: You cannot reduce the resource quota of a namespace or workspace to a value lower than the sum of the resources currently being consumed by its child components. For example, a namespace's quota cannot be set lower than the total CUs allocated to all of its queues.
On this page