Bonjour,
Depuis hier, mon programme s'arrête brusquement à cause, semble-t-il, d'un manque d'espace. Pour les mêmes calculs, j'ai eu les messages d'erreur suivant :
Error in pdf(#####) : cannot open file '#####'
Error in file(file, ifelse(append, "a", "w")) : cannot open the connection
En voulant débugger, dans une session Rstudio, j'ai obtenu le message suivant :
Warning message:
In dir.create(qc_output_dir, recursive = TRUE) :
cannot create dir '#####', reason 'No space left on device'
Or, tous ces calculs ont été lancés avec le même projet (myestrom_visium) pour lequel il reste de la place. Lorsque je me connecte en ssh au serveur, il est indiqué que 306 GB sont utilisés sur 350. En utilisant la commande 'du -sh' sur ce répertoire, j'obtiens 307G. Il y a donc bien de l'espace libre.
Le problème viendrait-il de mon compte ? Ou est-il plus général lié au serveur ?
Je vous remercie par avance pour vos réponses.
Christophe
Bonjour,
En effet, je ne vois pas de saturation de vos espaces (home ou projet).
- Pouvez-vous nous donner plus d'information (script, logs complets, n°job, etc) pour vérifier ce qui se passe ?
- P'têtre que votre traitement se fait sur un autre espace (
/tmp par exemple) ?
- Ou que votre job créé de nombreux fichiers temporaires (et donc sature l'espace) ?
Bonjour,
Voici les éléments que je peux vous fournir.
Les IDs des jobs qui ont planté auxquels je faisais référence dans mon premier message sont les suivants : 41699417, 41777961 et 41777182. Le dernier est une session Rstudio. Pour les 2 premiers, vous trouverez les logs (fichiers .out et .err) dans le dossier suivant : /shared/projects/myestrom_visium/analyses/10-Clustering/.
Tous ces calculs exécutait le script /shared/projects/myestrom_visium/analyses/10-Clustering/src/10-integration_clustering_markers-Seurat_v4.R. Il s'agit d'un script que j'exécute en routine depuis quelques semaines et pour lequel je n'avais pas rencontré ce genre de problèmes jusqu'à maintenant.
Enfin, je ne suis pas en mesure de vous dire à quel point ce script génère des fichiers temporaires et à quel endroit.
Christophe
Malheureusement, je ne vois pas ce qui coince.
Avez-vous toujours des erreurs si vous relancez ?
Je vous remercie d'avoir consacré du temps au problème que je rencontre.
Je vais relancer à nouveau mes calculs et vous tiendrai au courant de leur issue. Il m'est déjà arrivé en effet d'avoir des calculs qui avaient généré une erreur et de les avoir relancés à l'identique (même script, mêmes données en entrée) sans que cela crée d'erreur.
Christophe
Bonjour,
J'ai relancé mes calculs à l'identique par rapport aux précédentes tentatives (même script, mêmes données) et, cette fois-ci, ils ont bien pu aller à leur terme.
Il me semble effectivement que la piste du répertoire temporaire saturé probable pour expliquer l'erreur rencontrée lors des 2 premières tentatives. Dans le but d'essayer de comprendre ce qui s'est passé, j'ai vu dans le post suivant : OSError: [Errno 28] No space left on device + augmentation stockage - #9 par hugo-lefeuvre que le problème pourrait venir du dossier /tmp du noeud sur lequel tournent les calculs. J'ai donc les questions suivantes :
- lorsqu'on fait la commande 'df -h /tmp/' pour voir l'espace libre, de quel dossier /tmp s'agit-il ?
- comment connaître l'espace libre du dossier /tmp d'un noeud en particulier ?
Christophe
Merci pour les infos et le retour.
En effet, cela provient probablement d'une saturation de /tmp ou d'un problème occasionnel sur un noeud de calcul (ça arrive).
/tmp sur l'IFB corresponds à un disque local (sur le serveur).
Le plus simple pour visualiser l'espace me semble être un df -h /tmp.
Attention toutefois, si /tmp est peu utlisé au moment de lancer le job, il peut se remplir au fur et à mesure.
A noter aussi que, suivant les serveurs, la taille de /tmp peut varier (de qques Go à 2To).