vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2021-11-22T13:51:54+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2359Limiter la mémoire allouée aux jobs lancés via les workers2021-11-22T13:51:54+01:00Mathieu GiraudLimiter la mémoire allouée aux jobs lancés via les workersEn complément de #2349, on pourrait limiter la quantité de mémoire par worker ou sur tous les workers. On aimerait ainsi que, même dans des cas non prévus, le serveur réponde toujours même si un process fait n'importe quoi.
Voir http://...En complément de #2349, on pourrait limiter la quantité de mémoire par worker ou sur tous les workers. On aimerait ainsi que, même dans des cas non prévus, le serveur réponde toujours même si un process fait n'importe quoi.
Voir http://coldattic.info/shvedsky/pro/blogs/a-foo-walks-into-a-bar/posts/40, qui discute longuement certaines possibilités.
(On pourrait d'ailleurs avoir une solution non universelle, et par exemple protéger MiXCR par un `ulimit` si cela fonctionne.)https://gitlab.inria.fr/vidjil/vidjil/-/issues/2349Ne pas lancer plusieurs process gourmands en mémoire en même temps2020-01-21T17:34:41+01:00Mikaël SalsonNe pas lancer plusieurs process gourmands en mémoire en même tempsMiXCR est gourmand en mémoire et si plusieurs instances sont lancées en même temps cela peut mettre la VM en carafe (cf. vdj#396). Peut-on laisser les jobs MiXCR QUEUED tant que d'autres jobs MiXCR sont en train de tourner ?
@RyanHerb...MiXCR est gourmand en mémoire et si plusieurs instances sont lancées en même temps cela peut mettre la VM en carafe (cf. vdj#396). Peut-on laisser les jobs MiXCR QUEUED tant que d'autres jobs MiXCR sont en train de tourner ?
@RyanHerb penses-tu que cela soit possible ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2320Quand le scheduler ne fonctionne pas, les jobs en FAILED n'apparaissent pas d...2024-01-19T18:30:34+01:00Mikaël SalsonQuand le scheduler ne fonctionne pas, les jobs en FAILED n'apparaissent pas dans le log debugAurélie nous prévient que certains jobs ont échoué mais rien n'apparaît dans `vidjil-debug.log`
cc @magiraud @RyanHerb @flothoniAurélie nous prévient que certains jobs ont échoué mais rien n'apparaît dans `vidjil-debug.log`
cc @magiraud @RyanHerb @flothonihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2213Killer les processus en timeout2023-01-09T11:48:15+01:00Mikaël SalsonKiller les processus en timeoutÀ l'heure actuelle, quatre processus Vidjil tournent sur le serveur, certains depuis plus d'un jour (je soupçonne très fortement un bug dans l'algo, mais ce n'est pas le sujet), mais les quatre workers sont libres. La raison : on libère ...À l'heure actuelle, quatre processus Vidjil tournent sur le serveur, certains depuis plus d'un jour (je soupçonne très fortement un bug dans l'algo, mais ce n'est pas le sujet), mais les quatre workers sont libres. La raison : on libère le worker après le timeout (ou il se libère tout seul, je ne sais pas), mais le processus n'est pas achevé pour autant.
La méthode à adopter peut avoir un lien avec ce qui est discuté dans #2165
cc @magiraud @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2165Killer un processus qui tourne sur un fichier qu'on écrase ?2017-03-02T18:29:36+01:00Mikaël SalsonKiller un processus qui tourne sur un fichier qu'on écrase ?Suite à #2103, on supprime bien les résultats pré-existants lorsqu'on réuploade un fichier mais ça ne s'applique pas aux jobs en courts sur les fichiers qu'on écrase.
@mikael-s
> A-t-on la possibilité de dire aux jobs de s'arrêter ? Tr...Suite à #2103, on supprime bien les résultats pré-existants lorsqu'on réuploade un fichier mais ça ne s'applique pas aux jobs en courts sur les fichiers qu'on écrase.
@mikael-s
> A-t-on la possibilité de dire aux jobs de s'arrêter ? Trop complexe ?
@RyanHerb
> […]
On pourrait donc théoriquement kill le worker si on a son pid, supprimer la tâche et lancer un nouveau worker.
Est-ce raisonnable de killer le worker ? On pourrait se trouver dans une situation ou entre le moment où on lance l'upload et le moment où on lance le kill c'est un autre processus qui s'est mis à tourner. On killerait donc le mauvais processus. Ok, ça devrait arriver très rarement (si ça arrive), mais le risque n'est pas nul.
Prend-on ce risque ? D'autres solutions ?
cc @flothoni @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2055Mise à jour de web2py et nouvelles fonctionnalités2020-01-22T13:56:36+01:00Mathieu GiraudMise à jour de web2py et nouvelles fonctionnalitésSuite à vidjil/vdj#299, web2py est passé de 2.9.9 à 2.14.6, avec plus de 18 mois de nouveaux développements. Mais on avait déjà, sur d'autres serveurs, des web2py plus à jour. Devrait-on avoir un mécanisme pour garantir que web2py ne res...Suite à vidjil/vdj#299, web2py est passé de 2.9.9 à 2.14.6, avec plus de 18 mois de nouveaux développements. Mais on avait déjà, sur d'autres serveurs, des web2py plus à jour. Devrait-on avoir un mécanisme pour garantir que web2py ne reste pas trop longtemps dans une vieille version ?
Les nouveautés : https://github.com/web2py/web2py/blob/master/CHANGELOG
Il y a deux fois "Improved scheduler", à voir si cela a changé quelque chose:
Parmi les prochains points prévus :
- enfin python 3 (voir #1345)
- scheduler new feature: you can now specify intervals with cron
- gluon/* removed from sys.path. Applications relying on statements like e.g. "from storage import Storage" will need to be rewritten with "from gluon.storage import Storage"
- tests can only be run with the usual web2py.py --run_system_tests OR with python -m unittest -v gluon.tests on the root dir
@mikael-s @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2053Des tâches restent en STOPPED, pas toutes2017-02-02T11:35:22+01:00Mikaël SalsonDes tâches restent en STOPPED, pas toutesVu avec @RyanHerb : lorsqu'un preprocess est lancé et non terminé on peut lancer des jobs, qui sont mis en STOPPED (dans la fonction `schedule_run` de [task.py](server/web2py/applications/vidjil/models.task.py)) :
```python
if db.se...Vu avec @RyanHerb : lorsqu'un preprocess est lancé et non terminé on peut lancer des jobs, qui sont mis en STOPPED (dans la fonction `schedule_run` de [task.py](server/web2py/applications/vidjil/models.task.py)) :
```python
if db.sequence_file[id_sequence].pre_process_flag == "WAIT" or db.sequence_file[id_sequence].pre_process_flag == "RUN" :
db.scheduler_task[task.id] = dict(status ="STOPPED")
```
Lorsque le pre-process est terminé, on récupère les jobs en STOPPED pour les relancer.
```python
#resume STOPPED task for this sequence file
stopped_task = db(
(db.results_file.sequence_file_id == sequence_file_id)
& (db.results_file.scheduler_task_id == db.scheduler_task.id)
& (db.scheduler_task.status == "STOPPED")
).select()
for row in stopped_task :
db.scheduler_task[row.scheduler_task.id] = dict(status = "QUEUED")
```
Sauf que ça ne semble pas fonctionner pour tous. Certains restant en STOPPED.
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1950Trouver une autre méthode de scheduling, indépendante de web2py2022-06-20T11:59:42+02:00Vidjil TeamTrouver une autre méthode de scheduling, indépendante de web2py(Discuté lors de la Rando 2016)
Un scheduler idéal devrait pouvoir avoir :
1) des priorités fines (petits jobs passent devant gros jobs) (et aussi users Platinium :-)
2) une suspension de tâches
3) une assignation fine de certains (gr...(Discuté lors de la Rando 2016)
Un scheduler idéal devrait pouvoir avoir :
1) des priorités fines (petits jobs passent devant gros jobs) (et aussi users Platinium :-)
2) une suspension de tâches
3) une assignation fine de certains (groupes de) workers à certaines tâches
2) ou 3) permettrait de lancer des choses annexes et rapides (type FineSegmenter ou compare patients ou ...) même si des gros Vidjil (ou autres) tournent
Enfin, penser tout cela dans le cadre d'un "noeud de calcul", possiblement indépendant du serveur web. Le serveur de calcul ne reçoit que des lignes de commande à exécuter et à accès aux fichiers nécessaires par un montage.
Rien d'urgent, à réfléchir posément dans les prochains mois.
***
Task spooler: http://vicerveza.homeunix.net/~viric/soft/ts/ présente les fonctionnalités majeures que nous cherchons (tâches interdépendantes, changement d'ordre dans la file, etc), mais n'a pas d'API pour s'en servir en réseau.
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1930Tout ce qui est dans task.py devrait être lancé par un autre utilisateur2022-06-20T18:11:04+02:00Vidjil TeamTout ce qui est dans task.py devrait être lancé par un autre utilisateurDiscussion à l'instant: dans task.py, il peut y avoir des choses méchantes de faites, que ce soit via les configs ou les pre-process.
On pourrait échapper des choses, faire un chroot...
Le plus simple semble de faire tous les lancements...Discussion à l'instant: dans task.py, il peut y avoir des choses méchantes de faites, que ce soit via les configs ou les pre-process.
On pourrait échapper des choses, faire un chroot...
Le plus simple semble de faire tous les lancements par un *autre utilisateur*, qui n'aurait des droits en écriture que sur tmp/. Cela devrait passer tout seul pour vidjil / mixcr (le fichier de résultat étant copié), à voir pour les pre-process.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1818Priorités pour les tâches2022-03-09T11:24:49+01:00Vidjil TeamPriorités pour les tâchesLes fichiers de Sarah (4 Go RNA Seq) demandent souvent autour de 2h chacun (x 2, R1+R2)
J’ai par exemple relancé il y a quelques jours 16 jobs… et cela fait donc 32h / 3workers = 11 heures.
C’est dommage de bloquer tout le monde pendant ...Les fichiers de Sarah (4 Go RNA Seq) demandent souvent autour de 2h chacun (x 2, R1+R2)
J’ai par exemple relancé il y a quelques jours 16 jobs… et cela fait donc 32h / 3workers = 11 heures.
C’est dommage de bloquer tout le monde pendant ce temps.
Idéalement, il faudrait une priorité inverse au temps attendu de calcul (mais j’ai l’impression qu’il n’y a pas de priorités explicites dans web2py…)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1817Indicateur de progression / tâches en cours pour ce qui est lancé par task.py2019-02-28T12:40:31+01:00Vidjil TeamIndicateur de progression / tâches en cours pour ce qui est lancé par task.pyPour les grosse tâches qui durent longtemps (10 min → 2/3 heures), ce serait bien d’avoir un RUNNING (40%).
Voir par exemple http://web2py.com/books/default/chapter/29/04/the-core#Reporting-progress-percentages dans la doc web2py avec `s...Pour les grosse tâches qui durent longtemps (10 min → 2/3 heures), ce serait bien d’avoir un RUNNING (40%).
Voir par exemple http://web2py.com/books/default/chapter/29/04/the-core#Reporting-progress-percentages dans la doc web2py avec `sync_output`.
Mais bof, suppose de perdre la stdout… Ou bien pas de !clear, mais un parsing maison de la stdout, quitte à faire évoluer cette stdout du C++ ?
Et ensuite, c’est difficile de prédire le temps total. Peut-être, pour Vidjil, plutôt `RUNNING 1 (40%)` puis `RUNNING 2 (30%)` ou `CLUSTERING` ou autre chose.
(Et cela dépend du soft, MiXCR ce sera autre chose...)
https://gitlab.inria.fr/vidjil/vidjil/-/issues/1520Liste des sets : info si les calculs sont finis ou pas2019-02-28T12:39:27+01:00Vidjil TeamListe des sets : info si les calculs sont finis ou pasLorsqu'on a lancé beaucoup de calculs (disons sur 70 patients par exemple), on aimerait savoir si c'est fini ou pas, ou au moins quels patients on pourrait consulter. Une manière simple de visualiser cela serait d'avoir un petit indicate...Lorsqu'on a lancé beaucoup de calculs (disons sur 70 patients par exemple), on aimerait savoir si c'est fini ou pas, ou au moins quels patients on pourrait consulter. Une manière simple de visualiser cela serait d'avoir un petit indicateur dans la liste des configs de chaque patient lorsque la config est en train de tourner.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1519Lancer une config sur beaucoup de patients/fichiers2023-06-29T10:28:18+02:00Vidjil TeamLancer une config sur beaucoup de patients/fichiersIl arrive qu'on veuille lancer (ou relancer) une config sur beaucoup de patients / fichiers. Avec le patient précédent/suivant, c'est plus facile, mais cela reste très manuel :)
Il faudrait une page où on voit tous les fichiers (celle d...Il arrive qu'on veuille lancer (ou relancer) une config sur beaucoup de patients / fichiers. Avec le patient précédent/suivant, c'est plus facile, mais cela reste très manuel :)
Il faudrait une page où on voit tous les fichiers (celle de "compare patients" par exemple) ou bien tous les patients, on sélectionne ceux qu'on veut, et on lance une config. Peut-être qu'une confirmation serait la bienvenue avant de lancer des centaines de Vidjil :)
***
@nobody