SAS VIYA Guide

Monitoring CAS_CACHE_DISK: Under the Hood of SAS Viya Memory

Admin 58 vistas

Nivel de dificultad

Débutant

Publicado el : 04/12/2025

Consejo del experto

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 • 52

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

Ver toda la categoría

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;

Aviso importante

Los códigos y ejemplos proporcionados en WeAreCAS.eu son con fines educativos. Es imperativo no copiarlos y pegarlos ciegamente en sus entornos de producción. El mejor enfoque es comprender la lógica antes de aplicarla. Recomendamos encarecidamente probar estos scripts en un entorno de prueba (Sandbox/Dev). WeAreCAS no acepta ninguna responsabilidad por cualquier impacto o pérdida de datos en sus sistemas.

Volver a la lista de artículos

SAS y todos los demás nombres de productos o servicios de SAS Institute Inc. son marcas registradas o marcas comerciales de SAS Institute Inc. en los EE. UU. y otros países. ® indica registro en los EE. UU. WeAreCAS es un sitio comunitario independiente y no está afiliado a SAS Institute Inc.