Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'ai des déconnexions intempestives lors de requêtes simples (select sur 30 000 lignes par exemple) et sur des requêtes plus gourmandes.
Ce qui me donne côté client (psql) "erreur SYSCALL SSL : EOF détecté".
Exemple:
# SELECT cd_ref FROM inpn.taxref WHERE cd_ref NOT IN (cd_nom);erreur SYSCALL SSL : EOF détecté
La connexion au serveur a été perdue. Tentative de réinitialisation : Échec.
!>Côté serveur (Debian 7 + PostgreSQL 9.1):
Pour le log système (syslog):
Aug 24 10:18:17 Marmoratux kernel: [ 4328.062786] postgres[7245]: segfault at d0233c98 ip b722ee62 sp bf9da570 error 5 in postgres[b71cb000+553000]et pour le log PostgreSQL:
2015-08-24 10:18:17 CEST LOG: processus serveur (PID 7245) a ?t? arr?t? par le signal 11 : Segmentation fault
2015-08-24 10:18:17 CEST LOG: arr?t des autres processus serveur actifs
2015-08-24 10:18:17 CEST ATTENTION: arr?t de la connexion ? cause de l'arr?t brutal d'un autre processus serveur
2015-08-24 10:18:17 CEST D?TAIL: Le postmaster a command? ? ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitt? anormalement
et qu'il existe probablement de la m?moire partag?e corrompue.
2015-08-24 10:18:17 CEST ASTUCE : Dans un moment, vous devriez ?tre capable de vous reconnecter ? la base de
donn?es et de relancer votre commande.
2015-08-24 10:18:17 CEST LOG: tous les processus serveur se sont arr?t?s, r?initialisation
2015-08-24 10:18:17 CEST LOG: le syst?me de bases de donn?es a ?t? interrompu ; dernier lancement connu ? 2015-08-24 10:17:28 CEST
2015-08-24 10:18:17 CEST LOG: le syst?me de bases de donn?es n'a pas ?t? arr?t? proprement ; restauration
automatique en cours
2015-08-24 10:18:17 CEST FATAL: le syst?me de bases de donn?es est en cours de restauration
2015-08-24 10:18:17 CEST FATAL: le syst?me de bases de donn?es est en cours de restauration
2015-08-24 10:18:17 CEST LOG: enregistrement de longueur nulle ? 9/CF5C73C
2015-08-24 10:18:17 CEST LOG: la r?-ex?cution n'est pas n?cessaire
2015-08-24 10:18:17 CEST LOG: le syst?me de bases de donn?es est pr?t pour accepter les connexions
2015-08-24 10:18:17 CEST LOG: lancement du processus autovacuumDe ce que j'en comprend le serveur PostgreSQL se prend les pieds dans le tapis mais je n'en comprend pas la cause.
Pourriez-vous m'éclairer de vos lanternes?
Merci d'avance.
PS: une migration est prévue sur une nouvelle machine bientôt suivi d'une mise à jour de postgresql, si au passage vous avez des conseils, liens ou informations diverses à me fournir je suis preneur. Car ce sera ma première fois!
Hors ligne
Les erreurs se produisent systématiquement sur les mêmes requêtes ou c'est plus aléatoire ?
Un plantage sur une requête aussi simple est assez surprenant.
Ça pourrait être une corruption de données, ou un problème sur le serveur.
Marc.
Hors ligne
Les erreurs se produisent quasiment systématiquement, disons dans 60 à 80% des cas.
Si c'est une corruption de données comment puis-je identifier la donnée qui pose problème?
Dans le cas d'un problème serveur, il s'agirait d'un problème matériel type RAM ou disque dur montrant des signes de faiblesses ou tu penses à autre chose?
Merci en tous cas.
Hors ligne
Ma question c'est: si tu lances cette requête:
SELECT cd_ref FROM inpn.taxref WHERE cd_ref NOT IN (cd_nom)
Elle explose systématiquement ? C'est quoi d'ailleurs ce «cd_nom» (habituellement on voit un subselect dans un NOT IN)
Marc.
Hors ligne
Ah pardon je n'avais pas compris.
Oui elle plante systématiquement.
cd_nom est un champ issu de TaxRef, le référentiel espèces fournit par le ministère de l'environnement (grosso modo!).
Là l'idée est de trouver les cd_ref qui ne sont pas dans les cd_nom.
En fait une espèce peut être saisie sous plusieurs noms car la taxonomie évolue.
Le crapaud croa peut s'appeler crapaud karaoua dans le référentiel suivant (la magie de la génétique! 
).
Le référentiel évoluant plus vite que les naturalistes (imagine si tu devais réapprendre X noms d'espèces à chaque version ça deviendrait compliqué) il faut qu'on puisse saisir crapaud croa mais qu'en base le crapaud croa fasse bien référence au crapaud karoua.
D'où l'idée de cd_ref et cd_nom: cd_ref pour le code de référence saisi et cd_nom pour le code du nom valide de l'espèce pour le référentiel TaxRef.
Ainsi lorsque je t'envoie mes données naturalistes tu te trouveras avec uniquement des crapauds karoua même si j'ai saisi un crapaud croa. Puisque nous utilisons le même référentiel alors nous pouvons échanger sans trop bricoler (c'est une des utilités de TaxRef).
C'est peut-être un peu touffu mais j'espèce avoir été clair.
Si ça t'intéresse voici un lien vers TaxRef: http://inpn.mnhn.fr/programme/referenti … que-taxref
Hors ligne
cd_nom, c'est donc un champ de la table taxref… il est de quel type ? (c'est un peu inhabituel d'avoir autre chose qu'un select dans un NOT IN).
Marc.
Hors ligne
Oui c'est un champ de la table taxref, de même que cd_ref.
Ce sont des champs en character varying pour les deux.
Hors ligne
Ok. Donc il ne peut y avoir qu'un seul cd_nom… Pourquoi un NOT IN et pas un <> ?
Sinon, pour revenir au problème de crash inital…
un «\copy inpn.taxref to /tmp/toto» (dans un psql) crash aussi ?
Marc.
Hors ligne
Euh joker pour le NOT IN! C'est un bout de code filé par un collègue qui touche plus que moi! (je suis plutôt débutant débutant/avancé).
J'obtiens le même résultat avec la requête suivante: SELECT cd_ref FROM inpn.taxref WHERE cd_ref <> cd_nom;
Alors le crash initial:
tentative 1 --> semble avoir marché
tentative 2 --> déconnecté du serveur
tentative 3 --> semble avoir marché
tentative 4 --> déconnecté du serveur
tentative 5 --> semble avoir marché
tentative 6 --> déconnecté du serveur
tentative 7 --> semble avoir marché
tentative 8 --> déconnecté du serveur
tentative 9 --> semble avoir marché
tentative 10 --> déconnecté du serveur
Je ne sais pas à partir de combien d'essai on peut dire que ça marche une fois sur deux mais ça semble être 50% fonctionnel et 50% problématique (même si j'attends un laps de temps variable entre chaque tentative).
Par contre côté contenu devrais-je avoir 452 103 lignes dans toto?
J'ai 452 103 dans la table taxref.
Voici la fin du fichier toto qui fait 33 116 lignes.
$tail /tmp/toto
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16409 188682 16409 ES Acallocrates denticollis (Germar, 1824) Acallocrates denticollis (Germar, 1824) <i>Acallocrates denticollis</i> (Germar, 1824) Acallocrates denticollis (Germar, 1824) 3 P http://inpn.mnhn.fr/espece/cd_nom/16409
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16410 188682 16409 ES Acalles denticollis Germar, 1824 Acalles denticollis Germar, 1824 <i>Acalles denticollis</i> Germar, 1824 Acallocrates denticollis (Germar, 1824) 3 P http://inpn.mnhn.fr/espece/cd_nom/16410
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16411 188682 16409 ES Acalles (Acallocrates) denticollis Acalles (Acallocrates) denticollis <i>Acalles </i>(<i>Acallocrates</i>)<i> denticollis</i> Acallocrates denticollis (Germar, 1824) 3 P http://inpn.mnhn.fr/espece/cd_nom/16411
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16412 188682 16412 ES Acallocrates minutesquamosus (Reiche, 1860) Acallocrates minutesquamosus (Reiche, 1860) <i>Acallocrates minutesquamosus</i> (Reiche, 1860) Acallocrates minutesquamosus (Reiche, 1860) 3 P http://inpn.mnhn.fr/espece/cd_nom/16412
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 409293 188682 16412 ES Acalles discors Hoffmann, 1958 Acalles discors Hoffmann, 1958 <i>Acalles discors</i> Hoffmann, 1958 Acallocrates minutesquamosus (Reiche, 1860) 3 P http://inpn.mnhn.fr/espece/cd_nom/409293
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16413 188682 16412 ES Acalles minutesquamosus Reiche, 1862 Acalles minutesquamosus Reiche, 1862 <i>Acalles minutesquamosus</i> Reiche, 1862 Acallocrates minutesquamosus (Reiche, 1860) 3 P http://inpn.mnhn.fr/espece/cd_nom/16413
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 188685 184685 188685 GN Acalyptus Acalyptus <i>Acalyptus</i> Acalyptus \N P
http://inpn.mnhn.fr/espece/cd_nom/188685
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 15772 188685 15772 ES Acalyptus carpini (Fabricius, 1792) Acalyptus carpini (Fabricius, 1792) <i>Acalyptus carpini</i> (Fabricius, 1792) Acalyptus carpini (Fabricius, 1792) 3 P http://inpn.mnhn.fr/espece/cd_nom/15772
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 409198 188685 15772 ES Acalyptus caucasicus Reitter, 1900 Acalyptus caucasicus Reitter, 1900 <i>Acalyptus caucasicus</i> Reitter, 1900 Acalyptus carpini (Fabricius, 1792) 3 P http://inpn.mnhn.fr/espece/cd_nom/409198
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 409197 188685 15772 ES Acalyptus fuscipes Thomson, 1870 Acalyptus fuscipes Thomson, 1870 <i>Acalyptus fuscipes</i> Thomson, 1870 Acalyptus carpini (Fabricius, 1792) 3 P http://inpn.mnhn.fr/espece/cd_nom/409197Toutes mes versions de toto semblent identiques (même poids, même nombre de lignes, terminent tous par http://inpn.mnhn.fr/espece/cd_nom/409197 ).
C'est grave docteur?
Hors ligne
C'est vraiment très bizarre. Je ne vois pas comment il ferait autre chose qu'un full scan sur cette table, c'est donc une requête vraiment simple. À tout hasard, Postgres est à jour ? Il y a eu il y a un certain temps des bugs d'initialisation de variables, qui pouvaient entraîner ce genre de plantages. Mais ça date...
=> Quelle est la version exacte de PG ? (select version() )
Marc.
Hors ligne
Ouf!
Je crois avoir réglé le problème à l'instant!
J'ai recréé ma table taxref, notamment à l'aide de ce tuto:
http://si.cenlr.org/postgresql_fdw_taxref
Et ça semble résoudre mes soucis.
Pour info le "\copy toto" semble fonctionner aussi (400 000 lignes et des poussières).
Je penche vers la table corrompue (je ne sais pas pourquoi ni à cause de quoi...).
Comme taxref est une table centrale (comprendre appelée par beaucoup d'autres), ça devait être le grain de sable qui grippait l'engrenage.
Existe-t-il une procédure pour savoir si une table contient des erreurs?
Je suis preneur de ce type d'information sur la maintenance globale du serveur.
Pour info notre version vieillissante:
PostgreSQL 9.1.15 on i686-pc-linux-gnu, compiled by gcc (Debian 4.7.2-5) 4.7.2, 32-bit
Merci pour ton aide en tous cas.
Hors ligne
C'est très étrange… mais bon, si le problème est résolu de cette façon, ça devait effectivement être une corruption de table.
Pour détecter les corruptions, il faut créer une instance avec checksums. Ce n'est disponible qu'à partir de la 9.3.
Marc.
Hors ligne
Ok merci pour tout.
J'attends le nouveau serveur pour upgrader la base, et j'attends avec impatience les vues dématérialisées de PostGIS.
Bonne soirée.
Hors ligne
Pages : 1