Forums PostgreSQL.fr

Mathieu Denat

Membre

Diagnostic segmentation fault

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 autovacuum

De 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!

Marc Cousin

Membre

Re : Diagnostic segmentation fault

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.

Mathieu Denat

Membre

Re : Diagnostic segmentation fault

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.

Marc Cousin

Membre

Re : Diagnostic segmentation fault

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.

Mathieu Denat

Membre

Re : Diagnostic segmentation fault

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

Marc Cousin

Membre

Re : Diagnostic segmentation fault

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.

Mathieu Denat

Membre

Re : Diagnostic segmentation fault

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.

Marc Cousin

Membre

Re : Diagnostic segmentation fault

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.

Mathieu Denat

Membre

Re : Diagnostic segmentation fault

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/409197

Toutes 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?

Marc Cousin

Membre

Re : Diagnostic segmentation fault

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.

Mathieu Denat

Membre

Re : Diagnostic segmentation fault

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.

Marc Cousin

Membre

Re : Diagnostic segmentation fault

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.

Mathieu Denat

Membre

Re : Diagnostic segmentation fault

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.