Demande d'accès à bigmem

Bonjour,
Serait-il possible d'obtenir un accès à la partition bigmem pour le projet tcrrep_aid notemment pour des gros alignements multiples de séquences ? Je n'ai jamais essayé de demander plus de nodes sur la partition fast mais à priori mon script ne supporte pas la distribution sur plusieurs nodes sauf si cela se fait automatiquement.

Merci
Martin Pezous

Bonjour Martin,

Je ne suis pas sûr que ce soit la mémoire qui vous pose problème actuellement.
En effet, je n'ai pas vu de jobs qui saturent la mémoire (avec typiquement un message d'erreur de type "out of memory").
Par exemple, un de vos dernier job (joib=35495590), n'utilise que 44Go (22%) de la mémoire allouée (200Go).
Une fois le job terminé, on peut voir les ressources utilisé via l'utilitaire seff:

$ seff 35495590
Job ID: 35495590
Cluster: core
User/Group: mpezous/mpezous
State: FAILED (exit code 1)
Nodes: 1
Cores per node: 20
CPU Utilized: 00:14:56
CPU Efficiency: 5.16% of 04:49:40 core-walltime
Job Wall-clock time: 00:14:29
Memory Utilized: 44.18 GB
Memory Efficiency: 22.09% of 200.00 GB

Dans ce cas précis, ce n'est pas la mémoire qui semble poser problème. Cela semble plutôt venir du code/programme qui échoue (pour je ne sais quelle raison).

Pouvez-vous vérifier ?

Merci pour votre réponse rapide.
Voilà l'erreur:
"An irrecoverable exception occurred. R is aborting now ...
/var/spool/slurm/slurmd/job35474629/slurm_script: line 7: 8893 Segmentation fault (core dumped)"

En effet, le job n'a utilisé que 36 Gb de RAM... je penserai à vérifier la prochaine fois !

Un "Segmentation fault" est bien une erreur du programme mais qui n'est pas dû à une saturation mémoire. C'est souvent un bug dans le programme ou dans une donnée d'entrée qui "bug" le programme.
Ce n'est pas toujours facile à dénicher... Il faut tester/essayer pour comprendre d'où vient le problème (ou utiliser des outils de debug avancé).

Bonjour,
Je reviens vers vous pour vous demander un accès à bigmem pour le projet tcrrep_aid (cette fois c'est justifié). Ça serait pour un calcul sur un peu plus d'un jour avec plus de 3000 GB de RAM. Par ailleurs j'ai fait une observation qui avait déjà été rapportée sur ce forum (je ne sais plus trop ou): voilà le seff d'un job qui a "dépassé" sa mémoire max:

Use of uninitialized value $FindBin::Bin in concatenation (.) or string at /usr/local/bin/seff line 11.
Name "FindBin::Bin" used only once: possible typo at /usr/local/bin/seff line 11, <DATA> line 602.
Job ID: 36632590
Cluster: core
User/Group: mpezous/mpezous
State: CANCELLED (exit code 0)
Nodes: 1
Cores per node: 100
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 60-09:56:40 core-walltime
Job Wall-clock time: 14:29:58
Memory Utilized: 1.19 TB
Memory Efficiency: 110.70% of 1.07 TB

Vous pouvez voir Memory efficiency > 100% c'est étrange
Dernière question, lorsque je souhaite utiliser "beaucoup" de RAM, dois-je demander beaucoup de cpu ou puis-je simplement demander beaucoup de RAM pour peu de cpu ?

Je vous remercie

mpezous

Bonjour,

Je viens de vous donner accès à la partition bigmem (pensez à bien spécifier la partition avec --partition=bigmem et votre projet avec --account=<projet>).

Vous pouvez demander "beaucoup de RAM" et peu de CPU.
Mais en général c'est un peu lié. Par défaut (si la mémoire n'est pas indiqué) nous allouons 2Go/CPU.
Il peut arriver aussi qu'on utilise toute la mémoire d'une machine, il ne peut alors y avoir d'autre jobs, et du coup autant utiliser tout les CPU.

Pour le retour de seff, je pense que l'usage CPU renvoyé n'est pas bon (probablement à cause du job Failed). Il y a une marge qui fait que l'on peut dépasser légèrement la mémoire alloué.Je suis en revanche étonné du retour "Failed" puisqu'on aurait dû avoir un "Out-Of-Memory". On essaie de regarder pourquoi.

Je vous remercie.