Crash postgres à la synchronisation #221
Comments
|
Bonjour @gildeluermoz, |
|
Bonjour Sébastien, 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 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 qui fait penser à une erreur lors d'un commit d'une transaction longue à aboutir. |
|
Ah oui effectivement 90000 pour 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 :
Avant 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) : |
|
Merci Sébastien pour cette réponse précieuse. Ca m'éclaire bien sur les potentielles pistes du problème et d'amélioration. |
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?The text was updated successfully, but these errors were encountered: