Ubuntu-fr

l.rocchi

Problème de performance Fluent en partage de nœud CPU

Bonjour à tous,
Je me permets de vous solliciter pour un problème de performance avec ANSYS Fluent sur un cluster de calcul.
Je suis utilisatrice occasionnelle en HPC et je rencontre un problème qui semble lié au partage des nœuds CPU.
Étant peu expérimentée sur ces environnements, je suis un peu perdue pour identifier la source du problème et le résoudre.

Contexte :
•  Logiciel : ANSYS Fluent 2024R1
•  Calcul : Simulation CFD 3D RANS, maillage assez lourd (~8M de cellules), parallèle CPU.
•  Ressources : 64 cœurs (sur 128) par nœud, durée moyenne de 1,5 jour par job.

Problème :
Dès qu’un autre utilisateur partage mon nœud, le temps de calcul par itération explose (x5 à x10).
Tout redevient normal quand je me retrouve seule sur le nœud. : j’en déduis que c’est lié à la mémoire partagée, mais je ne sais pas comment le résoudre.

Solutions testées (sans grands succès) :
•  Limitation de la RAM : #SBATCH  --mem et #SBATCH --mem-per-cpu : aucun changement - le problème persiste dès que le nœud est partagé.
•  Privatisation du nœud : #SBATCH  --exclusive (64/128) ou réservation des 128 cœurs : fonctionne - mais gaspille les ressources (je n’ai besoin que de 64 cœurs) + temps d’attente très long (nécessité d’un nœud libre).
Sachant que j’ai pas mal de calculs je souhaiterais trouver une autre solution.

Je n’ai pas accès à la configuration détaillée des nœuds, mais je sais que la mémoire disponible par nœud est de 512 Go.

Existe-t-il une solution pour privatiser la RAM (ou les ressources associées) sans réserver un nœud entier ?
Comment limiter l’impact des autres utilisateurs sur mes performances sans saturer le cluster ?

Merci d’avance pour vos retours !

Majex

Re : Problème de performance Fluent en partage de nœud CPU

Bonjour à tous,
Je me permets de vous solliciter pour un problème de performance avec ANSYS Fluent sur un cluster de calcul.
Je suis utilisatrice occasionnelle en HPC et je rencontre un problème qui semble lié au partage des nœuds CPU.
Étant peu expérimentée sur ces environnements, je suis un peu perdue pour identifier la source du problème et le résoudre.

Contexte :
•  Logiciel : ANSYS Fluent 2024R1
•  Calcul : Simulation CFD 3D RANS, maillage assez lourd (~8M de cellules), parallèle CPU.
•  Ressources : 64 cœurs (sur 128) par nœud, durée moyenne de 1,5 jour par job.

Problème :
Dès qu’un autre utilisateur partage mon nœud, le temps de calcul par itération explose (x5 à x10).
Tout redevient normal quand je me retrouve seule sur le nœud. : j’en déduis que c’est lié à la mémoire partagée, mais je ne sais pas comment le résoudre.

Solutions testées (sans grands succès) :
•  Limitation de la RAM : #SBATCH  --mem et #SBATCH --mem-per-cpu : aucun changement - le problème persiste dès que le nœud est partagé.
•  Privatisation du nœud : #SBATCH  --exclusive (64/128) ou réservation des 128 cœurs : fonctionne - mais gaspille les ressources (je n’ai besoin que de 64 cœurs) + temps d’attente très long (nécessité d’un nœud libre).
Sachant que j’ai pas mal de calculs je souhaiterais trouver une autre solution.

Je n’ai pas accès à la configuration détaillée des nœuds, mais je sais que la mémoire disponible par nœud est de 512 Go.

Existe-t-il une solution pour privatiser la RAM (ou les ressources associées) sans réserver un nœud entier ?
Comment limiter l’impact des autres utilisateurs sur mes performances sans saturer le cluster ?

Merci d’avance pour vos retours !

Bonjour,
Le sujet date et je ne sais pas si tu as déjà pu régler le souci, mais je me permets de te répondre juste au cas où...

Ton ralentissement ressemble typiquement à un goulet d'étranglement lié à l'architecture NUMA du nœud. Sur de grosses machines à 128 cœurs, les processeurs sont divisés en plusieurs bancs physiques. Si SLURM éparpille tes 64 processus et ceux de l'autre utilisateur sur les mêmes bancs de RAM, les temps d'accès mémoire s'effondrent.

Puisque tu utilises SLURM avec #SBATCH, essaie de regarder du côté des directives d'affinité pour isoler tes calculs sur une moitié physique du nœud. Tu peux tester l'ajout d'options comme --distribution=block:block dans ton script, ou chercher comment forcer le "CPU binding" directement dans les paramètres de lancement d'ANSYS Fluent. J'espère avoir été utile.

Édit : D'ailleurs, si la syntaxe complexe des scripts SLURM ou les paramètres d'affinité NUMA te prennent trop la tête à configurer à la main, n'hésite pas à te faire aider par une IA pour générer ton fichier batch. J'ai testé suite à un petit guide lu récement sur l'accès gratuit aux modèles les plus avancés pour le code, et ça fait vraiment gagner un temps précieux pour scripter dans ce genre d'environnement Linux un peu lourd.

Dernière modification par Majex (Le 03/08/2026, à 03:07)

---

"L'homme est un loup pour l'homme, ce qui, vous en conviendrez, n'est pas très gentil pour le loup"