Mastering Resource Allocation in SAS Viya: An Expert's Guide to Launcher Contexts

In a modern Kubernetes-based architecture like SAS^© Viya^™, resource management (CPU and RAM) is no longer static. It becomes dynamic and granular. One of the keys to optimizing infrastructure costs while ensuring the performance of critical processes is to move away from the one-size-fits-all model.

This article details the methodology for implementing a strategy of differentiated contexts (Small, Medium, Large) using Launcher Contexts, a powerful but often underutilized feature of SAS^© Viya^™.

1. Technical Fundamentals: The Kubernetes Mechanics

To properly configure SAS^© Viya^™, it is imperative to understand how the underlying engine (Kubernetes) allocates resources to pods (the containers running your SAS^© Compute, Connect, or Batch sessions).

Each pod is defined by two distinct metrics for CPU and Memory. Understanding the distinction between Request and Limit is crucial to avoid instability.

The Concept of "Request" (The Guarantee)

The Request is the amount of resources that Kubernetes reserves when the pod starts.

• Role: It is used for scheduling. Kubernetes looks for a node with at least this much available capacity.

• Implication: If you set a request too high, your pods will remain in a "Pending" state for lack of space, even if the pod does not actually use these resources.

The Concept of "Limit" (The Ceiling)

The Limit is the impassable barrier imposed on the pod once it is running.

• CPU Behavior: If a SAS^© process tries to consume more CPU than its limit, it is not killed, but throttled (CPU Throttling). Performance collapses, but the process continues.

• Memory Behavior (Danger): If a process exceeds its RAM limit, the Linux kernel intervenes brutally via the OOM Killer (Out of Memory Killer) and terminates the process. The SAS^© session crashes immediately.

Architecture Note: When SAS^© Workload Orchestrator is enabled (which is the case by default), it adds an additional management layer (queues, priorities) on top of these native Kubernetes mechanisms.

2. The Strategy: Defining Service Profiles

Rather than leaving all users with the default limits (often conservative, e.g., 2 vCPUs), the goal is to create profiles adapted to different use cases:

3. Technical Implementation (Step-by-Step)

The configuration takes place in two stages in SAS^© Environment Manager. You must first lift the global barriers before creating the specific contexts.

Step A: Unlock the Global Ceilings (sas©.launcher.max)

For security, SAS^© Viya^™ imposes global maximum limits. You cannot create a "Large" context (e.g., 8 CPUs) if the global limit is set to 2 CPUs.

1. Go to SAS^© Environment Manager > Configuration.

2. Search for the Launcher service.

3. Edit the configuration instance sas©.launcher.max.

As shown in the configuration snapshots, you need to increase the cpu.limit value.

• Action: Change cpu.limit from the default value (often 2) to a higher value (e.g., 8 or more depending on your physical nodes).

• Tip: Do not touch the global cpu.request if you do not have pod placement problems. Keep them low (e.g., 100m) to facilitate the startup of pods.

Step B: Create the "Large" Launcher Context

Once the global ceiling has been raised, you can create the specific context.

1. Go to Contexts > Launcher contexts view.

2. It is recommended to duplicate an existing context: Right-click on "SAS^© Studio launcher context" > Copy.

3. Name it explicitly, for example: SAS© Studio launcher context - large.

4. Open the Advanced tab.

This is where you override the default values.

• CPU Limit: Enter 8 (for 8 vCPUs).

• Memory Limit: You can leave it blank (to use the default) or increase the value (e.g., 8Gi).

• Requests: It is often wise to leave the "Request" fields blank or low (e.g., 50m for CPU, 300M for RAM) to ensure that the pod can start easily on the cluster, even if it consumes more (up to the limit) later (this is the burst mechanism).

Important: Any value left blank on this screen will inherit the values defined in sas©.launcher.default.

4. The Final User Experience

Once these Launcher Contexts are created (e.g., Extra Small, Small, Large), they are not directly visible to the end user. You must associate them with Compute Contexts.

It is at the Compute Context level (for example in SAS^© Studio) that the user will choose their environment:

• The user will see in their list of contexts: "SAS^© Studio Compute - Large", "SAS^© Studio Compute - Standard".

• By selecting "Large", their session will be instantiated by the Launcher Context configured with 8 CPUs.

This empowers users: they can use an economical "Standard" context for coding, and switch to a "Large" context only to run the final process.