Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 14 sur 14
  1. #1
    Invité de passage
    Inscrit en
    juillet 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 10
    Points : 1
    Points
    1

    Par défaut Mon serveur Firebird plante de temps en temps

    Bonjour !

    J'ai un serveur Firebird qui freeze de temps en temps et je ne sais plus trop quoi regarder. Si vous avez des pistes d'investigation à me proposer, votre secours serait très apprécié :-)

    Il s'agit d'un Firebird 1.5 sous Linux dont les données (14Go) sont accédées et modifiée par des clients sous Windows (via ODBC) et des scripts perl (Maintenance, monitoring et serveur web).

    Lorsque la plantée se produit, plus moyen de se connecter à la DB (Avec IBExpert, par exemple) et le serveur ne répond pas à la commande restart. Les autres process de mon serveur fonctionnent très bien. Pour "dépanner", je fais un reboot complet de mon serveur, et c'est repartis pour plusieurs jours ou semaines.

    La plantée se produit toujours aux alentours de la même heure dans la journée (Entre 6h et 7h). En regardant les logs firebird, je vois ceci :

    Mon_serveur (Server) Mon May 9 06:34:49 2011
    Database: /path/DB.fdb
    deadlock

    Sauf que voila, je n'y mettrai pas ma main à couper car le système est complexe, mais je suis presque sûr qu'il n'y a pas d'accès en update aux données à ce moment là... et encore moins concurrentielles !

    Questions :
    1) Pensez-vous que ce message de deadlock soit une cause ou une conséquence de mon problème ?
    2) Est-ce que la structure de ma DB ne serait pas endommagée ? Un backup-restore a-t'il des chances de corriger le problème ?
    3) Une fois que la DB est plantée, est-ce que l'utilitaire fb_lock_print a une chance de me donner la dernière requête exécutée par le serveur ?

    D'avance merci de vos lumières ...

  2. #2
    Membre Expert Avatar de Barbibulle
    Profil pro Frédéric
    Inscrit en
    octobre 2002
    Messages
    1 737
    Détails du profil
    Informations personnelles :
    Nom : Frédéric
    Âge : 44

    Informations forums :
    Inscription : octobre 2002
    Messages : 1 737
    Points : 2 326
    Points
    2 326

    Par défaut

    bonjour,

    ODBC =>

    Sinon utilisez vous des UDF ? (si oui lesquelles)

    N'y aurait il pas à cette heure ci une opération de maintenance (genre sauvegarde mais qui ne serait pas faite avec gbak par exemple).

  3. #3
    Invité de passage
    Inscrit en
    juillet 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Je n'y avais pas pensé...

    Effectivement, le backup sur bande se fait aux alentours de cette heure-ci et effectivement, le fichier de la DB était inclus dans la liste.
    Nous l'avons retiré pour ne laisser que le .fbk.

    Je crois que l'on a trouvé grâce à toi Barbibulle.
    Merci beaucoup.

  4. #4
    Invité de passage
    Inscrit en
    juillet 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Zut, ce n'est pas ça.
    Le backup a été modifié, mais la plantée s'est reproduite ce matin. J'ai l'impression que cela arrive de plus en plus souvent.

    Si quelqu'un a une idée ...
    :-/

  5. #5
    Membre Expert Avatar de Barbibulle
    Profil pro Frédéric
    Inscrit en
    octobre 2002
    Messages
    1 737
    Détails du profil
    Informations personnelles :
    Nom : Frédéric
    Âge : 44

    Informations forums :
    Inscription : octobre 2002
    Messages : 1 737
    Points : 2 326
    Points
    2 326

    Par défaut

    C'est peut être une conséquence de ce backup sur bande fait directement sur la base.

    Moi je tenterai :
    -1- Mettre hors ligne la base de données (accès exclusif au SYSDBA) Sauf si tous vos utilisateurs se log en SYSDBA ca ne servirait à rien (dans ce cas il faut faire ces opérations lorsqu'il n'y a pas d'utilisateurs (bloquer le port de FB). -_- Bref tout ca pour avoir un accès exclusif à la base.
    -2- Un gback en ignorant les transactions dans les limbes
    -3- Je renommerai la base de données (pour avoir une sauvegarde au cas ou la restauration se passerait mal)
    -4- Un restaure de la base de données

  6. #6
    Invité de passage
    Inscrit en
    juillet 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Je vais faire une restauration de la DB. Vu qu'elle est utilisée 24/24 par pas mal de monde, je vais devoir planifier un arrêt pour la semaine prochaine.
    J'aurais voulu être sûr que ce soit nécessaire avant de le faire, mais tant pis.

    Plus d'info dans quelques jours, donc...


    Je me suis toutefois intéressé aux logs. Voici ce que me disais fb_lock_print ce matin avant le redémarrage :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
     
    LOCK_HEADER BLOCK
    	Version: 115, Active owner:      0, Length: 262144, Used:  46196
    	Semmask: 0x0, Flags: 0x0001
    	Enqs: 5210412, Converts:      0, Rejects: 3659868, Blocks:      0
    	Deadlock scans:      0, Deadlocks:      0, Scan interval:   0
    	Acquires:      1, Acquire blocks:      0, Spin count: 3776
    	Mutex wait: 0.0%
    	Hash slots:  101, Hash lengths (min/avg/max):    0/   1/   8
    	Remove node:      0, INSERT queue:      0, INSERT prior:      0
    	Owners (28):	forward:  11396, backward:  25212
    	Free owners (36):	forward:  12320, backward:  14460
    	Free locks (103):	forward:  25356, backward:  42984
    	Free requests (103):	forward:  24956, backward:  37252
    	LOCK Ordering: Enabled
    Le Enqs à 5210412 ce n'est pas bon, n'est ce pas ?
    J'ai remarqué que cette valeur augmentait à chaque requête qui est lancée, qu'il ne diminue pas et ce, même si la requête réussie (Ce qui est toujours le cas).
    C'est ce qui se produit aussi maintenant, alors que le serveur vient de redémarrer et qu'il est, je suppose, "propre".
    Cela confirmerait-il que la DB est endommagée ?

  7. #7
    Expert Confirmé

    Homme Profil pro Philippe Makowski
    Consultant spécialité Firebird
    Inscrit en
    mai 2002
    Messages
    2 308
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Makowski
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 2 308
    Points : 3 294
    Points
    3 294

    Par défaut

    Citation Envoyé par Fulcanel Voir le message
    Bonjour !

    J'ai un serveur Firebird qui freeze de temps en temps et je ne sais plus trop quoi regarder.
    que donne gstat -h ?
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

  8. #8
    Invité de passage
    Inscrit en
    juillet 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Ce matin, la DB tient toujours le coup

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
     
    /opt/firebird/bin/gstat Ma_DB.fdb -h
     
    DATABASE "Ma_DB.fdb"
     
    DATABASE header page information:
            Flags                   0
            Checksum                12345
            Generation              76546372
            Page size               4096
            ODS version             10.1
            Oldest transaction      76516169
            Oldest active           76516170
            Oldest snapshot         76516170
            Next transaction        76546359
            Bumped transaction      1
            Sequence number         0
            Next attachment ID      0
            Implementation ID       19
            Shadow count            0
            Page buffers            0
            Next header page        0
            DATABASE dialect        3
            Creation date           Feb 14, 2011 10:34:38
            Attributes
     
        Variable header DATA:
            Sweep interval:         20000
            *END*
     
    ------
     
    fb_lock_print -w | more
    LOCK_HEADER BLOCK
            Version: 115, Active owner:      0, Length: 262144, Used:  44372
            Semmask: 0x0, Flags: 0x0001
            Enqs: 6495596, Converts:      0, Rejects: 4468312, Blocks:      0
            Deadlock scans:      0, Deadlocks:      0, Scan interval:   0
            Acquires:      1, Acquire blocks:      0, Spin count: 3436
            Mutex wait: 0.0%
            Hash slots:  101, Hash lengths (min/avg/max):    0/   1/   8
            Remove node:      0, INSERT queue:      0, INSERT prior:      0
            Owners (31):    forward:  14060, backward:  30024
            Free owners (25):       forward:  29304, backward:  30168
            Free locks (104):       forward:  18524, backward:  21164
            Free requests (104):    forward:  39332, backward:  40228
            LOCK Ordering: Enabled
    La valeur "Enqs" continue de monter. Je vais faire un restart dans la journée pour le réseter. Je ne sais toujours quel est le problème, mais je comprends que cette valeur est un indicateur...

    Le restore est planifié pour mercredi matin.

  9. #9
    Expert Confirmé

    Homme Profil pro Philippe Makowski
    Consultant spécialité Firebird
    Inscrit en
    mai 2002
    Messages
    2 308
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Makowski
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 2 308
    Points : 3 294
    Points
    3 294

    Par défaut

    Code :
    1
    2
    3
    4
            Oldest transaction      76516169
            Oldest active           76516170
            Oldest snapshot         76516170
            Next transaction        76546359
    tu as plus de 30000 transactions ouvertes ??????

    corrige ton code, ton gap de transaction est bien trop grand
    tu dois avoir une transaction ouverte depuis trop longtemps pour rien et qui bloque tout
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

  10. #10
    Invité de passage
    Inscrit en
    juillet 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Citation Envoyé par makowski Voir le message
    tu as plus de 30000 transactions ouvertes ??????

    corrige ton code, ton gap de transaction est bien trop grand
    tu dois avoir une transaction ouverte depuis trop longtemps pour rien et qui bloque tout
    J'ai d'abord pensé que le problème venait du code, moi aussi. Mais maintenant, je doute car même les requêtes lancées avec IBExpert laissent des transactions ouvertes. C'est aussi le cas avec des scripts réputés sans bugs, ou avec les clients sous Windows...

    Question : Admettons que je me trompe et que le problème vienne d'un bout de code mal foutu dans un coin .. Sachant que plusieurs programmeurs sont impliqués sur cette plateforme, j'ai de la peine a deviner lequel. Y aurait-il un outil sous Firebird pour me donner des infos ? Le SQL de la requête concernée serait super ...

  11. #11
    Expert Confirmé

    Homme Profil pro Philippe Makowski
    Consultant spécialité Firebird
    Inscrit en
    mai 2002
    Messages
    2 308
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Makowski
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 2 308
    Points : 3 294
    Points
    3 294

    Par défaut

    IBExpert laissent des transactions ouvertes

    la bonne blague
    et alors ?
    c'est pas pour cela que c'est une bonne chose, loin de là
    c'est même une erreur de laisser ouvert un "IBExpert" trop longtemps sur une base

    quand à :
    C'est aussi le cas avec des scripts réputés sans bugs, ou avec les clients sous Windows...
    je ne vois pas de quoi tu parles et si des transactions sont laissées ouvertes plus que nécessaire, c'est mal

    Admettons que je me trompe
    oui tu te trompes et les stats le prouvent

    Y aurait-il un outil sous Firebird pour me donner des infos ?
    lire la doc sur les tables de monitoring et le trace manager

    voir utiliser un outil comme Fb Trace Manager http://www.upscene.com/products.misc.fbtm.php

    et lire par exemple http://www.ibphoenix.com/resources/d.../design/doc_21
    et
    http://www.ibphoenix.com/resources/d...general/doc_67
    et
    http://www.ibphoenix.fr/spip.php?article4
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

  12. #12
    Invité de passage
    Inscrit en
    juillet 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Ce que je voulais dire avec IBExpert, c'est que les requêtes que je lance avec lui restent elles aussi ouvertes. Quelles que soient les données que j'accède (Fermer IBExpert lui même n'y change d'ailleurs rien). J'en déduisait que les programmes développés par nous ne pouvait être impliqués.

    En te lisant, cependant, je comprends qu'une seule transaction non terminée (Probablement lancée par un bout de code mal fichu, certes) peut bloquer les suivantes, même si elles n'accèdent pas aux mêmes données. C'est bien cela ?

    Pour ce qui est de la trouver, ma chasse continue.
    Le Trace Manager et les Tables de Monitoring seraient géniales. Malheureusement, je ne les ai pas sous Fb 1.5

  13. #13
    Expert Confirmé

    Homme Profil pro Philippe Makowski
    Consultant spécialité Firebird
    Inscrit en
    mai 2002
    Messages
    2 308
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Makowski
    Âge : 51
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 2 308
    Points : 3 294
    Points
    3 294

    Par défaut

    Citation Envoyé par Fulcanel Voir le message
    Ce que je voulais dire avec IBExpert, c'est que les requêtes que je lance avec lui restent elles aussi ouvertes. Quelles que soient les données que j'accède (Fermer IBExpert lui même n'y change d'ailleurs rien).
    même si je n'aime pas IBExpert, quand tu le ferme il ferme les transactions et connexions
    Citation Envoyé par Fulcanel Voir le message
    En te lisant, cependant, je comprends qu'une seule transaction non terminée (Probablement lancée par un bout de code mal fichu, certes) peut bloquer les suivantes, même si elles n'accèdent pas aux mêmes données. C'est bien cela ?
    oui
    de même que le mode commit retain qui est une absurdité qui n'aurait jamais du être inventée

    lit et relit http://www.ibphoenix.com/resources/d...general/doc_67
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

  14. #14
    Invité de passage
    Inscrit en
    juillet 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Le backup/restore n'a finalement pas eu d'effet.

    La liste de transactions ouvertes continuait de s'allonger. La seule façon de corriger restant un reboot complet du serveur. Un stop/start de Fb ne suffisant pas.

    Pour trouver la transaction incriminée, j'ai programmé dans le crontab un gstat -h toutes les 5 minutes afin de déterminer le moment ou la transaction qui me bloquait était lancée. J'ai découvert qu'elle était lancée entre 5h et 5h05.
    Là j'ai perdu un peu de temps, car le serveur qui lançait cette requête était oublié de tous ... Une fois fait, j'ai épluché le code pour trouver la requête qui n'était pas fermée. Je l'ai trouvé et modifiée.

    Maintenant mon serveur se porte beaucoup mieux.
    Problème résolu.

    Merci à ceux qui m'ont aidés.

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •