sgrimault
commented
1 year ago Bonjour @gildeluermoz, C'est plus un sujet coté GeoNature que coté "Occtax" :)
Open gildeluermoz opened 1 year ago
sgrimault
commented
1 year ago Bonjour @gildeluermoz, C'est plus un sujet coté GeoNature que coté "Occtax" :)
gildeluermoz
commented
1 year ago Bonjour Sébastien, Oui, j'ai hésité, je peux recréer ce ticket dans GN. Je profite que le ticket est ici pour te poser une question strictement mobile. Ce souci semble en lien avec des requêtes trop longues à retourner un résultat et/ou à une multiplication des connexions.
Concernant les pistes pour réduire le temps de traitement des requêtes, est-ce que tu peux me dire si j'ai intérêt à mettre "page_size": 10000 au lieu de 90000 actuellement sur une instance ou la liste des taxons est de 138 000 ?
Autre piste, si on synchronise une cinquantaine de relevés avec 2-300 observations, est-ce que cela créé 1 connexion par observations donc 2 ou 300 connexions ou tout passe dans une seule transaction. Dans un cas comme dans l'autre on peut soit avoir un souci avec le max_connexions de postgres soit avoir une transaction trop longue si elle encapsule beaucoup d'observation à pousser en base.
A noter ce point dans les logs
processus serveur (PID 252624) a été arrêté par le signal 9 : Processus arrêté
Le processus qui a échoué exécutait : COMMITqui fait penser à une erreur lors d'un commit d'une transaction longue à aboutir. En te remerciant
sgrimault
commented
1 year ago Ah oui effectivement 90000 pour page_size ça me semble élevé. De mémoire 50000 c'était déjà limite sur l'instance de demo.
La valeur par défaut pour page_size a été fixée à 1000 (un peu faible sans doute pour assurer que les appels chaînées puissent passer sans souci, mais je pense que 10000 me semble très bien comme un bon compromis entre le nombre d'appels à empiler coté "Occtax" et le volume de données à remonter à chaque appel.
Pour la partie synchronisation des relevés, le processus a été revue depuis la version 2.5.0 avec la gestion des médias et il est plus complexe car il doit enchaîner plusieurs appels coté GeoNature. Ce traitement n'est pas transactionnel :
POST -> /api/occtax/OCCTAX/only/releve pour créer le relevé en lui même et récupération de son ID généré coté GeoNaturePOST -> /api/occtax/OCCTAX/releve/{{id}}/occurrence pour chaque occurrence de taxon du relevé avec les dénombrements
POST -> /api/gn_commons/media pour chaque média (ici les photos) présent pour chaque dénombrement de chaque occurrence de taxonAvant la version 2.5.0, il n'y avait qu'une seule route appelée pour créer un relevé dans son intégralité (occurrences et dénombrement) : POST -> /api/occtax/releve. Comme cette route est considérée comme obsolète peut être ne gère-t-elle pas très bien la création complète d'un relevé surtout si ce dernier comporte peut être trop d'occurrences ?
gildeluermoz
commented
1 year ago Merci Sébastien pour cette réponse précieuse. Ca m'éclaire bien sur les potentielles pistes du problème et d'amélioration. Je passe page_size à 10 000 et je vais passer l'appli en V2.6.0. elle était en 2.4.0.
Version de l'application
Version d'Occtax-mobile affectée par le bug : 2.4.0 Version de GeoNature utilisée : 2.11.1 A priori le soucis semble venir du traitement des requêtes de synchro coté GeoNature.
Description du bug et comportement attendu
Fréquement, la synchronisation provoque un plantage de postgres. Lors du dernier plantage, la synchro concernait une cinquantaine de relevés pour 2-300 obs. Il y a également environ 100 000 taxons dans la liste des taxons synchronisés. Postgres semble rester dans un état intermédiaire, comme s'il cherchait à faire aboutir qq chose qui n'abouti jamais puis, parfois 1 ou 2h plus tard, il crash. Il faut faire un restart de postgres ainsi que des services GN, taxhub et usershub pour rétablir un fonctionnement normal. En 2 mois et demi, c'est environ 6 à 8 plantages de ce genre auxquels j'ai du faire face. durant qq jours tout se passe normalement et parfois ça plante. L'analyse des logs n'est pas facile, ils sont très verbeux coté geonature et peu coté postgres. A priori la synchro a été faite vers 10h54 et postgres a planté vers 12h41
En recherchant des infos autour de ce genre d'erreur, j'ai trouvé ça : https://stackoverflow.com/questions/24130305/postgres-ssl-syscall-error-eof-detected-with-python-and-psycopg et notamment cette partie :
Ca fait un moment que j'essaie de comprendre d'où vient ce souci que j'ai sur instance et pas sur les autres mais je ne trouve rien de très probant. Si vous avez des pistes, je suis preneur. Sachant que cette instance est en production chez un client, je ne maitrise pas quand ont lieu les synchros.
Logs postgresql :
A noter : au début :
processus serveur (PID 252624) a été arrêté par le signal 9 : Processus arrêtéLe processus qui a échoué exécutait : COMMITPuis une suite en chaîne à 12h41:02 aboutissant à l'arret du serveur postgres à 19h40 redémarrage du service postgres manuellement.Logs Geonature
A noter : l'erreur lors d'une requête d'insertion dans cor_counting_occtax (pas d'horaire mais probablement 10h54) puis à 12h41 d'abord des
psycopg2.OperationalError: server closed the connection unexpectedlypuis rapidement descould not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?