Mon serveur Firebird plante de temps en temps [Résolu]

[Fulcanel]

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 ...

[Barbibulle]

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).

[Fulcanel]

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.

[Fulcanel]

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 ...
:-/

[Barbibulle]

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

[Fulcanel]

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 ?

[makowski]

Envoyé par Fulcanel

Bonjour !

J'ai un serveur Firebird qui freeze de temps en temps et je ne sais plus trop quoi regarder.

que donne gstat -h ?

[Fulcanel]

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.

[makowski]

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

[Fulcanel]

Envoyé par makowski

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 ...

[makowski]

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

[Fulcanel]

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

[makowski]

Envoyé par Fulcanel

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

Envoyé par Fulcanel

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

[Fulcanel]

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.