Bonjour
j'ai un nouveau type d'erreur qui est apparu. J'utilise snakemake pour faire tourner une suite de règles une à une. Certaines règles soumettent 300 jobs qui écrivent deux fichiers de sortis.
Depuis cet été, tout fonctionnait parfaitement, mais depuis hier j'ai un type d'erreur OSError: [Errno 16] Device or resource busy. Peut être lié à ces accès I/O multiples simultanés.
Avez vous des conseils pour les éviter s'il vous plait?
Merci encore pour tout votre boulot en tout cas !
C.
Bonjour Camille,
Cette erreur est malheureusement connu (lié à un problème de compatibilité entre le Kernel Linux utilisé et notre système de stockage). En cas d'I/O importants, les tâches échouent avec l'erreur OSError: [Errno 16] Device or resource busy.
Nous travaillons dessus mais n'avons pas encore mis en place de solution finale.
Je ne peux que vous inviter à lancer moins de jobs simultanément et à relancer les jobs en erreur.
En parallèle, il est d'ores et déjà prévu une évolution du stockage avec une augmentation de capacité et de meilleur performances (et donc plus d'I/O). Mais tout ça prends du temps.
Désolé du désagrément.
Je comprends, on a déjà une chance énorme de profiter d'un tel service gratuitement et dois avouer que je contribue énormément à une forme d'utilisation abusive.
Vais adapter mes pratiques en effet.
Question bête, est-ce que les connexions entre programmes par un pipe contribuent ou c'est uniquement les écritures/lectures de fichiers?
Si on a un code python qui génère un tableau de 1,000 lignes par exemple, est-ce qu'écrire le tableau en une fois en fin d'exécution au lieu d'écrire 1,000 fois une ligne pendant le processus (sur 10minutes) réduirait l'occurrence de ce type de bug?
Merci encore,
Camille
Merci Camille pour ce retour.
est-ce que les connexions entre programmes par un pipe contribuent ou c'est uniquement les écritures/lectures de fichiers?
Normalement non. Les pipes peuvent être vu comme un I/O, mais pas sur le système de fichier partagé (/shared/projects, /home, etc). Donc cela ne devrait pas être lié à notre problème.
Si on a un code python qui génère un tableau de 1,000 lignes par exemple, est-ce qu'écrire le tableau en une fois en fin d'exécution au lieu d'écrire 1,000 fois une ligne pendant le processus (sur 10minutes) réduirait l'occurrence de ce type de bug?
C'est possible en effet, mais je n'en suis pas sûr. 100 lignes/minutes c'est pas énorme non plus.
J'aurais tendance à écrire le fichier une fois le traitement terminé (ou à construire le fichier dans /tmp puis le déplacer). A tester.
Bonne fin de journée
Bonjour Camille,
Je dis peut-être une bêtise, mais je pense que Python gère un "buffer" pour écrire les lignes dans le fichier cible. A moins d'utiliser les fonctionnalités de "flush" et "fsync", le fait de changer le nombre de ligne n'aura pas beaucoup d'impact sur le nombre d’écriture disque.
En plus des idées proposer par David, une autre piste que vous pouvez essayer, c'est de faire explicitement et systématiquement le "close" du "file descriptor" ouvert dés que vous avez fini d’écrire le fichier. Sinon python va probablement essayer de fermer tout ceux qui sont restés ouvert en même temps lors du passage du "garbage collector", ce qui peux faire beaucoup d’écriture disque au même moment.
Bonne soirée
