L’accounting sur Olympe

Les algorithmes de calcul de la consommation suivant les ressources que vous utilisez.

Article mis en ligne le 22 juin 2018
dernière modification le 6 novembre 2018
logo imprimer

Pour rappel Olympe est un Cluster qui interconnecte des noeuds de calcul. Chaque noeud d’Olympe dispose de 36 cpu, certains noeuds disposent en plus des 36 cpu, 4 cartes accélératrices GPU.

Plusieurs cas de figure se présentent en fonction de votre réservation totale : de 1 à 18 cœurs, supérieure à 18 cœurs, beaucoup de mémoire, utilisation d’un ou plusieurs GPUs.

Accounting pour la réservation de plus de 18 cœurs

Pour une réservation de plus de 18 cœurs, les nœuds sont attribués dans leur intégralité (i.e les 36 cœurs de chaque nœud réservé sont réservés) → partition exclusive.
Tout nœud réservé sur la (partition exclusive) est comptabilisé de la manière suivante :

(nombre de nœuds réservés) * (36 cœurs) * (temps de réservation effectivement utilisé)

Accounting pour la réservation de 18 cœurs ou moins

Pour une réservation de moins de 18 cœurs, le nœud est partagé entre plusieurs utilisateurs → partition shared QOS mono.
Tout nœud réservé sur la partition shared est comptabilisé de la manière suivante :

(nombre de cœurs réservés) * (temps de réservation effectivement utilisé)

Accounting pour la réservation de grands besoins mémoire (nœuds mesca)

Pour une réservation sur l’un des deux nœuds mesca (nœud grande capacité mémoire), le nœud est partagé entre plusieurs utilisateurs .

Tout job sur la partition mesca est comptabilisé de la manière suivante :

(nombre de cœurs réservés) * (temps de réservation effectivement utilisé)

Accounting pour la réservation d’une ou plusieurs cartes accélératrices GPU (nœuds Volta : CPU+cartes accélératrices GPU )

Pour une réservation de moins de 18 cœurs, et de moins de 2 cartes accélératrices GPU le nœud est partagé entre plusieurs utilisateurs partition volta QOS voltam.

Dans ce cas de figure les ressources sont comptabilisées de la manière suivante :

((nombre de coeurs réservés) + (nombre de GPUs)*(33) )* (temps de réservation effectivement utilisé)

Le coefficient 33 est le coefficient de conversion des heures GPU en heures cpu normalisées

Pour une réservation de plus de 18 cœurs, et de plus de 2 cartes accélératrices GPU le ou les nœuds sont attribués dans leur intégralité (i.e les 36 cœurs de chaque nœud réservé sont réservés, ainsi que les 4 cartes GPU et les 380 Go de mémoire) partition volta QOS volta.

Dans ce cas de figure les ressources sont comptabilisées de la manière suivante :

(nombre de nœuds réservés) *( (36 cœurs) + (4 GPUs)*(33)) * (temps de réservation effectivement utilisé)

Exemple CPU uniquement :

Je lance un job sur 2 nœuds, en lançant 36 tâches par nœud. Mon job met 15h à tourner.
L’en-tête de mon script SLURM ressemblera à quelque chose comme :

Il me sera décompté (2 nœuds) * (36 cpus) * (15 h) = 1080 h_cpus
Pour rappel : 36 coeurs de calculs par noeuds d’Olympe.

Exemple CPU uniquement, mode dépeuplé :

Je lance un job sur 2 nœuds en dépeuplé, en lançant 32 tâches par nœud. Mon job met 15h à tourner.
L’en-tête de mon script SLURM ressemblera à quelque chose comme :

Il me sera décompté (2 nœuds) * (36 cpus) * (15 h) = 1080 h_cpus
Pour rappel : 36 coeurs de calculs par noeuds d’Olympe.

Exemple CPU et carte accélératrice GPU :

Je lance un job utilisant 4 cpu et un GPU. Mon job met 15h à tourner.
L’en-tête de mon script SLURM ressemblera à quelque chose comme :

Il me sera décompté ((4 cpus)+(1 GPU)*(33)) * (15 h) = 555 h_cpus

Un job n’est comptabilisé que lorsqu’il est terminé. En cas de dépassement de quota :
- aucun job ne peut plus être soumis au gestionnaire de batch,
- les jobs en attente sont supprimés,
- les jobs en cours continuent leur exécution.




Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.87.86
Version Escal-V4 disponible pour SPIP3.2 Hébergeur : INP Toulouse