Gouvernance des Ressources CAS sous SAS Viya 4

Pour optimiser les performances, il est crucial de connaître les plafonds de ressources. En utilisant le paramètre name avec les valeurs MAXCORES, MAXCORESPERWORKER ou MEMORYSIZE, vous obtenez les limites de cœurs CPU et de mémoire vive allouées. Cela permet d'ajuster les charges applicatives et de s'assurer que le cluster respecte les licences logicielles et les capacités matérielles de l'infrastructure cloud ou sur site.

Comment vérifier les limites de puissance de calcul et de mémoire de votre cluster ? - getServOpt

Pour optimiser les performances, il est crucial de connaître les plafonds de ressources. En utilisant le paramètre name avec les valeurs MAXCORES, MAXCORESPERWORKER ou MEMORYSIZE, vous obtenez les limites de cœurs CPU et de mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. vive allouées. Cela permet d'ajuster les charges applicatives et de s'assurer que le clusterEnsemble de nœuds (machines) interconnectés, gérés par Kubernetes, qui collaborent pour exécuter les microservices et le moteur CAS de SAS Viya, assurant haute disponibilité et passage à l'échelle. respecte les licences logicielles et les capacités matérielles de l'infrastructure cloud ou sur site.

Schéma : Comment vérifier les limites de puissance de calcul et de mémoire de votre cluster ?

Exemple de Code Additionnel

/* CASL Script : Audit des Limites CPU et Mémoire de la Session
(c) Nicolas Housset 2026 - Code SAS pour VIYA 4 - testé et validé en version 2024.09 */

proc cas;
/* 1. Extraction des plafonds de coeurs (Global et par Worker) */
sessionProp.getSessOpt result=r_cores / name="MAXCORES";
print "Limite globale de coeurs du cluster (MAXCORES)       : " r_cores.MAXCORES;

sessionProp.getSessOpt result=r_worker / name="MAXCORESPERWORKER";
print "Limite de coeurs par noeud worker (MAXCORESPERWORKER) : " r_worker.MAXCORESPERWORKER;

/* 2. Extraction du plafond de la mémoire vive allouée */
sessionProp.getSessOpt result=r_mem / name="MEMORYSIZE";
print "Plafond de mémoire vive allouée (MEMORYSIZE)          : " r_mem.MEMORYSIZE;

/* 3. Vérification de la configuration physique via l'état K8s sous-jacent */
builtins.serverStatus result=status;

print "---";
print "Rapport d'état matériel K8s par noeud CAS :";
for row in status.server;
print " > Noeud " row.node " (" row.role ") - Coeurs utilisables : " row.coreCount " | RAM détectée : " row.memory;
end;
quit;

1	<pre>/* CASL Script : Audit des Limites CPU et Mémoire de la Session
2	(c) Nicolas Housset 2026 - Code SAS pour VIYA 4 - testé et validé en version 2024.09 */
3	PROC CAS;
4	/* 1. Extraction des plafonds de coeurs (Global et par Worker) */
5	sessionProp.getSessOpt RESULT=r_cores / name="MAXCORES";
6	PRINT "Limite globale de coeurs du cluster (MAXCORES) : " r_cores.MAXCORES;
7	sessionProp.getSessOpt RESULT=r_worker / name="MAXCORESPERWORKER";
8	PRINT "Limite de coeurs par noeud worker (MAXCORESPERWORKER) : " r_worker.MAXCORESPERWORKER;
9	/* 2. Extraction du plafond de la mémoire vive allouée */
10	sessionProp.getSessOpt RESULT=r_mem / name="MEMORYSIZE";
11	PRINT "Plafond de mémoire vive allouée (MEMORYSIZE) : " r_mem.MEMORYSIZE;
12	/* 3. Vérification de la configuration physique via l'état K8s sous-jacent */
13	BUILTINS.serverStatus RESULT=STATUS;
14	PRINT "---";
15	PRINT "Rapport d'état matériel K8s par noeud CAS :";
16	for row in status.server;
17	print " > Noeud " row.node " (" row.role ") - Coeurs utilisables : " row.coreCount " \| RAM détectée : " row.memory;
18	END;
19	QUIT;</pre>

Exemples pour l'action getServOpt

Vérifier la Locale du serveur

Un exemple rapide pour savoir si votre serveur parle français ou anglais.

Récupérer et stocker la limite de mémoire

Cet exemple montre comment récupérer la valeur de l'option MAXTABLEMEM dans une variable CASL pour une utilisation ultérieure dans votre logique de programmation.

Conseil de l'Expert

Je tiens à souligner un point critique d'architecture propre à la version cloud-native : sous SAS Viya 4, il est impératif de distinguer les limites internes du moteur CAS des requests et limits définis dans vos manifestes Kubernetes. Configurer un paramètre MEMORYSIZE dans CAS sans l'aligner strictement avec les cgroups alloués au pod par le Kubelet vous expose à des arrêts brutaux par l'OOM-Killer (Out Of Memory) de Linux, rendant les mécanismes d'alerte et de débordement (spill) inopérants.

Points de Vigilance Techniques sur le Dimensionnement CAS

Cohérence Kubernetes-CAS : La valeur définie pour MEMORYSIZE doit toujours intégrer une marge de sécurité (overhead OS d'environ 10 à 15 %) par rapport à la limite mémoire matérielle configurée pour le pod du worker K8s.
Topologie MPP vs SMP : L'option MAXCORESPERWORKER est vitale dans une architecture distribuée (MPP) pour garantir une allocation homogène des threads sur chaque nœud, évitant ainsi un goulot d'étranglement réseau (network bottleneck) lors des opérations de shuffle.
Comportement du CAS_DISK_CACHE : Lorsque l'utilisation mémoire approche du plafond MEMORYSIZE, CAS force le déchargement des blocs en mémoire vers le disque. Vérifiez que la capacité IOPS de vos Persistent Volumes (PV) éphémères supporte cette charge.
Affinité CPU et NUMA Nodes : Dans les environnements K8s bare-metal, la valeur retournée par MAXCORES peut masquer la réalité matérielle. Veillez à ce que vos pods CAS respectent les limites NUMA via la configuration de la Topology Manager de Kubernetes.
Autoscaling Horizontal (HPA) et Licences : La surveillance de ces paramètres est indispensable lors de l'élasticité du cluster ; l'ajout dynamique de pods workers peut faire dépasser les seuils globaux MAXCORES autorisés par votre contrat de licence SAS.

Cette réponse vous a-t-elle aidé ?

Vos votes aident à améliorer notre base de connaissances.

Action CAS associée

configuration

getServOpt