Diffusion sur RessourcesCBP du 2025-06-27

1. Migration Trixie avant la rentrée 2025 : nouvelle version à tester
2. Ollama disponible : un assistant IA dans votre terminal
3. Consommation énergétique CPU : 2 petits scripts pour en savoir plus
4. Accessibilité archives /projects et /local : pour récupérer ses data
5. Usage Visual Studio : se simplifier la tâche en respectant les autres

Si vous avez des questions, veuillez exploiter le formulaire https://www.cbp.ens-lyon.fr/doku.php?id=ressources:informatique:demande comme pour toute demande et à des fins de traçabilité : ceci n'est pas une option.

Comme tous les deux ans, les machines de CloudCBP (et ClusterCBP) changent de version majeure de distribution : Debian Trixie 13 remplace Debian Bookworm 12. Normalement, tous les logiciels intégrés et exploités cette dernière année ont été réintégrés. Il se peut que certains soient passées entre les mailles du tamis ! Des machines démarrées en Trixie (recherchez “trixie64nfs” dans la page CloudCBP, colonne SIDUS) vous permettent déjà de “rejouer” vos codes ou vos formations. La migration “totale” de CloudCBP vers cette distribution trixie est prévue pour, au plus tard, le 24 août prochain : il vous appartient donc de, dès à présent, l'évaluer et me remonter les anomalies.

De manière à permettre une certaine souveraineté et disposer d'assistants IA internes à l'ENS, Ollama est disponible sur toutes les machines du CBP. Cette application, en commande en ligne (également accessible par une API Python), vous permet de charger tous les modèles disponibles sur : https://ollama.com/search . Attention cependant : le choix de la machine permettant d'exploiter tel ou tel modèle est cardinal pour une usage intéractif. Il convient d'adapter le modèle exploité à la machine sollicitée : par exemple, exploiter une machine à GPU et disposer d'une mémoire sur la GPU supérieure à la taille du modèle est un prérequis souhaitable.

Plusieurs fois, il m'a été demandé quelle était la consommation électrique des équipements du CBP. Malheureusement, la diversité des machines et le manque de standardisation rendent la réponse presque impossible. De manière à toutefois offrir le maximum d'éléments, deux scripts exploitant les mécanismes RAPL des machines permettent d'en savoir un peu plus sur la consommation, notamment pendant l'exécution d'une tâche. Les commandes RaplWattQueue.sh et RaplJouleQueue.sh vous permettent d'avoir une idée de la consommation instantanée ou récupérer les compteurs énergétiques associés au CPU et parfois sa mémoire. Attention, ces données ne sont pas universelles sur tous les équipements de CloudCBP : les CPU trop vieux ou trop récents sont exclus, parfois des éléments sur la mémoire sont rapportés mais ce n'est pas universel. C'est cependant un appoint acceptable avec ce que peut fournir “nvidia-smi dmon” pour les GPU Nvidia.

Les archives quotidiennes (une “archive” est “l'état d'une information” dans le passé) sur les volumes “/local” et “/projects” sont accessibles depuis plusieurs mois : elles se trouvent dans la racine du volume, dans les dossiers /projects/.zfs/snapshot/YYYYMMDD-HHMM (au format “style” ISO 8601) ou /local/.zfs/snapshot/YYYYMMDD-HHMM . Vous pouvez donc récupérer les données que vous auriez négligemment supprimées. Ces archives, “état du passé” sont évidemment non modifiables. Elles sont purgées lorsque la pression sur l'espace disponible augmente. Donc plus le volume sera “occupé”, moins il reste d'archives.

Depuis plusieurs années, Visual Studio s'est imposé chez beaucoup comme le “système d'exploitation” des ressources. Il induit deux difficultés dans l'exploitation du CBP. La première est la charge de ses tâches “propres” exécutées sur la machine distante (sollicitée pour lancer ses calculs) ; cette charge n'est pas résiduelle, notamment en espace mémoire. La seconde est liée au caractère dissimulatoire de ce qui se passe sur la machine. Je rappelle que les machines de CloudCBP sont des machines d'expérimentation : la connaissance de ce qui se passe sur la machine, notamment en matière de consommation de ressources (CPU, GPU, mémoire, entrées/sorties disques ou réseau) pendant un traitement, reste cardinale pour une bonne utilisation (les commandes htop, dstat, nvtop, etc… sont très utiles). S'en désintéresser complètement implique souvent un usage inapproprié des ressources : sur-exploitation ou sous-exploitation des équipements, frustration entre utilisatrices concurrentes, etc. Ainsi, l'utilisation de Visual Studio ne vous affranchit pas d'une exploitation raisonnée des ressources.