SAS VIYA Guide

Monitoring CAS_CACHE_DISK: Under the Hood of SAS Viya Memory

Admin 58 views

Difficulty Level

Débutant

Published on : 04/12/2025

Expert Advice

Michael

"CAS_DISK_CACHE is your architecture's silent safety net: when RAM saturates, it absorbs the load until it hits the breaking point. To prevent node crashes, don't rely on standard user logs; you must leverage privilege elevation (superuser) within your CASL code. This is the only way to get accurate, cluster-wide telemetry of the physical disk space available on all workers

Dans : SAS VIYA Guide

SAS Viya: How to handle CASLIB names longer than 8 characters via the REST API

26/08/2024 • 39

SAS Viya Tutorial: Everything About the table.tableInfo Action

19/02/2024 • 51

Should the CASLIB Option Be Repeated in the LIBNAME Statement?

26/12/2023 • 38

Why is my CASUSER data not visible in Visual Analytics?

30/09/2023 • 34

SAS Viya & Python: How to Replace a Global Table?

30/07/2023 • 33

View full category

SAS^© Cloud Analytic Services (CAS) is the in-memory execution engine of the SAS^© Viya^™ platform. Its power lies in its ability to process massive volumes of data directly in RAM. However, a critical question often arises for administrators and architects: what happens when RAM is saturated or tables are too large?

This is where the CAS_DISK_CACHE (or Disk Cache) comes in.

The Role of the Disk Cache

The CAS_DISK_CACHE is a temporary storage space on the hard drive of the nodes (workers and controller). CAS uses it to:

"Paging": Offload data blocks from RAM to disk when memory is full (memory mapping).
Replication: Store copies of data blocks for high availability.

If this disk space becomes saturated, it leads to an immediate halt of processes, or even a crash of the CAS session. It is therefore vital to be able to query the status of this cache across the entire cluster.

Note :
Analysis of the Monitoring Code
The CASL (CAS Language) code below allows for auditing the state of this cache. Here is how it works, step by step:

1. Privilege Elevation (accessControl.assumeRole)
By default, a standard user only sees what pertains to their own session. To get an overview of the infrastructure (the physical state of the disks of all nodes), it is often necessary to have administrative rights. The `accessControl.assumeRole / adminRole="superuser";` statement attempts to switch the current user to the "Superuser" role. This allows viewing metrics from all nodes in the cluster, not just the controller.

2. The Action Call (builtins.getCacheInfo)
This is the core of the script. The `getCacheInfo` action from the `builtins` action set queries the underlying file system configured for the cache. It returns crucial information:

The access path (Path) on the Linux server.

The total available space (Total Size).

The current free space (Free Space).

3. The Display (print)
The result is stored in a dictionary variable (here named `cache`) and then displayed in the log or the SAS^© Studio results output. This allows for quickly identifying if a specific node is in danger of saturation ("Disk Full").

1	PROC CAS;
2	/* -------------------------------------------------------------------
3	OBJECTIF : Auditer l'espace disque du CAS_DISK_CACHE
4	PRÉREQUIS : Droits suffisants pour assumer le rôle de Superuser
5	------------------------------------------------------------------- */
6
7	/* 1. Tentative de passage en mode Superuser pour une visibilité globale */
8	/* Note : Si l'utilisateur n'a pas les droits, cette étape peut échouer ou être ignorée */
9	ACCESSCONTROL.assumeRole / adminRole="superuser";
10
11	put "--- ÉTAT DU CAS_CACHE_DISK (Cache Disque) ---";
12
13	/* 2. Récupération des métriques de cache pour chaque nœud du cluster */
14	BUILTINS.getCacheInfo RESULT=cache;
15
16	/* 3. Affichage structuré des résultats */
17	/* Les colonnes typiques sont : Node Name, Path, Free Space, Total Size */
18	PRINT cache;
19	RUN;

Important Disclaimer

The codes and examples provided on WeAreCAS.eu are for educational purposes. It is imperative not to blindly copy-paste them into your production environments. The best approach is to understand the logic before applying it. We strongly recommend testing these scripts in a test environment (Sandbox/Dev). WeAreCAS accepts no responsibility for any impact or data loss on your systems.

Back to article list

SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. WeAreCAS is an independent community site and is not affiliated with SAS Institute Inc.