vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2021-10-07T16:17:55+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3154Récupérer des infos des pré-process : mécanisme2021-10-07T16:17:55+02:00Mathieu GiraudRécupérer des infos des pré-process : mécanismeVoir #2875 et #2247.
Chaque ~"server-pre-process" pourrait générer un `.json` comme le `.vidjil` (mais sans section `clones` ni ...).
Avec en particulier des warnings #2247 et des variables de qualité #2875.Voir #2875 et #2247.
Chaque ~"server-pre-process" pourrait générer un `.json` comme le `.vidjil` (mais sans section `clones` ni ...).
Avec en particulier des warnings #2247 et des variables de qualité #2875.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4633Connaître le nom des fichiers uploadés, avant le pre-process2021-01-13T15:09:06+01:00Mathieu GiraudConnaître le nom des fichiers uploadés, avant le pre-processDepuis #3154 :
> @mikael-s : "ce qui sera possible avec !691"Depuis #3154 :
> @mikael-s : "ce qui sera possible avec !691"https://gitlab.inria.fr/vidjil/vidjil/-/issues/3493Stats et icône de relance2024-02-14T10:49:13+01:00Mathieu GiraudStats et icône de relanceÀ terme, il faudra
- si les stats sont déjà présents, ne pas la mettre
- et, à l'appui, avoir un retour utilisateur, idéalement `RUNNING` (peut-être sous forme d'icône #3324)
En attendant, il apparait sage de la mettre en commentair...À terme, il faudra
- si les stats sont déjà présents, ne pas la mettre
- et, à l'appui, avoir un retour utilisateur, idéalement `RUNNING` (peut-être sous forme d'icône #3324)
En attendant, il apparait sage de la mettre en commentaire.
Vérifier aussi qu'elle fait un ~"server\-fuse" en sortie.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2618Status : FUSING en plus de RUNNING ?2018-02-16T15:56:14+01:00Mathieu GiraudStatus : FUSING en plus de RUNNING ?Discussion lors de l'audio à propos de #2605/#2606.Discussion lors de l'audio à propos de #2605/#2606.Ryan HerbertRyan Herberthttps://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/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/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...)