Un utilisateur me remonte un souci sur l’upload d’une séquence sur notre instance.
L’upload a été effectué il y a deux jours (58000 photos) mais le statut est encore en '“floutage en cours”.
Pour information ce même utilisateur a déjà uploadé une séquence à 54000 photos avant sans souci.
Si je cherche de mon côté le statut de cette séquence, à priori certaines photos sont en “attente”
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━┓
┃ Upload Set ┃ Published ┃ Total ┃ Ready ┃ Waiting ┃ Preparing ┃ Broken ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━┩
│ toto │ Waiting for collections to be created │ 58903 │ 58826 │ 77 │ 0 │ 0 │
Comment puis-je affiner mon diagnostic ? Avant de demander à l’utilisateur de retenter un upload, étant donné la volumétrie, je préfère voir si je peux débloquer celui-ci.
ouch, oui on manque beaucoup d’outils pour les administrateurs/administratrices d’instances
pour creuser, ce que je fais :
select * from job_history where upload_set_id = '<id de l uploadset>';
Ca va te donner si il y a eu une erreur sur l’upload.
Pareil, tu peux afficher les erreurs de floutage d’une photo avec:
select * from job_history where picture_id = '<id d une image>';
Tu peux aussi faire un
update upload_sets set completed = true where id = '<id de l uploadset>';
pour redemander le traitement (dispatch) de l’uploadset (la fonction quand toutes les photos ont été floutées (ou au moins on a essayé) pour créer les collections et calculer les géométries).
tu peux aussi redemander le floutage des photos en erreur :
insert into job_queue (picture_id, task) select id, 'prepare' from pictures where preparing_status = 'broken';
Le floutage est réessayé en cas d’erreur, mais ca peut débloquer les choses en cas de soucis répétés sur l’api de floutage.
Il va falloir qu’on priorise le développement d’interface d’admin maintenant qu’il y a plus de gens qui ont leurs instances
Après avoir fouillé un peu, en réalité c’est plusieurs séquences qui sont bloquées.
Peut-être dû au nombre de photos, on parle de séquences qui varient entre 25000 et 60000 photos et qui ont probablement été envoyées d’un bloc.
Le souci c’est que le re-floutage des photos en erreur ne résous rien pour l’instant, et pour cause, ma job_queue contient pas loins de 20 000 lignes. Cela explique pourquoi des séquences n’ont pas de photos en erreur mais sont toujours en attente car il en reste quelques unes en “préparation”.
Puis-je (ou dois-je) prioriser certains jobs ? Ne serait-il pas mieux de tout “annuler” et redemander à l’utilisateur de ré-uploader bloc par bloc ? Et si oui comment ?
la taille de la queue diminue ? Vous avez combien de workers pour préparer les photos ? et quelle API de floutage utilisez vous ?
Pour le moment on n’a pas trop de moyens industriels pour prioriser des jobs, une maniere artisanal est de truquer le champ nb_errors en base pour dé prioriser les jobs, mais les 20 000 photos devraient avoir été traitées depuis hier normalement si votre instance est dimensionnée pour vos besoins.
Nous avons 5 workers déployés et nous utilisons l’API de floutage de openstreetmap.
En effet, à présent la queue est vide et les séquences sont bien uploadées.
Je n’en ai pas vu mais y a t-il des recommandations justement sur le nombre de worker à déployer suivant la taille des séquences ?
Sur l’instance OSM, je crois en avoir mis 12 et bien sûr ça dépend du nombre de coeurs de CPU disponibles sur la machine/VM/conteneur ainsi que la RAM car chaque worker va avoir besoin de RAM.
Waiting for collections to be created │ 58903 │ 58826 │ 77 │ 0 │ 0 │
