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.
Entendu, et est-ce qu’il y a un moyen pour monitorer la charge des workers ?
Ma VM ne sature à aucun moment (4 CPU et 4Go de RAM), mais je me retrouve confronté au même problème d’il y a quelques temps, un utilisateur a envoyé plusieurs séquences lourdes d’un coup.
Je me retrouve avec au moins une bonne centaine de milliers de photos en traitement et ça dépile assez lentement (par exemple là j’ai 40 000 images traitées en 24 heures). Ces photos sont en très haute résolution, mais est-ce un délai de traitement “normal” ?
Ou à minima l’idéal serait à la rigueur de prioriser les jobs pour que le traitement se fasse séquence par séquence. Là on se retrouve avec un envoi massif et un début de publications de séquences quelques jours après.
on manque d’outillage la dessus, il va falloir qu’on travaille sur ca, nous on monitore la taille de la file d’attente (select count(*) from job_queue).
On garde en base de donnée ce qu’il faut pour suivre, mais on n’a pas de dashboard intégré pour le moment. Chaque job de préparation de photo est tracé dans la table job_history, avec la tache, l’heure de début/fin et l’éventuelle de fin, si tu veux faire des stats de durée de traitement.
4CPU/4G de ram et 5 workers, ca ne me semble pas beaucoup pour traiter des gros volumes de photo haute résolution. Tu peux aussi essayer d’augmenter le nombre de workers, vu que pour les photos, ils attendent pas mal l’api de floutage sans utiliser le CPU (qu’ils utilisent ensuite pour découper la photo, et calculer des photos dérivées).
Pour la priorisation, pour le moment c’est premier arrivé premier servi, et on est obligé d’attendre d’avoir toutes les photos pour pouvoir supprimer les doublons / calculer la répartition en séquence en fonction des distances entre les photos, donc dur de publier au fil de l’eau.
Le problème est résolu dans le sens où les uploads ne sont finalement pas bloqués mais prennent beaucoup de temps; un ajustement CPU/RAM/Nombre de workers règleront sûrement ce point.
Nous devrions avoir l’occasion de parler de cela lors de notre point que l’on doit programmer entre nous (cf mails).
Waiting for collections to be created │ 58903 │ 58826 │ 77 │ 0 │ 0 │
